Proof-of-Work and Proof-of-Stake have proven to be the most popular consensus mechanisms. However, they are not the only methods for getting nodes to verify and agree upon data. Other projects have experimented with rather unique ways of achieving consensus:
A Proof-of-Work algorithm that is monitored by masternodes. Each Dash masternode requires a minimum stake to run. Masternodes are tasked with acting as extra network supervisors, earning passive income while providing network security. This is essentially a partnership between a Proof-of-Work and Proof-of-Stake algorithms, the two working in concert with each other. Blocks are still compiled by miners, but masternodes provide additional supervision while earning coins and ensuring the security of the network.
Another interesting consensus system is Proof-of-Activity, which is a unique hybrid between Proof-of-Work and Proof-of-Stake, allowing the network to implement a series of incentives. The more active you are on a network, the more likely you are to be selected as a validator. This model prioritizes network activity over PoW
21 block producers are elected by EOS holders. Block producers are tasked with compiling data into a block, essentially confirming valid transactions to get a block reward. These block producers must stake their EOS, and are randomly chosen to produce the next block. If EOS holders are unhappy with a block producer, they can be voted out and a new block producer is elected. Rewards are very high for block producers, as they collect all transaction fees accrued by the network. This provides an incentive for block producers to follow network protocol, along with the fact that they would lose their status as a validator if any funny business was afoot. This consensus method is known as Delegated Proof-of-Stake or dPoS. It functions as a senate or representative legislative body. EOS holders elect representatives in block producers, who make the crucial decisions and confirmations needed to sustain the network.
One of the most contentious forks in cryptocurrency history occurred when Bitcoin Cash split from the main Bitcoin blockchain, creating a separate blockchain and new cryptocurrency. This happened on August 1st, 2017. That date was the culmination of the scaling debate surrounding blockchain. Essentially, the Bitcoin network had seen a recent increase in activity from the previous year as there had been a huge increase in transaction volume. This resulted in backlogs and high network fees. We’ll talk about scaling in the next lesson but put simply, scaling addresses the question of how the Bitcoin network can handle the extra strain put on the network.
The Bitcoin blockchain split in a hard fork, resulting in the creation of the Bitcoin Cash chain. This process was a divergence of code based on incompatible ideas. When the chains split, holders of bitcoin were given an equal amount of bitcoin cash. Coins on the Bitcoin network are essentially duplicated onto a different chain. Forks happen all the time on open source projects, but most were not as contentious as the Bitcoin/Bitcoin Cash fork.
The disagreement originated over conflicting ideas on how to scale the Bitcoin blockchain for increased global demand. One group wanted to increase the block capacity from 1MB to 2MB to hold more data. Satoshi Nakamoto specifically stated that scaling should occur on-chain, bolstering the block increase argument as it more closely followed Satoshi’s original vision. This group would eventually split off into the Bitcoin Cash blockchain. The Bitcoin Core developers wanted to upgrade the internal structure of blocks to be more efficient and flexible for future growth. Importantly, this contains a fix to a long-standing bug in Bitcoin call transaction malleability. The addition of SegWit, a protocol upgrade that stores data more efficiently within the 1MB block by utilizing block headers was Bitcoin Core’s solution to this problem. The addition of SegWit also enabled the viability of second-layer solutions.
Bitcoin Core block size is still roughly 1MB while Bitcoin Cash increased to 8MB during the split. Bitcoin Cash would go on to eventually increase to their block size to 32 MB per block.
One of Bitcoin Core’s proposed solutions was to introduce side chains, designed conduct transactions on a parallel blockchain. Another solution was to add a second layer to the network like the Lightning Network, which has transactions conducted off-chain that are not recorded on the Bitcoin blockchain except at open or close of a payment channel. They also aimed to implement the previously mentioned “SegWit”, a protocol change that adjusted how transaction data is stored in a block, theroretically maximizing efficiency. Bitcoin Cash planned to increase block sizes and plans to keep doing so as needed. Bitcoin Cash had a successful first year, having been added to multiple exchanges and onboarding several new vendors. However, not all has been rosy in the Bitcoin Cash community since the split.
Much of blockchain governance is focused on making blockchains as efficient as possible while maintaining decentralization and security. In the next lesson, we’ll take a look at how blockchains are striving to meet the demand needed for widespread use.