Every year new crypto PoW (Proof of work) based projects are launched, and every year older projects die away. One of the major reasons for this turn-over is due to blockchain-bloat. You see, as a coin ages the depth of the blockchain that it records obviously grows. Depending on the speed of the transaction verification sometimes those blockchains can grow very quickly. This usually continues until the chain is so very large, that the project is not worth the cost of disk, network bandwidth and memory used to contain that blockchain. Once that cost is too high, for the rewards gained, these projects either close down, or switch to a new algorithm, and swap their coins onto that newer algorithm in a very disruptive and risky manner. Even in cases there the blockchain is worth continuing, this bloat issue often leads to greater centralization, since smaller network nodes can no longer contain it. In my own project at Fedoragold.com after 5 years our blockchain is now about 10 gigabytes. Is there a solution to the chain growth that will allow our project to continue after year 10 and beyond?
At the time of this writing a huge "Crypto Drama" is unfolding as Ethereum is scheduled to switch from Proof of Work to Proof of Stake (PoS). One of the major reasons for this is again related to blockchain-bloat. However, PoS has many disadvantages; for example, once only a few large staking entities such as COINBASE are in charge of maintaining the Ethereum chain governance, they will very likely be forced into compliance with SEC policy regarding the banning of Ethereum addresses (see my previous posting "The Future of Crypto Is Fungible"). Centralization, in either PoS or PoW systems both lead to market manipulation exactly of that sort. Was there another solution possible for this situation, that would have allowed Ethereum to remain a Proof of Work based system?
In this posting I will propose one possible solution to that technical challenge posed by blockchain-bloat. For a lack of a better name I will call it "Auto-Forking". Please note, that this solution only works for blockchains that ONLY contain coin information, and not information associated with smart contract applications that may run within them, unless such projects choose to store that extra-chain information outside of the blockchain file itself.
In his seminal Bitcoin White Paper S. Nakamoto described a system that builds a single large blockchain. Satoshi's single chain proposal remains the most prevalent, and generally accepted solution for PoW, as each node can retain a complete copy of the entire blockchain history within a file. It's true that Nakamoto's design does not Require each node to keep the entire chain, but no technical framework was included describing how older blocks should be discarded. But what if that same coin daemon (a server for blockchains) could manage more than one chain? What if the blockchain for even 1 single coin were divided across multiple files and replicated on each client? Such a multi-file based blockchain solution could offer advantages that resolve the issue of blockchain-bloat. This proposed solution could allow PoW based projects to continue for much longer periods of time; and if residual mining rewards are allowed, they could even continue on forever.
Today, when blockchains are forked, these events happen at specific blockchain heights. So, for example the developer could say that the next fork will happen at the block height of 1,000,000 and when the chain reaches that height, the algorithm would update. It may take a long time to reach a block height of 1,000,000; for example it could take an entire year. Inquires about the older chain entries prior to 1,000,000 would still use the previous algorithm for verification, and newer entries at or above the new height of 1,000,000 would respond with the newer algorithm. That's how forks work currently. Sometimes the forks lead to completely new coin projects, and sometimes the forks lead to different algorithm enforcement at different block heights within the same blockchain file. But, these forks could be used within the same blockchain set, and as file boundaries as well.
In our example, beginning at blockchain height 1,000,000 the coin daemon (a server that handles blockchain processing) could look for information about those blocks within a completely different blockchain file. The daemon could use multiple files even though it only services 1 crypto coin project. If this were done, every 1,000,000 blocks then the size and complexity of each blockchain file would be bounded. Updates to the chain would only be made to the current chain. Since the older chains are all immutable (unchanging) this is not an issue. This process could continue with each blockchain file growing to 1,000,000 block entries and then automatically forking onto a new blockchain file.
In this scenario, blockchain files would then be stacked on top of each other in a queue, with the most recent blockchain file at the top of that queue. At the beginning and end of each blockchain file, a "checkpoint" would be set, expressing the chain block number and its associated hash for the 1st and last entry within each blockchain file. A limit would then be placed on the size of the blockchain queue. In this example, let's just say that the blockchain queue size is set to 10. Since in our example, each chain takes about 1 year to build, this would continue for approximately 10 years.
The owners of these wallets would know which layer their coins reside in. The wallet software would simply examine the blockchain files, and identify the deepest layer that each address has coins stored within. That layer depth information would be displayed by the wallet software on screen. So the wallet user would see his coins start out at layer 1, and with each proceeding year they would know that the layers associated with the stored funds are gradually being buried deeper within the blockchain file queue. After year 7, the wallet would begin displaying warnings to the user, indicating that their coins are approaching the "bottom" of the blockchain queue. At year 9 those warnings would blink "code red", and make sure that the user knows very well that the end of the chain is near.
After 10 years have passed, and the queue has 10 layers and 1 additional blockchain layer is to be added, then the blockchain file at the bottom of the queue would be forked off automatically. The blockchain would still service entries for that layer 11, but support for that layer 11 would no longer be mandatory for all daemons, and smaller network nodes running daemons could choose to ignore that discarded layer 11. Blockchain layers in discarded sections such as this would be LESS secure than the more current layers above, because not every daemon would choose to service them. Even though network fees paid to daemon operators could pay extra for maintaining those discarded sections, eventually, after many years, these discarded layers would be lost forever, as the number of coins stored within them, and therefore the expanded fees paid, would diminish over time. Once these discarded sections are economically inviable, they would be permanently discarded at that moment, starting with the deepest blockchain section first and working upwards from there. The higher level chains would still operate however, as they would simply start with the bottom-most "checkpoint" recorded for the lowest section which is at number 10.
So, why does this work you may ask? Isn't the blockchain supposed to be immutable and form a record forever? Well, nothing lasts forever. One day even our Sun will stop shining, and blockchains are no exception to that rule. The users of this crypto would have had 3 years warning to move their coins prior to the creation of a new "discard" section containing the stored funds. And the end-user solution is actually quite simple. The user simply creates a new wallet address, and then sends the coins to himself, (and presto!) his coins are once again held at layer 1, with another 10 years notice.
So, you see there IS a solution to PoW blockchain-bloat. We need not favor very large coin holders in order to do away with the complex encryption standards associated with PoW. We need not settle for increased centralization that leads to control from Regulatory Agencies. The controllers of our PoW chains CAN remain the miners, who have an independent system of incentives proven to lead to more healthy coin governance.
The Future of PoW Is Forked.
