Challenges for Eth1
The major technical challenges facing Ethereum in the coming years are as follows:
- State growth management: Contract creators can pay the storage allocation cost once and expect their data to be kept permanently. This has caused the storage to grow to a size that the typical handheld device can no longer store, and is even getting difficult for standard desktop computers to manage. The mid-term risk is that participation in the network will become the purview of big mining farms, which in turn presents a major collusion risk;
- Feature adoption: Adding new precompiles and features has seen a lot of healthy pushback by client maintainers. Adding a new feature means that said feature needs to be properly understood and correctly implemented by all client maintainers. This is a rather difficult task, especially considering that client teams are typically understaffed;
- Network maintenance: An issue which is correlated to the previous one. As research interests switches to Eth2, few people are left behind to keep maintaining the network until Eth2 is production-ready;
- Privacy: A concern, which is always difficult to address in a public ledger;
- User experience paradigm shift in Eth2: A lot of details are currently still being discussed, nonetheless it’s already apparent that Eth2 introduces an important change in the user experience, which will represent a non-trivial step-up in difficulty for all Eth1 users.
How it works
Like regular precompiles, during the execution of the code of a contract, a call can be made to some special contract. This contract is special because:
- The functionality it offers is needed by many contracts, so it makes sense not to duplicate the same code over and over;
- This contract is written in such a way that its execution is faster than it would be if the same code had been written in EVM bytecode (i.e. with solidity or vyper).
In the present case, this special contract is written in Wasm. Why Wasm? Because the code for a given precompile can be written only once, and then be available everywhere (that is, in every client).
The main focus is to bring about a change in ÐApp development paradigm, similar to Eth2. This works by providing developers with the tools to handle off-chain most of what is currently done on-chain. It greatly helps with scalability, since only the minimal amount of data necessary to preserve the safety properties of a blockchain (generally a 32-byte hash) is retained on-chain. On top of that, most of the updates to that data is handled by precompiles, so development, execution costs and maintenance are also greatly simplified.
Advantages of this approach
- Easy to implement: as a host of Wasm interpreters are available, written in a variety of languages. Client integration is therefore straightforward and a Geth-based prototype already exists.
- New features, fast: only one Wasm program needs to be validated, which can subsequently be dropped as-is into each client and work without effort.
- No lock-in: If clients are dissatisfied with the execution speed of Wasm, they can take their time to rewrite the precompile in their favorite language; the Wasm file can then be used to validate the output of “native” precompiles.
- Fairer gas schedules: there is a single, instruction-based reference for each clients. This provides unbiased arguments for a gas schedule change, as data from the benchmarking of the Wasm precompile are easily published and scrutinized.
- Focus on layer 2 or stateless solutions: those precompiles focus on cryptographic primitives and proof verification, which opens up the possibility of reducing each contract’s state to only 32 bytes.
- A UX closer to that of Eth2: precompiles are very similar to the Eth2 concept of execution environments (EE). Among other things, Eth2 EE will be Wasm-based. Introducing Wasm precompiles will provide for a smooth transition to the heavy paradigm shift that Eth2 is.
- Execution speed: News flash: Wasm is slower than native. There is currently a lot of research going on, not least of all in the ewasm team, to explore areas for speedup.
- Risk of precompile overload: Everybody want their code to be added as a precompile, in order to have their code subsidized. This predates Wasm precompiles and client maintainers are accustomed to pushing back on such proposals. There is no reason for this to change. See relevant question in the FAQ.
- A third issue is the potential for reinventing the wheel, as e.g. some topics are very close to those of Eth2. Care is taken to avoid redundancies.
Case study: proof verification
As part of this project, several implementations addressing Eth1 challenges have been offered, on which more details will be published shortly. In this section, I will outline how a proof verification precompile would help implement a stateless version of the ERC20 standard.
As seen in Figure 1, an on-chain contract only stores the root of a merkle tree representing the accounts. Note that on this figure, the arbitrary choice of a linear storage space has been made.
When a user wants to update their account, they need to provide the merkle proof of the current state of their account. The contract receives this proof, verifies that it corresponds to the root currently stored, update the accounts, recalculate the root and updates it.
As a result, since proof calculation is gas-intensive, there is a great advantage to use a precompile to handle this very repetitive task. Note that the precompile would be used for more than just ERC20 tokens as this system can also be applied to other layer 2 solutions. And since there is more than one ERC20 token anyway, it justifies its inclusion as a precompile.
What’s the point? Isn’t that very close to Eth2? Or stateless clients? Or <name your favorite project> ?
It certainly has similarities (and is inspired from) all of the above. The advantage is that the amount of work needed to implement it is minimal, and at the same time it paves the way for the advent of these technologies.
Can you add my precompile?
We can’t turn everything as a precompile. Precompiles should be understood as a factorization of code that would otherwise be duplicated among many contracts. As a rule of thumb, to be considered by the community, candidates will have to demonstrate:
- Having (many) more than one application;
- A relevance to either a) cryptographic primitives, b) proof verification or c) layer 2 solutions
Expect as much push-back from client maintainers as currently.
Is there a connection with the ewasm team’s previous work on precompiles?
Yes. This work is a continuation. It is currently still at the prototype stage and I made different, incompatible design choices in order to extract more performance. If this project is successful, the result will be merged back.