以太坊Purge階段需要清除什麼

最近的 Dencun 硬分叉中不太知名的 EIP 之一是EIP-6780，它刪除了操作碼SELFDESTRUCT的大部分功能。

該EIP是以太坊協議開發中經常被低估的部分的關鍵範例：透過消除複雜性和添加新的安全保證來簡化協議的努力。這是我所說的"PURGE"的一個重要部分：精簡以太坊和清除技術債的專案。將會有更多的EIP具有類似的精神，因此值得了解EIP-6780如何實現的目標，以及未來Purge中可能會清除哪些其他EIP。

EIP-6780如何簡化以太坊協定？

EIP-6780對SELFDESTRUCT的功能進行了微調，它將銷毀合約的操作碼限制為僅當該合約存在交易期間才執行。這可以防止濫用SELFDESTRUCT合約銷毀功能，以及清空程式碼和儲存而導致的潛在問題。儘管這並沒有強制執行更嚴格的規範，但它引入了兩個新變數來實現：交易期間是否存在、合約是否正在被呼叫。這項變更確保了合約只能在同一交易期間內創建合約並簽訂協議，以實現更高的可靠性。

1、EIP-6780 後，單一區塊中可以編輯的儲存槽數有最大數量（大致為：gas limit / 5000）。

2、如果合約在交易或區塊開始時具有非空代碼，則在該交易或區塊結束時它將具有相同的代碼。

之前，這些不變量都不是True：

1、SELFDESTRUCT擁有大量儲存槽的合約可以在單一區塊內清除無限數量的儲存槽。這將使Verkle樹的實作變得更加困難，並且使以太坊客戶端的實作變得更加複雜，因為它們需要額外的程式碼來有效地處理這種特殊情況。

合約的程式碼可以透過SELFDESTRUCT從非空變為為空，實際上合約甚至可以在之後立即使用不同的程式碼重新建立。這使得帳戶抽像中的交易驗證更加困難，因為交易驗證需要使用交易中的程式碼庫而不容易受到DoS攻擊的影響。

現在，這些不變量都是True，使得建​​立以太坊用戶端和其他類型的基礎設施變得更加容易。幾年後，希望未來的EIP能夠完成這項工作並SELFDESTRUCT完全消除。

哪些其他「purges」正在進行？

• Geth 最近刪除了數千行程式碼，刪除了對pre-merge PoW網路的支援。

• 這個EIP正式體現了這樣一個事實：我們不再需要程式碼來擔心「空帳戶」（請參閱：EIP-161 ，它引入了這個概念作為上海DoS 攻擊修復的一部分）

• Dencun 中blob 的儲存視窗為18 天，這意味著以太坊節點只需要約50 GB 來儲存blob 數據，並且此數量不會隨著時間的推移而增加

前兩個顯著改善了客戶端開發人員的體驗。後者顯著提高了節點運營商的壽命。

還有哪些其他可能需要Purge的東西？

預先編譯（Precompiles）

預先編譯是以太坊合約，它沒有 EVM 程式碼，而是具有必須由客戶端自己直接實現的邏輯。這個想法是，預編譯可用於實現無法在 EVM 中有效實現的複雜形式的密碼學。

如今，預編譯的使用非常成功，特別是透過橢圓曲線預編譯啟用基於 ZK-SNARK 的應用程式。然而，還有其他很少使用的預編譯：

• RIPEMD-160：引入哈希函數是為了支援與比特幣更好的兼容性

• Identity：傳回與其輸入相同的輸出的預編譯

• BLAKE2：引入哈希函數是為了支援與Zcash 更好的兼容性

• MODEXP引入非常大的模冪以支援基於RSA 的加密

事實證明，對這些預編譯的需求遠低於預期。 Identity被廣泛使用，因為它是複製資料最簡單的方法，但自從 Dencun 以來，操作碼MCOPY已經取代了它。不幸的是，這些預編譯都是共識錯誤的巨大來源，也是新 EVM 實現的巨大痛苦來源，包括 ZK-SNARK 電路、形式驗證友善的實現等。

有兩種方法可以刪除這些預編譯：

• 只需刪除預編譯即可，例如。 EIP-7266刪除了 BLAKE2。這很簡單，但會破壞任何仍在使用它的應用程式。

• 將預編譯替換為執行相同操作的 EVM 程式碼區塊（儘管不可避免地會產生更高的 Gas 成本），例如。本草案 EIP就是為了身分預編譯而這麼做的。這比較困難，但幾乎肯定不會破壞使用它的應用程式（除非在極少數情況下，新 EVM 程式碼的 Gas 成本超過了某些輸入的區塊 Gas 限制）

Historical Blocks (EIP-4444)

Today, every Ethereum node is expected to store all historical blocks permanently. 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 question that needs to be solved is: if the old history is not stored by each node, then what is used to store it? 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 a very "overkill" way to achieve this permanence.

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 greatly increase the number of people willing to be nodes. EIP-4444 can also reduce node synchronization time, which also simplifies the workflow for many node operators. Therefore, EIP-4444 can greatly improve the decentralization of Ethereum nodes. 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:

The log was originally introduced to enable applications to record information about events on the chain in order to decentralize Applications (dapps) can easily query 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 can remove the bloom filter and simplify the LOG opcode so that all it does is create a value that puts the hash value 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 topic, and applications that require logging and want decentralization can use these separate protocols.

Moving to SSZ

Today, much of Ethereum’s block structure (including transactions and receipts) is still stored using an outdated 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):

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

• Comparison with the current six-branch Merkle Patricia tree Merkle proofs are 4x shorter in most cases than in most cases receipt output)

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

• For ZK-SNARK use cases, it is usually possible to reuse the surrounding binary Existing implementations of Merkle tree construction

• Today, three types of cryptographic data structures exist 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 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.

以上是以太坊Purge階段需要清除什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！