Ethereum’s Vitalik Buterin: Layer 1 base level can’t too powerful but need powerful enough to support the complexity of applications on layer 2

By Congecko News 12/27/19 10:53 PM

One of the most common strands of thinking in blockchain space is that base-layers (layer 1) should be stable and simple because they are is a piece of infrastructure that is difficult to change and would lead to great harm if it breaks. Whereas, complexity and further applications should be built on layer 2: state channels, Plasma, rollup, and so on.

However, in a recent blog post, Vitalik Buterin, co-founder of Ethereum, challenges this thinking, said that while the splitting is a good idea and he strongly supports this idea in the long-term, the layer 1 base level must be powerful enough to support the complexity of applications on the layer 2.

Vitalik Buterin, co-founder of Ethereum

According to that, Buterin shared the kind of thinking misses an important point: although layer 1 cannot be too strong because of greater power implies greater complexity and therefore greater brittleness, layer 1 must also be powerful enough for the layer 2 protocols-on-top that people want to build to actually be possible in the first place. Hence, when a layer 1 protocol has reached a certain level of functionality, which could call “functionality escape velocity”, then we can do everything else on top without changing the base.

On the other hand, in the case that layer 1 is not powerful enough, in theory, we can talk about filling in the gap with layer 2 systems, but the reality is that there is no way to actually build those systems, without reintroducing a whole set of trust assumptions that the layer 1 was trying to get away from.

Besides, the co-founder also explained that it must be possible to execute custom user-generated scripts on-chain without the need for a high-performance language. It only needs the level of functionality required to be able to verify “arbitrary things that might need to be verified”.

Moreover, he affirmed that it was important because the layer 2 protocols that are going to be built on top need to have some kind of verification logic, and this verification logic must be performed by the blockchain somehow.

In addition, Buterin said that any program in one Turing-complete language can be translated into an equivalent program in any other Turing-complete language, though slightly lighter languages can also be used, and it’s okay to restrict programs without loops, or programs that are guaranteed to terminate in a specific number of steps.

Further, he added, no matter which programming language exists, it’s also important how exactly that programming language is integrated into the blockchain.

Particularly, the co-founder stated that this “pure function” approach would not strong enough to execute a lot of kinds of 2 protocols that people actually want to perform. For example, it can do channels (and channel-based systems like the Lightning Network), but can not scale techniques with stronger properties or bootstrapping systems that have more complicated notions of state.

It also pointed out that plasma and channels, and other layers 2 protocols that are fully off-chain have some fundamental weaknesses that prevent them from fully replicating the capabilities of layer 1. For instance, these protocols need to have a way of adjudicating situations where some parties maliciously fail to provide promised data, and data publication is not globally verifiable, which is not game-theoretically stable.

There is one way to solve, which is layer 2 protocols that publish very small amounts of data on-chain but do computation entirely off-chain. Moreover, if a blockchain allows for the publication and guarantees the availability of a reasonably large amount of data, even if its capacity for computation remains very limited, then the blockchain can support these layer-2 protocols and achieve a high level of scalability and functionality.

So, how much data does the blockchain need to be able to process and guarantee? yes, it focuses on what TPS you want. “With a rollup, you can compress most activity to ~10-20 bytes per transaction, so 1 kB/sec gives you 50-100 TPS, 1 MB/sec gives you 50,000-100,000 TPS, and so forth.”

In general, the Buterin said that we need layer 1 development parallel with layer 2 in the short-term and more focus on layer 2 in the long-term.