Vitalik: EIP-6780 is a key step in simplifying the Ethereum protocol

Author: Vitalik Translation: Shan Oppa, Golden Finance

One ​​of the lesser-known EIPs from the recent Dencun hard fork is EIP-6780, which removes much of the functionality of the opcode SELFDESTRUCT.

This EIP is a key example of an often underestimated part of Ethereum protocol development:by removing complexity and addingnewSecurity guarantees to simplify protocol efforts. This is an important part of what I call "cleaning": projects that streamline Ethereum and clear out technical debt. There will be more EIPs in a similar spirit, so it's worth understanding how EIP-6780 in particular achieves its goals, and what other EIPs there might be in the future.

How does EIP-6780 simplify the Ethereum protocol?

EIP-6780 reduces the functionality of the opcode SELFDESTRUCT, which destroys the contract that calls it and clears its code and storage, so It is only valid if the contract is created during the same transaction. This in itself does not reduce the complexity of the specification. However, it does improve the implementation by introducing two new invariants:

1. After EIP-6780, there is a maximum number of storage slots that can be edited in a single block (roughly: gas limit / 5000).

2. If the contract has a non-empty code at the beginning of a transaction or block, it will have a non-null code at the end of that transaction or block Same code.

Previously, none of these invariants were true:

1. SELFDESTRUCTContracts with a large number of storage slots can clear an unlimited number of storage slots within a single block. This will make the implementation of Verkle trees more difficult and make Ethereum client implementations more complex as they will require additional code to handle this special case efficiently.

2. The code of the contract can change from non-empty to empty SELFDESTRUCT. In fact, the contract can even change after Instantly recreate with different code. This makes transaction verification in account abstraction wallets more difficult to use the code base without being vulnerable to DoS attacks.

These invariants are now all correct, making building Ethereum clients and other type of infrastructure becomes easier. In a few years, it is hoped that future EIPs will be able to complete this work and SELFDESTRUCT be eliminated entirely.

What other "purges" are happening?

• Geth recently removed thousands of lines of code, removing support for the pre-merged (PoW) network support.

• This EIP officially embodies the fact that we no longer need code to worry about "empty accounts" (see: EIP- 161, which introduced this concept as part of the Shanghai DoS attack repair)

• The storage window for blobs in Dencun is 18 days, which Meaning that an Ethereum node only needs about 50 GB to store blob data, and this amount will not increase over time

The first two significantly improve client developers' lives. The latter significantly increases node operator lifespan.

What else might need to be cleared?

Precompilation

Precompilation is an Ethereum contract, which does not have EVM code, but Has logic that must be implemented directly by the client itself. The idea is that precompilation can be used to implement complex forms of cryptography that cannot be efficiently implemented in the EVM.

Today, the use of precompilation is very successful, especially to enable ZK-SNARK based applications through elliptic curve precompilation. However, there are other precompilers that are rarely used:

• RIPEMD-160 : The hash function is introduced to support better compatibility with Bitcoin

• Identity

  code>: A precompilation that returns an output identical to its input

• BLAKE2: The introduction of hash functions is In order to support better compatibility with Zcash

• MODEXP introduces very large modular exponentiation to support based on Encryption with RSA

It turns out that the need for these precompilations is much lower than expected. Identity is widely used because it is the easiest way to copy data, but since Dencun, the operation MCOPY code has replaced it. Unfortunately, these precompilations are a huge source of consensus bugs and a huge source of pain for new EVM implementations, including ZK-SNARK circuits, formal verification friendly implementations, etc.

There are two ways to remove these precompilations:

1. Just remove the precompilation, eg. EIP-7266 removed BLAKE2. This is simple, but will break any application still using it.

2. Replace precompilation with a block of EVM code that does the same thing (although inevitably at a higher Gas cost), For example. This draft EIP does this for identity precompilation. This is more difficult, but will almost certainly not break applications that use it (unless in rare cases the gas cost of the new EVM code exceeds the block gas limit for some inputs)

ol>

History (EIP-4444)

Today, every Ethereum node is expected to permanently store all Historical block. This has long been considered a very wasteful approach and makes running an Ethereum node unnecessarily difficult due to high storage requirements. In Dencun, we introduced blobs, which only need to be stored for about 18 days. With EIP-4444, after a period of time, Ethereum blocks will also be removed from the default Ethereum node.

A key issue that needs to be solved is: if the old history is not stored by each node, then what is used to store it? Woolen cloth? In fact, large entities such as block explorers will do this. However, it is also possible and not difficult to make a p2p protocol to store and transfer this information, which is more optimized for the task.

The Ethereum blockchain is permanent, but requiring each node to store all data forever is an overkill to achieve this permanence Way.

One ​​approach is a simple peer-to-peer torrent network for old history. The other is a protocol more explicitly optimized for use with Ethereum, such as the Portal Network.

Or, in meme format:



Reducing the amount of storage required to run an Ethereum node can Dramatically increase the number of people willing to do so. EIP-4444 can also reduce node synchronization time, which also simplifies the workflow for many node operators. Therefore, EIP-4444 can greatly improve Ethereum’s node decentralization. Potentially, if each node stored a small portion of history by default, we could even store roughly the same number of copies of each specific history on the network as we do today.

Log reform

Quote directly from this EIP draft:

Logs were originally introduced to enable applications to record information about on-chain events so that decentralized applications (dapps) can Easily look up this information. Using bloom filters, a dapp will be able to quickly browse the history, identify several blocks that contain logs relevant to their application, and then quickly identify which individual transactions have the required logs.

Actually, this mechanism is too slow. Almost all dapps that access history end up not through RPC calls to Ethereum nodes (or even remotely hosted nodes), but through centralized additional protocol services.

What can we do? We could remove the bloom filter and simplify the LOG opcode so that all it does is create a value that puts the hash into the state. We can then build a separate protocol that uses ZK-SNARKs and incremental verifiable computation (IVC) to generate a provably correct "log tree" that represents an easily searchable table of all logs given a topic< /code>, and applications that need logging and want decentralization can use these separate protocols.

Moving to SSZ

Today, most of Ethereum’s block structure (including transactions and receipts) are still stored using an obsolete format based on RLP and Merkle Patricia trees. This makes it unnecessarily difficult to develop applications that use this data.

The Ethereum consensus layer has moved to the cleaner and more efficient SimpleSerialize (SSZ):



< em>Source: https://eth2book.info/altair/part2/building_blocks/merkleization/

However, we still need to complete the conversion, and move the execution layer to the same structure.

The main advantages of SSZ include:

• The specification is simpler and clearer

• Compared with the current six-branch Merkle Patricia tree, in most cases Merkle The length of the proof is reduced by a factor of 4

• The length of the Merkle proof is bounded compared to the extremely long worst-case scenario (e.g., Prove contract code or long receipt output)

• No need to implement complex bit manipulation code (required for RLP)

• For ZK-SNARK use cases, it is often possible to reuse existing implementations built around binary Merkle trees

Today, there are three types of encrypted data structures in Ethereum: SHA256 binary trees, SHA3 RLP hash lists, and hexadecimal Patricia trees. Once we complete the transition to SSZ, we will be left with only two: SHA256 binary trees and Verkle trees. In the long term, once we get good enough at SNARKing hashes, we will most likely replace SHA256 binary trees and Verkle with binary Merkle trees that use SNARK friendly hashes (a cryptographic data structure that works for all Ethereum) Tree.