Vitalik Which functions should Ethereum solidify at the protocol layer

Author: Vitalik, Founder of Ethereum; Translator: LianGuai0xjs

From the very beginning of the Ethereum project, there has been a strong belief in keeping the Ethereum core as simple as possible and accomplishing as much work as possible by building protocols on top of it. In the blockchain field, the debate between “executing on L1” and “focusing on L2” is generally seen as mainly involving scalability. However, similar issues exist when providing services for many Ethereum user needs such as digital asset exchanges, privacy, usernames, advanced cryptography, account security, censorship resistance, and front-running protection, among others. Recently, there has been an increasing interest in cautiously formalizing more of these features into the Ethereum core protocol.

This article explores some philosophical reasoning behind the early concept of protocol minimalism in Ethereum and my more recent thoughts on these ideas. The goal is to gradually build a framework for better identifying goals where certain features might be worth considering in the protocol.

Early Protocol Minimalism Philosophy

In the early history of what was then called “Ethereum 2.0”, there was a strong desire to create a clean, simple, and elegant protocol that did as little work as possible, leaving almost everything to users to build upon. Ideally, the protocol would just be a virtual machine, and verifying a block would only require invoking the virtual machine once.

• Understanding the True Potential of the Asset Issuance Agreement RGB in One Article
• IBC Product Manager states that Ethereum Layer2 is not the holy grail of scaling.
• From Concept to Performance Is it the Spring of Humanoid Robots?

In early 2015, Gavin Wood and I made a very rough sketch of what Ethereum 2.0 might look like. The “state transition function” (the function that processes blocks) would simply be a virtual machine invocation, and all other logic would be implemented through contracts: some system-level contracts, but mainly user-provided contracts. One very nice feature of this model is that even an entire hard fork could be described as a single transaction to process blocks in a contract, which would be approved through off-chain or on-chain governance and then run with upgrade permissions.

These 2015 discussions apply particularly well to two areas we care about: account abstraction and scalability. In the case of scalability, the idea was to try and create a maximally abstract form of scalability that feels like a natural extension of the above diagram. Contracts could make calls to certain data that most Ethereum nodes do not store, and the protocol would detect this and solve the call with some very general scalability computation. From the perspective of the virtual machine, the call would go into some separate subsystem and magically return with the correct answer after some time.

This way of thinking was briefly explored but quickly abandoned because we were too focused on whether any form of blockchain scalability was possible to be verified. However, as we will see later, the combination of data availability sampling and ZK-EVM means that a possible future of Ethereum scalability might actually look surprisingly close to this vision! For account abstraction, on the other hand, we knew from the beginning that some form of implementation was possible, so we immediately started researching how to make the “transaction is just a call” pure starting point as close to reality as possible.

Here, there is a lot of code that happens between handling the transaction and making the underlying EVM calls to the sender’s address both before and after. How can we minimize this code to as close to zero as possible?

One major piece of work in a section of code is to validate_transaction(state, tx), which includes checking the transaction’s nonce and signature. The actual goal of the account abstraction from the beginning was to allow users to replace the basic nonce increment and ECDSA verification with their own validation logic, making it easier for users to use things like social recovery and multi-signature wallets. Therefore, reshaping apply_transaction to a simple EVM call is not just a task of “making the code clean for the sake of making the code clean”; instead, it is to move the logic into the user’s account code to give flexibility to the users who need it.

However, the insistence on minimizing the amount of formal logic in apply_transaction eventually introduced many challenges. To understand the reasons, let’s take a closer look at one of the early account abstraction proposals, EIP 86:

Specification

If block.number >= METROPOLIS_FORK_BLKNUM: 1. If the signature of the transaction is (0, 0, 0) (i.e., v = r = s = 0), then it is considered valid and the sender address is set to 2 ** 160 – 1. 2. The address of any contract created through a CREATE transaction is set to sha3(0 + initialization code) % 2 ** 160, where + denotes concatenation, replacing the previous address formula sha3(rlp.encode([sender, nonce])). 3. A new opcode, 0xfb, CREATE_P2SH, is created, which sets the address to sha3(sender + init code) % 2 ** 160. If a contract already exists at that address, it fails and returns 0, just as if the initialization code ran out of gas.

Essentially, if the signature is set to (0, 0, 0), then the transaction becomes “just a call”. The account itself will be responsible for the code that parses the transaction, extracts and verifies the signature and nonce, and pays the fees. Click here to see an early version of this code, and click here to see the validate_transaction code that will be replaced by this account code, which once simply reduces apply_transaction to just an EVM call. In other words, the Ethereum protocol performs transaction verification and leaves the specific transaction logic to the user’s own account code to provide flexibility.

However, the attempt to minimize the amount of formal logic in apply_transaction eventually introduced many challenges. To understand why, let’s take a closer look at one of the early account abstraction proposals, EIP 86.

Note that miners need to devise a strategy to accept these transactions. This strategy needs to be very discerning, or else they may accept transactions that don’t pay any fees (for the validate_transaction code that will be replaced by pre-account code), or even transactions that have no effect (e.g., because the transaction has already been included, so the nonce is no longer valid). One simple approach is to set a whitelist of code hashes for the account code they accept transactions to; approved code will include the logic to pay the miner’s transaction fee. However, this might be too restrictive; a looser but still effective strategy is to accept any code that conforms to the same general format mentioned above, only consuming a limited amount of gas to perform the nonce and signature checks, and ensuring that the transaction fee will be paid to the miner. Another strategy is to attempt processing any transaction requesting fewer than 250,000 gas, in addition to other methods, and include it only if the miner’s balance is appropriately increased after executing the transaction.

If EIP-86 is adopted as is, it will reduce the complexity of the EVM but greatly increase the complexity of other parts of the Ethereum stack, requiring essentially duplicating the same code elsewhere and introducing completely new strange possibilities, such as the same transaction having the same hash appearing multiple times on the chain, not to mention the issue of multiple failures.

The issue of multiple failures in account abstraction. One transaction included on-chain can invalidate thousands of other transactions in the mempool, making the mempool vulnerable to cheap flooding.

Account abstraction has evolved from there. EIP-86 became EIP-208, which later became a post on ethresear.ch about “trade-offs in account abstraction proposals,” and then, half a year later, became this post on ethresear.ch. Eventually, all of this led to the practically viable EIP-2938.

However, EIP-2938 is not minimal. The EIP includes:

• A new transaction type

• Three new transaction-scoped global variables

• Two new opcodes, including the heavy LianGuaiYGAS opcode, which handles gas price and gas limit checks, acts as an EVM execution breakpoint, and temporarily holds ETH for fee payment.

• A complex set of mining and replay strategies, including a series of disallowed opcodes in the transaction validation stage

In order to push account abstraction forward without involving the Ethereum core developers who are busy optimizing Ethereum clients and implementing the merge, EIP-2938 was eventually redesigned as the completely off-protocol ERC-4337.

ERC-4337. It does indeed rely entirely on EVM calls to do everything!

Because it is an ERC, it does not require a hard fork, technically “outside the Ethereum protocol.” So… problem solved, right? Well, it turns out not completely. The current mid-term roadmap for ERC-4337 actually involves ultimately turning most of the content of ERC-4337 into a series of protocol features, which is a useful example to understand why this path is being considered.

Protocol-Level Solidification of ERC-4337

For the eventual inclusion of ERC-4337 into the protocol, some key reasons have been discussed:

• Gas Efficiency: Any operation executed within the EVM incurs some degree of virtual machine overhead, including inefficient gas usage when using expensive features like storage slots. Currently, these additional inefficiencies add at least ~20,000 gas, and often more. Pushing these components into the protocol is the simplest way to eliminate these issues.

• Code Error Risk: If the “entry point contract” for ERC-4337 has sufficiently nasty errors, all wallets compatible with ERC-4337 may see their funds drained. By replacing the contracts with protocol features, there can be an implied responsibility to fix code errors and eliminate user fund risks.

• Support for EVM opcodes such as tx.origin. ERC-4337 itself makes tx.origin return the address of the “bundler” that packages a set of user operations into a transaction. Native account abstraction can solve this issue by making tx.origin point to the actual account that sent the transaction, just like it works for EOAs.

• Censorship resistance: In the case of PBS, one challenge is making it easier to censor individual transactions. In a world where every transaction is visible to the Ethereum protocol, this can be greatly mitigated by inclusion lists that allow proposers to specify a list of transactions that must be included in the next two slots in almost all cases. However, off-protocol ERC-4337 wraps “user operations” within a single transaction, making the user operations invisible to the Ethereum protocol; thus, the inclusion lists provided by the Ethereum protocol would not provide censorship resistance for ERC-4337 user operations. Formalizing ERC-4337 and treating user operations as “official” transaction types would address this issue.

It is worth further researching the gas efficiency issue. In its current form, ERC-4337 is significantly more expensive than “basic” Ethereum transactions: the cost of a transaction is 21,000 gas, while ERC-4337 costs about 42,000 gas. This document lists some of the reasons:

• There are many separate storage read/write costs that, for EOA, are bundled into a single payment of 21,000 gas:

• Editing storage slots containing pubkey+nonce (~5000)

• UserOperation calldata cost (~4500, can be reduced to ~2500 through compression)

• ECRECOVER (~3000)

• Pre-warming the wallet itself (~2600)

• Pre-warming the receiving account (~2600)

• Transferring ETH to the receiving account (~9000)

• Editing storage to pay fees (~5000)

• Accessing storage slots containing proxies (~2100), and then the proxies themselves (~2600)

• In addition to the above storage read/write costs, the contract also needs to execute “business logic” (uncompress UserOperation, hash it, shuffle variables, etc.), while EOA transactions are “free” in the Ethereum protocol.

• Gas needs to be spent to pay for log fees (EOA does not emit logs)

• One-time contract creation cost (base cost of ~32000, code in the proxy adds 200 gas per byte, plus 20000 gas for setting the proxy address)

In theory, it should be possible to manipulate the EVM gas cost system to match the storage access cost of protocol-internal costs and extra protocol costs; there is no reason why transferring ETH should cost 9000 gas while other storage editing operations are much cheaper. In fact, two EIPs related to the upcoming Verkle tree transition are actually attempting to do this. But even if we do that, there is a huge reason why formal protocol features will inevitably be much cheaper than EVM code, no matter how efficient the EVM becomes: formalized code does not need to pay gas for preloading.

A fully functional ERC-4337 wallet is large. This implementation, when compiled and put on the chain, takes up about 12800 bytes. Of course, you can deploy this large code once and allow each individual wallet to call it using DELEGATECALL, but the code still needs to be accessed in each block where it is used. According to the upcoming Verkle tree gas cost EIP, 12800 bytes will occupy 413 chunks, and accessing these chunks will require payment of 2x WITNESS_BRANCH_COST (total of 3,800 gas) and 413x WITNESS_CHUNK_COST (total of 82,600 gas). This doesn’t even mention the ERC-4337 entry point itself, which is 23689 bytes on-chain in version 0.6.0 (loading requires ~158700 gas according to Verkle tree EIP rules).

This leads to a problem: the actual gas cost of accessing this code must be somehow allocated between transactions. The method currently used by ERC-4337 is not ideal: the first transaction in the bundle absorbs the one-time storage/code read cost, making it obviously more expensive than the rest of the transactions. A solution to this problem is to make these commonly used shared libraries part of the protocol, accessible to everyone without having to pay fees.

What can we learn from this example about when to cement into protocols more universally?

In this example, we can learn some experience about when to abstract things more universally.

• Moving complexity to the edge is a good idea, especially when there is a high cost of cementation. This becomes apparent in the “decentralized account abstraction” roadmap, as loading standardized wallet code costs 244,100 gas, and aggregation (which requires ZK-SNARK verification, which can cost hundreds of thousands of gas, plus the on-chain cost of proof verification) would be nearly impossible for users to pay for, introducing many market inefficiencies. Having certain features as protocol features, providing access to all users without cost, can neatly solve this problem.

• A communal response to code mistakes. If a piece of code is used by all or a wide class of users, it is often more reasonable for the blockchain community to bear the responsibility of fixing errors that may arise through a hard fork. ERC-4337 introduces a significant amount of globally shared code, and in the long run, it is better to fix errors in that code through hard forks rather than causing users to lose significant amounts of ETH.

• Sometimes, directly leveraging the power of the protocol can achieve more powerful forms of functionality. For example, an audit system within the protocol can better guarantee resistance to censorship, and allowing user-level operations to truly benefit from the protocol requires the individual user-level operations to be “readable” to the protocol. Another less-known example is Ethereum’s 2017 proof of stake design that had an authority abstraction with a single authority, which was abandoned in favor of a BLS-based summary because BLS supports an “aggregation” mechanism that had to be implemented at the protocol and network level, making processing a large number of signatures more efficient.

However, it is important to remember that even the established account abstraction within the protocol is still a huge “disestablishment” relative to the status quo. Today, top-level transactions in Ethereum can only be initiated by externally owned accounts (EOAs), which use a single secp256k1 elliptic curve signature for verification. The account abstraction reflects this and provides openness for users to define verification conditions. Therefore, in this story about account abstraction, we also see the strongest argument against cementation: flexibility to meet the diverse needs of different users.

Let’s try to further refine this story by looking at some features that have recently been considered for cementation. We will specifically focus on: ZK-EVMs, proposer-builder separation, private mempools, fluid staking, and new precompiles.

Cementing ZK-EVMs

Let’s turn our attention to another potential goal for cementation in the Ethereum protocol: ZK-EVMs. Currently, we have a large number of ZK-rollups, all of which must write fairly similar code to verify Ethereum-like blocks in ZK-SNARKs. There is a fairly diverse independent implementation ecosystem: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth, and more.

One of the recent controversies in the field of EVM ZK-rollup involves how to handle the possibility of errors in ZK code. Currently, all running systems have some form of “security council” mechanism that can override the proof system in case of errors. In an article last year, I attempted to create a standardized framework to encourage projects to clarify their level of trust between the proof system and the security council, and move towards reducing the power of the security council over time.

Looking ahead, rollups can rely on multiple proof systems, and the security council would only have any power in extreme cases where the two different proof systems disagree with each other.

However, there is a feeling that some of this work is redundant. We already have the Ethereum base layer, which has an EVM, and we already have a mechanism for handling errors in implementations: if there are errors, the client with the error will update to fix the error, and the chain will continue. From the perspective of a client with an error, from the perspective of multiple implementations in the Ethereum community and off-chain social consensus, the blocks seem to eventually settle, but at least we don’t see users losing funds. Similarly, if a rollup wants to be and remain equivalent to the EVM, then when their internal ZK-EVM rules need to match upgrades in the Ethereum base layer, they should not implement their own governance, but should directly build on top of the Ethereum base layer, which knows when to upgrade and what the new rules are.

Given that these L2 ZK-EVMs essentially use the same EVM as Ethereum, can’t we somehow turn “verifying EVM execution in ZK” into a protocol feature? In case of errors and upgrades, can’t we handle the issue by applying Ethereum’s social consensus, just as we do for the base layer EVM execution itself?

This is an important and challenging topic. There are some subtleties:

1. We want to be compatible with Ethereum’s multi-client philosophy. This means we want to allow different clients to use different proof systems. This in turn means that for any EVM execution that is proven using one ZK-SNARK system, we want to ensure that the underlying data is available so that proofs can be generated for other ZK-SNARK systems.

2. While the technology is not yet mature, we may want to conduct audits. In practice, this means the same thing: if any execution is proven, we want the underlying data to be available so that if there are problems, users and developers can inspect it.

3. We need faster proof times so that if one type of proof is generated, other types of proofs can be quickly generated for other clients to verify. This can be addressed by creating a pre-compiled contract with asynchronous response after a certain time window (e.g. 3 hours), but this adds complexity.

4. We want to support not only replicas of the EVM, but also “almost-EVMs”. Innovating at the execution layer and extending the EVM is part of the appeal of L2. If a given L2’s VM is only slightly different from the EVM, it would be nice if the L2’s VM can use the local protocol ZK-EVM in the same parts as the EVM, and only rely on its own code to handle the different parts. This can be achieved by designing a ZK-EVM pre-compiled contract that allows the caller to specify a bit field or list of opcode or address ranges handled by an external table provided instead of the EVM itself. We can also make gas costs customizable to some extent.

When using native ZK-EVM, one possible controversial topic regarding data availability is statefulness. If ZK-EVMs don’t need to carry “witness” data, they will be more data-efficient. In other words, if a specific data has been read or written in a previous block, we can simply assume that the prover can access it, and we don’t need to provide it again. This is not limited to reloading storage and code; in fact, if a rollup properly compresses data and makes the compression stateful, it can save as much as 3 times the data compared to stateless compression.

This means that for ZK-EVM precompiles, we have two choices:

1. Precompiles require all data to be available in the same block. This means that provers can be stateless, but it also means that using a ZK-rollup with such precompiles is more expensive than using a rollup with custom code.

2. Precompiles allow pointers to data used or generated in previous executions. This allows ZK-rollup to be almost optimal, but it is more complex and introduces a new type of state that must be stored by the prover.

What lessons can we draw from this? There is a fairly good argument to be made for establishing ZK-EVM verification in some way: rollups are already building their own custom versions, and it feels wrong for Ethereum to put the weight of multiple implementations and off-chain social consensus on L1 EVM execution, while L2 that does the exact same work needs to implement a complex toolkit involving a security council. But on the other hand, there is a big trouble in the details: there are different versions of established ZK-EVMs with different costs and benefits. Statefulness versus statelessness is just the tip of the iceberg; attempting to support custom code “almost-EVMs” with proofs from other systems may reveal even more design space. Therefore, establishing ZK-EVMs has both hope and challenges.

Prover-Builder Separation (ePBS)

The rise of MEV has turned block production into a scale economic activity, where savvy participants can generate more revenue than default algorithms by simply monitoring transactions in the mempool and including them. The Ethereum community has so far attempted to address this issue by proposing prover-builder separation schemes outside of protocols, similar to MEV-Boost, which allows regular validators (“provers”) to outsource block construction to specialized participants (“builders”).

However, MEV-Boost introduces a trust assumption for a new category of participants called relays. Over the past two years, there have been many proposals to create “embedded PBS”. What are the benefits of doing so? In this case, the answer is very simple: PBS constructed with the power of the protocol itself is stronger in terms of trust assumptions (in the sense of weaker trust assumptions) than PBS constructed without them. This is similar to establishing a price oracle in a protocol, although there is also a strong counterargument in that case.

Establishing a Private Memory Pool

When a user sends a transaction, the transaction becomes public and visible to everyone immediately, even before it is included in the blockchain. This makes users of many applications vulnerable to economic attacks such as frontrunning: if a user makes a large transaction on Uniswap, an attacker may place a transaction before them, increasing the price they pay and profiting from arbitrage.

Recently, there have been projects specifically creating “private memory pools” (or “encrypted memory pools”) that keep users’ transactions encrypted until they are irreversibly accepted into a block.

However, this solution requires a specific type of encryption: in order to prevent users from flooding the system and running the decryption process themselves before the transaction is actually irreversibly accepted, the encryption must be able to automatically decrypt when the transaction is actually irreversibly accepted.

There are various different technologies to implement this form of encryption, each with different trade-offs, as described well by Jon Charbonneau in an article (as well as in this video and slides):

• Encryption with centralized operators, such as Flashbots Protect.

• Time-lock encryption, a form of encryption that can be decrypted by anyone after a certain number of sequential computational steps, which cannot be parallelized.

• Threshold encryption, where most of a committee is trusted to decrypt the data. See the concept of shutterized beacon chains for a concrete proposal.

• Trusted hardware, such as SGX.

Unfortunately, all of these have various weaknesses. Centralized operators are unacceptable for inclusion in the protocol for obvious reasons. Traditional time-lock encryption for running thousands of transactions in a public memory pool is too expensive. A more powerful primitive called delayed encryption allows for efficient decryption over a certain number of messages, but it is difficult to practically build and existing constructions have sometimes been found to be broken. Threshold encryption requires trusting most of a committee not to collude, which is unacceptable in settings where collusion can be undetectable (unlike 51% attacks where who is participating is immediately known). SGX introduces a dependency on a single trusted manufacturer.

While there are subsets of users willing to trust each of these solutions, there is currently no solution that is sufficiently trustworthy to be actually accepted to Layer 1. Therefore, including frontrunning as a feature in Layer 1 looks like a difficult proposition, at least until/unless delayed encryption technology improves or other technological breakthroughs occur, even though it is a highly valuable feature that many application solutions have emerged for.

Immutable Liquidity Collateral

One common demand among Ethereum DeFi users is the ability to use their ETH for collateral and as collateral in other applications simultaneously. Another common demand is simply for convenience: users want to be able to collateralize without running a node and being constantly online (and securing their now online collateral keys).

So far, the simplest “interface” to meet these two demands is an ERC20 token: convert your ETH to “staked ETH,” hold it, and then convert it back. In fact, liquidity staking providers like Lido and Rocketpool have emerged to do just that. However, liquidity staking has some inherent centralizing mechanisms at play: people naturally gravitate towards the largest version of staked ETH because it’s the most familiar and liquid (and gets the best support from applications, which in turn support it because it’s the kind most users have heard of).

Every version of staked ETH needs some mechanism to determine who can be a base node operator. It can’t be unrestricted, because attackers will join and amplify their attacks with users’ funds. Currently, the top two are Lido, which has a DAO whitelist of node operators, and Rocket Pool, which allows anyone to run a node with 8 ETH (i.e. 1/4 the capital) deposited. Both approaches have different risks: the Rocket Pool approach allows attackers to launch a 51% attack on the network and force users to foot most of the cost. With the DAO approach, if a single staked token dominates, it leads to a single, potentially attackable governance tool controlling a large portion of Ethereum’s validators. For protocols like Lido, they have implemented safeguards, but one layer of defense may not be enough.

In the short term, one option is to encourage ecosystem participants to use a diverse set of liquidity staking providers to reduce the chance of any one becoming too large and a systemic risk. However, in the long run, this is an unstable balance, and relying too much on moral pressure to solve the problem carries risks as well. A natural question arises: does it make sense to codify some kind of functionality in the protocol to reduce concentration of liquidity staking?

Here, the key question is: what protocol functionality to codify? The issue with simply creating a fungible “staked ETH” token in the protocol is that it either must have codified Ethereum global governance to choose who runs nodes, or it is open and becomes a tool for attackers.

An interesting idea is Dankrad Feist’s article on liquidity staking maximalism. First, we have to accept the fact that if Ethereum is subjected to a 51% attack, only about 5% of the attacked ETH would be penalized. This is a reasonable trade-off; there are now over 26 million ETH staked, and 1/3 of the cost of attack (around 8 million ETH) is completely redundant, especially considering how many “attack models” can be implemented with less cost. In fact, similar trade-offs have been discussed in the “supercommittee” proposal, which is used to implement single-slot finality.

If we accept that only 5% of attacking ETH will be confiscated, then more than 90% of the staked ETH will be exempt from confiscation. Therefore, 90% of the staked ETH can be placed into a protocol’s interchangeable and liquidable collateral token, which can then be used by other applications.

This approach is interesting. However, it still leaves one question: what specific things will be hardened? The operation of Rocket Pool is very similar to this: each node operator has to contribute some capital, while the liquid stakers contribute the rest of the capital. We can simply adjust some constants to limit the maximum penalty to 2 ETH, and the existing rETH in Rocket Pool will become risk-free.

Through simple protocol adjustments, we can do some clever things. For example, imagine we want a system with two “tiers” of collateral: node operators (with high collateral requirements) and depositors (with no minimum requirements and can join or exit at any time). However, we still want to empower the depositors through a randomly-sampled committee, such as for proposing transaction lists that must be included (for anti-censorship reasons), controlling fork choices during inactive leakage periods, or requiring block signing. This can be achieved by adjusting the protocol to require each validator to provide (i) a regular collateral key and (ii) a mechanism where each slot can call an ETH address to output the secondary collateral key. The protocol will grant power to these two keys, but the mechanism for selecting the second key in each slot can be left to the collateral pool protocol. Directly hardening certain things may still be a better choice, but it is worth noting that there is design space for “hardening some things and leaving others to the users”.

Hardening More Precompiles

Precompiles (or “precompiled contracts”) are Ethereum contracts that implement complex cryptographic operations natively in client code rather than in EVM smart contract code. Precompiles were a compromise adopted in the early days of Ethereum development: because the cost of the VM was too high for certain types of highly complex and specialized code, we could implement key operations that are valuable to important classes of applications natively in code to make them faster. Today, this primarily includes specific hash functions and elliptic curve operations.

Efforts are currently underway to add a precompile for secp256r1, which is a slightly different elliptic curve than secp256k1 used for basic Ethereum accounts, as it has widespread support from trusted hardware modules and may improve wallet security by being widely used. In recent years, there have also been efforts to add precompiles for features such as BLS-12-377, BW6-761, generalized pairing, and more.

The counterargument to adding more precompiles is that many of the precompiles previously added (such as RIPEMD and BLAKE) ended up being used less than anticipated, and we should learn from that. Instead of adding more precompiles for specific operations, we might focus on more modest approaches such as ideas based on EVM-MAX and dormant but always awakenable SIMD proposals, which would allow the EVM to execute a wide category of code more cost-effectively. It may even be possible to remove existing but rarely used precompiles and replace them with EVM code implementations of the same functionality. That being said, there may still be specific cryptographic operations that are highly valuable to accelerate, making it reasonable to add them as precompiles.

What can we learn from all of this?

It is understandable and good to try to minimize solidification; it comes from the Unix philosophical tradition of creating minimal software that users can easily adapt to different needs, avoiding the curse of software bloat. However, blockchain is not a personal computing operating system; they are social systems. This means that there are reasons to solidify certain functionalities in the protocol that go beyond the above personal considerations.

In many cases, these other examples reiterate similar lessons seen in the account abstraction. But there are also some new lessons that have been learned:

• Helping to avoid centralized risks in other areas of the stack. Often, keeping the base protocol simple and minimal pushes complexity out into the ecosystem around the protocol. From a Unix philosophy perspective, this is good. However, sometimes the risk in the ecosystem outside the protocol is that it may become centralized, often (but not only) due to high fixed costs. Solidification can sometimes reduce actual centralization.

• Too much solidification can overload the trust and governance burden of the protocol. This is a theme of early articles about “Don’t Overload Ethereum Consensus” (see LianGuai’s previous translation articles): if a particular functionality is solidified, it weakens the trust model and makes Ethereum as a whole more “subjective,” thereby weakening Ethereum’s credibility and neutrality. In these cases, it is better to keep that specific functionality as a mechanism above Ethereum rather than trying to bring it into Ethereum itself. In this case, the encrypted memory pool is the best example of something that may be too difficult to solidify, at least until delayed encryption technology improves.

• Too much solidification can overly complicate the protocol. Protocol complexity is a systemic risk, and adding too many functionalities to the protocol increases that risk. Precompiles are the best example of this.

• Solidification may backfire over the long term because user needs are unpredictable. Many functionalities that are considered important and will be used by many users may actually see little usage in practice.

In addition, the examples of liquidity staking, ZK-EVM, and precompiles show a middle ground possibility: minimal viable solidification. Rather than solidifying the entire functionality, it is better to solidify specific parts that address the key challenges of implementing that functionality without being overly subjective or narrow. This includes:

• Instead of solidifying the entire liquidity staking system, it is better to change the penalty rules to make trustless liquidity staking more feasible.

• Instead of solidifying more precompiles, it is better to solidify EVM-MAX and/or SIMD to make more diverse categories of operations easier to effectively implement.

• Instead of solidifying the entire concept of Rollups, we can simply solidify EVM verification.

We can extend the chart at the beginning of this article as follows:

Sometimes it may even make sense to remove some things that have become solidified. Removing infrequently used precompiles is one example. As a mechanism to support existing users in a forward-compatible manner, the mechanism to remove precompiles may actually be remarkably similar: one such mechanism is EIP-5003, which would allow an EOA to transform itself in-place into a contract with the same (or better) functionality.

Deciding which features to bring into the protocol and which ones to leave to other layers of the ecosystem is a complex tradeoff, and we should expect this tradeoff to evolve over time as our understanding of user needs and our available thoughts and technological toolkits improve.

We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!

Follow us on Twitter, Facebook, YouTube, and TikTok.