The First Layer of Web3: Consensus

What has been built so far, and what are we still missing?

Web3, or the next internet if not too bold to say, needs to have many different layers: storage, communication, light client, oracle, prover network… But the first one, that has started this whole journey, was the consensus layer.

But how much did we build so far, how much is still to be done, and how close we are to completing it?

The Reason

Consensus is the idea of representing a common opinion online. It is required to allow multiple parties to interact and come to a conclusion in a reasonably short time. Starting from Bitcoin to Ethereum, most blockchains focus on this first layer of Web3.

In an ideal consensus layer, we must be able to:

1. Trustlessly order events happening on the network,

2. Prevent any censorship of any transaction,

3. Work in real time, meaning there is no significant delay in between interactions.

The reason behind these needs is to prevent single entities from controlling all the online interactions. As long as actions are ordered in a decentralized way, without any trust assumptions or censorship, we can make sure that the information is not controlled by a single party. Of course, other layers are also a must, but let us focus only on consensus for this article.

Note here that the consensus layer does not need to do any high performant computation. Of course, some amount is necessary to allow state updates, but we do not necessarily need the consensus layer to perform heavy actions on-chain. In the long run, client side computation and prover networks are designed to free the consensus layer from high workload.

This point is somewhat controversial, and many still argue blockchains can enable enough computation power without any zero-knowledge or fraud proof-like solution. To me, this is not a question of can, but rather should. In perfect designs, each layer must be specialized for a single end-goal, and consensus and computation are very different concepts. Moreover, no single computer can perform as efficiently as a distributed computation protocol.

Nevertheless, consensus networks need to be performant, even if they are not responsible for the entire computation. The hard question is, how to enable efficient systems with perfect decentralization?

The Current Status

Over the last years, we have seen significant development in this consensus area, especially in performance and decentralization of the network.

The performance of the network depends on a lot of parameters: number of transactions the network can handle per second (TPS), the total computation (or equivalently verification) power the network can provide (GPS - gas per second), and of course, the update frequency of the state (block time & finality).

It is a fact that no blockchain is as fast as a single high performance server at the moment (or even slower than a common PC usually), but the improvement is drastic. Only ten years ago, finality that lasted less than ten minutes and TPS higher than 100 would be considered amazing. Now, we can achieve subsecond block time and hundreds of thousands of TPS, which is much better than we have imagined.

Nevertheless, improvement is a must. Some interesting areas to work on may be:

1. Multi-block producer schemes, where all validators of the network are used in parallel to generate blocks, not a single one for each slot,

2. Sharding and distribution of sources, to parallelize the workload to multiple nodes simultaneously,

3. Local consensus designs, where not the entire network is used for each decision, but subdivisions are made based on local trust assumptions.

There are already promising projects working on each subject, so my guess is that the performance of the consensus layer is close to becoming perfect in the near future.

Elephant in the Room: Decentralization

Decentralization is the bigger problem: Most people still argue that Bitcoin is the most decentralized decision mechanism we have had so far (I do not argue fully, but it has some truth in it). To clarify a little more, we have 3 important problems that we still couldn’t solve:

First Problem: Censorship

Even if a complete censorship of a transaction is not feasible, it is possible for strong entities to delay the execution of chosen actions in our current designs. Eventual censorship resistance is a strong property, but we need to make sure that all parties have similar delays while waiting to get included in the network. The important observation here is that even a small delay may result in a drastic outcome in sensitive use cases, e.g. finances.

This problem is hard to solve since validators are real entities and subject to law and authority. Thus, the consensus needs to find a way that validators can act freely while also being held responsible for their actions. More than anything, this is actually a privacy problem, which can only be solved with private consensus designs (or private blocks).

Second Problem: MEV (maximal extractable value)

This is the name of validators wrapping TXs with opposite orders to make a net profit from it. For instance, if a significant amount of Bitcoin is purchased on the chain, the validator may buy just before this TX, and sell immediately after, to make a net profit. The concept is much bigger than finance, since basically any information change on the network can be used for some sort of gain by validators, who have earlier access to this information than the rest of the world (information asymmetry).

I do not say all sorts of MEV is dangerous or must be prevented. The problem is more that we do not have a competitive design against it, i.e. you are subject to MEV on all of your actions if you are not able to pay enough fees for private channels. This decreases the mass adoption of blockchains significantly and makes the UX even worse. In any case, information asymmetry is dangerous, as it allows centralization of power in the long run.

Third Problem: Centralization of the validator set

Right now, our decentralization ideas are all based on some sort of economical value, either computation power or blockchain tokens. The more money you possess, the more say you get to have on the network. It is not trivial to see how this can even be changed at all, since everything comes to money in the end. However, a nice property that the chain may provide would be somehow including geographical distribution in the backbone of the consensus, so that the network is incentivized to be as distributed as possible in the world. Right now, this is mostly achieved through external incentivisations (e.g. delegation programs), which does not provide any long term security.

In a different perspective, consensus mechanisms should be able to capture the distribution of opinions in the real world better than just modeling it with economical incentives. Blockchains are right now based on the idea that each party is only trying to maximize its short term gain, which is not always true in real life. Can a better modeling be designed?

Conclusion

I think the main idea of this whole story is that: We do not care about decentralization as much as performance at the moment.

This is sad, but I guess normal, since no new technology can replace the older without matching the bare minimum. Until very recently, the performance was not close to being enough, but this is not true anymore.

Thus, I hope we will see bolder development on the decentralization of the consensus layer in the coming future.

Or else, what is the difference between web 2 and 3, right?