Unless you’ve been living under a rock, I’m confident that you’ve heard about blockchain and the unsettling intricacies that surround it. Decentralization, Bitcoin, mining, ledgers, and other keywords appear to be acquiring new popularity every day as “Satoshi” gains more romantic connotations. The necessity for a safe and expandable infrastructure becomes even more urgent as everyone’s passion for it grows.
Scalability, the current buzzword, has been the subject of intense debate among crypto professionals, businesses, and opponents for more than a year, preventing widespread use of the technology. It’s interesting to note that if blockchain were to support Facebook in its current form, it could only handle fifteen likes per second as opposed to the millions that would normally go over the Facebook network. It is immediately needed when those millions are combined with the volume of activity taking place on Snapchat, Instagram, and YouTube.
After discussing the problems with scaling, let’s truly dig down into the fundamentals of blockchain technology to attempt to understand how everything fits together and where the peer-to-peer (P2P) network actually becomes the bottleneck. Although we will use the Bitcoin blockchain as our starting point for simplicity’s sake, the issue applies to all blockchains equally.
The fundamental building blocks of blockchain, which maintains a collection of data and connects that data to one another to create a chain of data, are blocks. According to how Bitcoin operates, each time a transaction is carried out, it must be recorded in a block, or so-called “digital container,” and kept unaltered forever. A procedure known as mining produces one such new block every span of time.
A simple, easier-to-visualize architecture can accommodate the aforementioned procedure. Consider a pyramid that has three planes:
the network plane
the consensus plane, and
the ledger plane
The component that mines blocks in order for a widespread consensus to be formed is called the consensus plane, whereas the network plane is where P2P propagation runs, and the ledger plane is the place where blocks are ultimately kept when they are mined. The consensus plane, as a generic abstraction, takes in messages from the network plane and generates operations for insertion into the system ledger and integration into the blockchain.
While many projects have been working on scaling blockchains over the past year with a focus on the consensus plane, the network plane, which is the basis of the system, has mostly been seen as a black box that just functions.
The P2P network for Bitcoin is composed of miner nodes that connect to one another at random. These nodes disseminate transactions and blocks throughout the network until all have received the information. Hops are required for a transaction to spread a message throughout the network. The network dispersion increases by a factor of 2n with each iteration as a set of two nodes are delivered the message. After twelve to fifteen hops, the message is distributed over the whole network, with the diffusion growing exponentially as the number of hops rises.
The throughput of a blockchain is determined by the number of transactions it can support per second and is expressed as –
Where, TransactionsBlock is the factor of the current block capacity of the Bitcoin and average transaction size.
With an average transaction size of about 540 bytes and the current Bitcoin block capacity of 1MB for a block interval of ten minutes, the network now handles about 1,950 transactions each block, or about three transactions every second (TPS).
Either the transactions per block or the blocks per second can be increased to boost throughput. It has already taken a lot of effort to use both on-chain and off-chain techniques to increase the number of transactions per block. Teams have experimented with expanding the block size by ten times in an effort to multiply the capacity by a factor of ten. A higher block size typically maintains the hop count at twelve to fifteen for the whole network, but necessitates delivering a bigger block (one block of 10MB) through the Bitcoin connection.
Although the transaction/block size grows in this case, it also raises the issue of network throttling, which exponentially lengthens propagation times and raises the stakes in the argument over Bitcoin splits. One such attempt is the hard fork of Bitcoin into Bitcoin Cash.
On the other hand, blocks/second is another important component to take into account for network scaling, although it has so far frequently been overlooked owing to a variety of throttling considerations. The absence of features like pipelining, latency optimization, redundancy, congestion, message losses, and others prevent the Bitcoin network stack from achieving the per-node link capacity, making the existing gossip mechanism that determines journey time on the network plane inefficient.
For visuals of block propagation across the network, please refer to this link.
Now that we’ve looked at the different components of a block journey, let’s return to the subject at hand. Over the past year, projects have mostly emphasized the consensus plane. While off-chain and side-chain projects like Lightning Network, Plasma, Raiden Network, etc. have developed ways to scale by computing off the chain and storing the results on the chain, on-chain projects like Zilliqa, Wanchain, Dfinity, and EOS have attempted to change the current consensus in order to increase throughput. Scaling options both on-chain and off-chain have been thoroughly studied. The bulk of them, however, have either failed to meet the extra specific needs of security and/or decentralization or have sufficiently fragmented the network to cause adoption issues.