Blockchain Explorer
Bitcoin is based on Proof Of Work (PoW). While DLT (distributed ledger technology) based on PoW naturally prevents certain Byzantine conditions, it is very expensive and slow. Proof of Stake (PoS) on the other hand makes it fast to finalize a block. 0chain, in it’s quest to fast finality, has adopted Proof of Stake based consensus algorithm. It is a variation of a couple of PoS based algorithms that have been published in the last couple of years. The variation stems from our desire to separate out the role of the miner and sharder but also based on the experience of running a testnet spanning multiple continents and studying the network latency behavior. An upcoming paper will talk more about our technology in detail. However, I would like to highlight a few problems and visually present how they are addressed within our blockchain.
PoS is easily prone to DDoS attacks especially when information is available upfront. That’s why, unlike traditional distributed consensus algorithms like Paxos and Raft that have a single leader, a public blockchain needs to operate with multiple “leaders” at any given time. Not only would this prevent an external threat like a DDoS, it also prevents an internal threat like a Byzantine condition. We know that any distributed consensus algorithm that can defend against Byzantine condition needs to have 3*f+1 active participants with at most f Byzantine participants. However, ensuring we have more than f participants are doing all steps of the consensus algorithm can lead to a lot of wastage (of course, still better than PoW). For example, when there are 100 active miners, how many should be generating a block within a given round? Anything more than 34 would ensure that it can defend against the worst case Byzantine condition. However, given that only one block gets finalized from a given round, generating 34 blocks is a lot of wastage of resources.
That’s why, 0chain allows configuring how many generators propose a block in a given round. This can be a much smaller number. On one hand, we don’t want this number to be too high as it’s a waste of resources and on the other, not too low, as it can easily lead to Byzantine conditions. Of course, as long as there is a provision to shuffle the generators to a different set when the chosen set is not operating properly (due to real issues like network partition or deliberately by being Byzantine), then the number of generators can be reasonably small. In fact, in a completely private setting, one could configure it to be just 1 making it similar to CFT (crash fault tolerance) only consensus algorithms.
When multiple miners can generate a block, then the issue is how to ensure that everyone agrees upon the same block. As with many fast finality protocols, 0chain protocol also allows speculative execution where blocks and chain forks are created speculatively. However, within a short duration, these chain forks are resolved and everyone converges to the same block for a given round. This is easier said than done (coding). But many people have hard-time even visualizing what it means to have several blocks within a given round but eventually the blockchain is converging along a single chain of blocks.
Many of you may have seen block explorers. But have you seen a blockchain explorer which shows how it is progressing with all the speculative blocks in its full glory? Take a look at the video below. As we are trying to optimize the finality by studying the practical deployment scenarios, it became clear that we needed a way to visualize what’s going on under the hood. That’s why we spent sometime hooking up a graph visualization library to display a segment of the latest blockchain rounds that show how the chain is progressing with multiple forks and which blocks are getting finalized and which are getting pruned.
In the above video, the blocks with dashed lines are the blocks that will be be pruned away as they are dead-ends. The blocks with dotted lines are in speculative state and over time they either result in finalized blocks on the blockchain or pruned off. The solid line edges indicate the finalized blocks of the blockchain. The labels on the blocks have the format “Rnn,v,Mx” where Rnn indicates round number (modulo 100), v indicates the number of votes and Mx indicates the miner that generated the block. The size of the block indicates the weightage that should be given to the block in that round as per the consensus protocol.
This video is based on our testnet that is globally deployed with 9 miners (M0 to M8) and 3 generators per round. It shows how in each round 3 miners are generating a block. Of course, sometimes only 2 or even 1 generates a block. This could be because the others don’t have the transactions to build a block yet or they don’t know that they need to generate a block yet due to (temporary) network latencies. Occasionally you can see that more than two blocks are getting notarized in a given round. You would also see notarized or even finalized blocks without a border indicating that the miner from which the data is fetched himself has not verified the block but there was consensus from sufficient number of other miners for the block to got notarized.
One interesting point is that the blockchain explorer wasn’t pulling data from a single miner but randomly from any of the 9 miners and each time it is cleared and rendered using the new data set. This was done deliberately to see if there is a glaring structural difference in the blockchain among the miners. The rendering seems to be smooth indicating that all miners are more or less working with the same set of blocks with same state. It is likely that a block may have border and then not have a border indicating it is verified by some but not the other. I encourage viewers to carefully review and post a comment if you find such a block or any other discrepancies.
Note that this blockchain explorer is not made public. This continuously polls miners and that creates a certain load on the miners. For now, it’s only on my laptop. This is a great tool that helps us gain deeper insight of our constantly improving consensus algorithm paving way to explore further cutting edge research ideas.
