Vitalik Buterin weighs the possibilities and risks of expanding the Ethereum protocol

Ethereum co-founder Vitalik Buterin weighed the advantages of including some features in the core protocol code versus implementing them on top of the blockchain in a blog post.

Should Ethereum be okay with enshrining more things in the protocol?https://t.co/7F7yOLBoUr

— vitalik.eth (@VitalikButerin) September 30, 2023

In the list of discussed solutions, Buterin named the ERC-4337 token standard for account abstraction, ZK-EVM, private mempools, precompiles, and liquid staking.

According to him, the original Ethereum philosophy was ‘protocol minimalism’ — the aim to make the blockchain’s core as simple as possible, implementing most solutions on top. However, recently there has been a ‘careful interest’ in embedding many of these features in the main code, Buterin admitted.

He argues that there are several advantages in enshrining ERC-4337 in the protocol, including:

• more efficient gas usage and a reduction of fixed transaction costs;
• reduction in the risk of a bug in the function’s code;
• resistance to censorship in the protocol.

Regarding the potential inclusion of ZK-EVM in the main code, Buterin noted that there are currently a large number of ZK-rollups implementations. The developers of all these solutions, such as PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth and others, are forced to ‘write quite similar code for verifying block execution’. Theoretically, for this function one could use the base EVM, but there are a number of technological nuances.

«Enshrining ZK-EVM is both a promising and a challenging task», says Buterin.

He noted that the development of MEV has turned block production into a large-scale activity, yielding participants more income than the default algorithms. The community is trying to tackle this problem with off-protocol implementations of the PBS concept — the proposer-builder separation.

Such solutions, for example MEV-Boost, allow validators to delegate block production to specialized participants, but entail trust in a new category of actors — relayers.

However, a strong counterargument for embedding PBS into the protocol code is the risk of consensus overload.   

Regarding recent private mempool projects, the programmer noted that there are serious obstacles to enshrining this function in the protocol. Such solutions keep transactions encrypted until their irreversible inclusion in a block. The encryption technologies used have certain weaknesses, Buterin believes. In his view, implementing private mempools on the first layer of the blockchain without technological breakthroughs seems a ‘difficult task’.

Regarding liquid staking, Buterin reminded of centralisation concerns. In his view, there is a ‘natural centralized mechanic’ in this segment. Users cluster on the largest and most well-known platforms, but the growth in the number of beacon nodes carries a 51% attack risk.

The programmer noted that protocols employ various protective measures. For example, Lido uses a whitelist, and Rocket Pool allows a node to be launched only after depositing 8 ETH (a quarter of capital) as a stake. In Buterin’s view, none of these approaches is without drawbacks. He believes it is sensible to enshrine some ‘in-protocol functionality’ that would make liquid staking less centralised. However, it remains unclear what exactly this solution should be.

Buterin reminded that precompiles are Ethereum contracts that implement complex cryptographic operations, the logic of which is implemented in the client code. This compromise approach originally allowed reducing the EVM overhead for some complex applications, solving part of the tasks in the core code, making them faster.

According to the programmer, work is currently underway to add precompiles for the elliptic curve secp256r1. In recent years there have been attempts to integrate contracts for BLS-12-377, BW6-761 and a number of other functions.

An argument against adding more precompiles is that many of them have been used far less often than expected. Buterin acknowledged that there exist certain cryptographic operations, valuable for acceleration, that are worth including in the protocol. Perhaps some of the existing contracts should be retired, he added.

He highlighted several takeaways from considering the possibility of including the discussed functions in the Ethereum protocol:

• enshrining could reduce centralisation risks in several areas;
• too broad an integration could lead to excessive burden on consensus and governance, and overly complicate the code;
• in the long term, an undesirable consequence is the unpredictability of user needs.

«Which functions should be included in the protocol, and which should be left to other layers of the ecosystem — this is a difficult compromise, and we should expect that it will continue to evolve over time as our understanding of users’ needs and the set of available ideas and technologies grows,» concluded the programmer.

As reported in September, Buterin outlined timelines for addressing the centralisation issue in Ethereum.