We would like to take a moment to discuss the problems with blockchain, which might seem odd as we are a blockchain company. In truth, it was the problems we saw in the early stages of blockchain technology that led us to create the Factom Network. As the years progress and Factom matures, we like to make sure these core reasons for the Factom Network’s creation stay at the forefront of Factom’s story.
As with most things, the problems with blockchain are only problems in context. The original blockchain implementation, Bitcoin, was designed to track a token (the Bitcoin), and it does this task well. Or at least it did in the early days.
As businesses have attempted to apply blockchain to larger enterprise class problems, some of the limitations of early blockchain implementations have created perception issues with blockchain, specifically the following:
- Blockchain is perceived as slow.
- Blockchain transaction costs are perceived as high.
- Blockchain cost model is perceived as unstable.
Blockchain is Bad for Business
It didn’t take long for the power of blockchain and the unique capabilities it brings to the table to be recognized. The first attempts to apply the power of an immutable distributed ledger to solve real world business problems simply started with Bitcoin. Implementation of business use cases were attempted by adding data to the memo field of the coin.
Soon after that, projects began to fail as enthusiasm for the new technology ran aground on the hard rocks of the limitations of the original Bitcoin implementation. When Bitcoin is used in the context of complex business use cases, problems appear.
When blockchains designed to track tokens are jury rigged to support enterprise applications, all of the problems with blockchains you’ve probably been told about will rear their ugly heads. In the wrong context, blockchain solutions can be slow and the transactions costs can be, at best, unpredictable, and at worse, astronomical.
Don’t give up on the Blockchain, we promise there is light at the end of this dark tunnel.
In essence, many attempts were made to address enterprise problems with first generation blockchains by writing notes into the memo fields of tokens like Bitcoin, then spending the token to make something happen. It’s a bit like trying to implement an enterprise business process by writing notes on dollars and spending them to get the note passed forward. Simply put, the wrong tool is being used. Something designed to track a coin is not the right tool to implement complex business processes.
Bitcoin was implemented to track the ownership of tokens, and as such, one the most fundamental problems Bitcoin addressed was preventing a token from being spent twice. Bitcoin solves the double spend problem admirably, but to do so requires that each transaction be verified across the entire Bitcoin blockchain. Since enterprise business applications were accelerated due to the unique demand for access into the Bitcoin Blockchain’s immutable distributed ledger, the business functionality is chained to the same limitation and this limitation has serious consequences.
Since every transaction requires the entire chain, there’s little or no opportunity for optimization via parallel processing. There might be hundreds or thousands of Bitcoin servers, but each is an island to itself and has no way to share the load. Picking out just the blocks that represent the business object, be it a loan, a piece of tangible property, or a medical record, becomes problematic and very unpractical for traditional business adoption.
Over time, later Bitcoin copies begin appending functionality to the blockchain but the new functionality has to be paid for, which requires a wallet of coins be attached to fund the execution of the functionality.
Little hope for practical business applications on the coin-centered blockchains
Imagine for perspective’s sake that Oracle required a bank account be attached, on the internet, to their database, to pay for services as you make queries. This seems simple enough though possibly inconvenient. But, it gets better because all of those queries must be funded in a foreign currency.
The conversation with might go something like this.
“Sorry, before that join can be executed you must please deposit 3 pesos, wait, make that four pesos. The exchange rate just changed. Hurry, or it might change again. Wait, sorry, someone just hacked all your coins away… Please deposit…”
We can’t image how a company’s CFO would even be able to justify such a software purchase that requires any sort of foreign currency, whether fiat or crypto. How in the world can a business build a predictable cost model when the cost of the token swings wildly minute by minute? How can a business build a secure system when a wallet full of tradable tokens must be attached on the internet?
The consequences of trying to duct tape business functionality into coin-centered blockchains are: 1) extreme performance limits, and 2) a totally unpredictable cost model.
During the 2017 run up in Bitcoin values, most Bitcoin-cloned networks slowed to a crawl as the time to get a transaction recorded stretched out to hours, days, and longer, unless a very high transaction fee was paid. Bitcoin is limited to about seven transactions a second worldwide. No, that was not a mistype. At that transaction rate, the network could simply not keep up with the demand for transactions as the token price rose and therefore the transaction fees spiked through the ceiling and became hazards for passing jetliners.
The fundamental problem is that we try to build enterprise applications by squeezing them into the memo field of a coin transaction.
Why would you design a system that requires a coin to be spent, simply to write data to the blockchain to satisfy a business ask? Coins have value and must be tracked, which is not a requirement for writing business data to the blockchain.
There is a better way
A better approach would be to separate the coins (used to reward those who run the servers the network depends on) from the business functionality the blockchain is built to perform. This need to separate coin from functionality is one of the fundamental observations that drove the design of the Factom protocol.
The primary function of Factom is not to track a coin but rather, to provide a distributed immutable ledger to write complex data in support of enterprise business use cases. To write data into the blockchain, an Entry Credit is used. This Entry Credit is the only way to write data.
Factom separates the coins from the implementation of business functionality by the introduction of Entry Credits. Our coin can be burned to generate Entry Credits which are non-transferable coupons that simply allow an application to write an amount of data into the blockchain.
Entry credits solve the performance bottlenecks because each is only spent once, meaning the entire blockchain is not required to process them. Furthermore, the entire blockchain does not need to be scanned to prevent double spends. They only exist in a single address. Writes to the blockchain become lighting fast and parallel processing across the network is supported to allow the network to scale to support enterprise transaction rates.
Because Entry Credits are not transferable, they don’t paste a big red “please hack me” sign on your application as is the case for implementations that require a wallet of tradable tokens to execute. A Factom application does not need a wallet of tradeable tokens to execute.
Entry Credits have a constant fixed cost, regardless of any price fluctuation of the token price. Entry Credits provide a consistent dependable cost model to build enterprise applications upon. Since tokens are not required to use Factom, the equivalent of a foreign exchange function is not required simply to make use of the Factom blockchain.
Since the data written to the Factom blockchain is not tied to the memo field of a coin, far more complex data can be easily dealt with. Without a coin transaction, the entire blockchain is not required allowing for things like a sub-chain for each mortgage or chains of chains. Instead of trying to fit all the complexity of business use cases into a coin piggy bank, splitting the coins from the blockchain functionality allows for the creation of complex virtual file cabinets of data. There is a reason DBAs typically work with ERD or other diagrams when trying to understand business data. It’s not because the diagrams are pretty, but because business data is complex. It is not something simple that can be scribbled on the memo field of a coin.