What needs to be cleared during the Ethereum Purge phase?

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

This EIP is a key example of an often underestimated part of Ethereum protocol development: the effort to simplify the protocol by removing complexity and adding new security guarantees. This is an important part of what I call "PURGE": projects to streamline Ethereum and clear out technical debt. There will be more EIPs in a similar spirit, so it's worth understanding how EIP-6780 achieves its goals and what other EIPs may be cleared in future purges.

How does EIP-6780 simplify the Ethereum protocol?

EIP-6780 fine-tunes the functionality of SELFDESTRUCT, which limits the opcode to destroy a contract to only be executed when the contract exists during a transaction. This prevents abuse of the SELFDESTRUCT contract destruction function and potential problems caused by clearing code and storage. While this does not enforce a stricter specification, it does introduce two new variables: whether it exists during the transaction and whether the contract is being called. This change ensures that contracts can only be created and agreements signed within the same trading period for greater reliability.

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 the same code at the end of that transaction or block.

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.

The code of a contract can be changed from non-null to empty via SELFDESTRUCT, and in fact the contract can even be recreated with different code immediately afterwards. This makes transaction verification in the account abstraction more difficult, as transaction verification requires using the code base in the transaction without being vulnerable to DoS attacks.

Now, these invariants are True, making it easier to build Ethereum clients and other types of infrastructure. In a few years, hopefully a future EIP will finish the job and SELFDESTRUCT be eliminated completely.

What other "purges" are going on?

• Geth recently removed thousands of lines of code, removing support for pre-merge PoW networks.

• 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 a Shanghai DoS attack fix Part of)

• The storage window for blobs in Dencun is 18 days, which means that Ethereum nodes only need about 50 GB to store blob data, and this amount will not increase over time The addition of

along with the first two significantly improves the client developer experience. The latter significantly increases the longevity of node operators.

What other things may need to be purged?

Precompiles

Precompiles are Ethereum contracts that do not have EVM code, but have 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 rarely used precompilations:

• RIPEMD-160: Hash functions were introduced to support better compatibility with Bitcoin

• Identity: Precompilation that returns the same output as its input

• BLAKE2: Introduced The hash function is to support better compatibility with Zcash

• MODEXPIntroducing very large modular exponentiation to support RSA-based encryption

It turns out that the demand 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 opcode MCOPY 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:

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

• Replace precompilation with a block of EVM code that does the same thing (although inevitably at a higher gas cost), e.g. 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)

歷史區塊 (EIP-4444)

如今，每個以太坊節點都有望永久儲存所有歷史區塊。長期以來，人們一直認為這是一種非常浪費的方法，並且由於高儲存要求而使得運行以太坊節點變得不必要的困難。在 Dencun 中，我們引入了 blob，它只需要儲存約 18 天。使用EIP-4444，一段時間後，以太坊區塊也將從預設以太坊節點中刪除。

需要解決的一個關鍵問題是：如果舊歷史記錄並沒有被每個節點存儲，那麼用什麼來儲存它呢？實際上，區塊瀏覽器等大型實體將會這麼做。然而，要使 p2p 協定來儲存和傳遞該資訊也是可能的，而且並不困難，這對於任務來說更加最佳化。

以太坊區塊鏈是永久性的，但要求每個節點永遠儲存所有資料是實現這種永久性的一種非常「矯枉過正」的方式。

一種方法是針對舊歷史的簡單點對點torrent網路。另一種是針對以太坊使用進行更明確優化的協議，例如入口網站網路。

或者，以迷因格式：

減少運行以太坊節點所需的儲存量可以大幅增加願意做節點的人數。 EIP-4444 也可以減少節點同步時間，這也簡化了許多節點營運商的工作流程。因此，EIP-4444可以大幅提高以太坊節點的去中心化。潛在地，如果每個節點預設儲存一小部分歷史記錄，我們甚至可以像今天一樣在網路上儲存每個特定歷史記錄的大致相同數量的副本。

日誌改革

直接引用這個EIP草案：

日誌最初的引入是為了讓應用程式能夠記錄有關鏈上事件的信息，以便去中心化應用程式（dapp）能夠輕鬆查詢這些資訊。使用bloom過濾器，dapp 將能夠快速瀏覽歷史記錄，識別包含與其應用程式相關的日誌的幾個區塊，然後快速識別哪些單一交易具有所需的日誌。

實際上，這種機制太慢了。幾乎所有存取歷史記錄的 dapp 最終都不是透過對以太坊節點（甚至遠端託管節點）的 RPC 調用，而是透過集中式額外協定服務。

我們可以做什麼？我們可以刪除bloom過濾器，並簡化LOG操作碼，這樣它所做的就是建立一個將雜湊值放入狀態的值。然後，我們可以建立單獨的協議，使用ZK-SNARK 和增量可驗證計算（IVC）來產生可證明正確的“日誌樹”，它表示給定的所有日誌的易於搜尋的表topic，以及需要日誌和想要的應用程式去中心化可以使用這些單獨的協定。

轉向SSZ

如今，以太坊的大部分區塊結構（包括交易和收據）仍然使用基於RLP和 Merkle Patricia 樹的過時格式進行儲存。這使得開發使用該數據的應用程式變得不必要的困難。

以太坊共識層已轉向更乾淨、更有效率的SimpleSerialize (SSZ)：

資料來源：https://eth2book.info/altair /part2/building_blocks/merkleization/

但是，我們仍然需要完成轉換，並將執行層移至相同的結構。

SSZ 的主要優點包括：

• 規格更簡單、更清楚

• 與現況的六叉Merkle Patricia 樹相比，大多數情況下Merkle 證明的長度縮短了4 倍

• 與極長的最壞情況相比，Merkle 證明的長度有界（例如，證明合約程式碼或長收據輸出）

• 無需實現複雜的位元操作程式碼（RLP 需要）

• 對於ZK-SNARK 用例，通常可以重複使用圍繞二元Merkle 樹建構的現有實作

如今，以太坊中存在三種類型的加密資料結構：SHA256 二元樹、SHA3 RLP 雜湊清單和十六進位Patricia 樹。一旦我們完成向 SSZ 的過渡，我們將只剩下兩個：SHA256 二元樹和 Verkle 樹。從長遠來看，一旦我們在SNARKing 雜湊方面做得夠好，我們很可能會用使用SNARK 友善雜湊（一種適用於所有以太坊的加密資料結構）的二進位Merkle 樹來取代SHA256 二元樹和Verkle樹。

The above is the detailed content of What needs to be cleared during the Ethereum Purge phase?. For more information, please follow other related articles on the PHP Chinese website!