作者:Vitalik 翻譯:善歐巴,金色財經
最近的Dencun 硬分叉中不太知名的EIP 之一是EIP-6780,它刪除了操作碼的大部分功能SELFDESTRUCT。
該EIP 是以太坊協議開發中經常被低估的部分的關鍵示例:透過消除複雜性和添加新的安全保證來簡化協議的努力。這是我所說的「清理」的一個重要部分:精簡以太坊和清除技術債的項目。將會有更多的EIP 具有類似的精神,因此值得了解EIP-6780 特別是如何實現目標,以及未來可能會有哪些其他EIP。
EIP-6780如何簡化以太坊協定?
EIP-6780 減少了操作碼的功能SELFDESTRUCT,它會銷毀調用它的合約並清空其代碼和存儲,因此只有在同一交易期間創建合約時它才有效。這本身並沒有降低規範的複雜性。然而,它確實透過引入兩個新的不變量來改進實現:
-
EIP-6780 後,單一區塊中可編輯的儲存槽數有最大數量(大致為:gas limit / 5000)。
-
如果合約在交易或區塊開始時具有非空代碼,則在該交易或區塊結束時它將具有相同的代碼。
之前,這些不變量都不是真的:
-
SELFDESTRUCT擁有大量儲存槽的合約可以在單一區塊內清除無限數量的儲存槽。這將使Verkle 樹的實作變得更加困難,並且使以太坊客戶端的實作變得更加複雜,因為它們需要額外的程式碼來有效地處理這種特殊情況。
-
合約的代碼可以從非空變為空SELFDESTRUCT,事實上合約甚至可以在之後立即以不同的代碼重新建立。這使得帳戶抽象錢包中的交易驗證更難使用程式碼庫而不容易受到DoS 攻擊。
現在,這些不變量都是正確的,使得建立以太坊用戶端和其他類型的基礎設施變得更加容易。幾年後,希望未來的生態工業園區能夠完成這項工作並SELFDESTRUCT完全消除。
正在發生哪些其他「清洗」?
-
Geth 最近刪除了數千行程式碼,刪除了對預合併(PoW) 網路的支援。
-
這個EIP正式體現了這樣一個事實:我們不再需要代碼來擔心「空帳戶」(請參閱:EIP-161 ,它引入了這個概念作為上海DoS 攻擊修復的一部分)
-
Dencun 中blob 的儲存視窗為18 天,這意味著以太坊節點只需要約50 GB 來儲存blob 數據,而此數量不會隨著時間的推移而增加
前兩個顯著改善了客戶端開發人員的生活。後者顯著提高了節點操作員的壽命。
還有哪些可能需要清除的東西?
預編譯
預編譯是以太坊合約,它沒有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 限制)
歷史(EIP-4444)
如今,每個以太坊節點都有望永久儲存所有歷史區塊。長期以來,人們一直認為這是一種非常浪費的方法,並且由於高儲存要求而使得運行以太坊節點變得不必要的困難。在Dencun 中,我們引入了blob,它只需要儲存約18 天。使用EIP-4444,一段時間後,以太坊區塊也將從預設以太坊節點中刪除。
需要解決的一個關鍵問題是:如果舊歷史記錄並沒有被每個節點存儲,那麼用什麼來儲存它?實際上,區塊瀏覽器等大型實體將會這麼做。然而,要使p2p 協定來儲存和傳遞該資訊也是可能的,而且並不困難,這對於任務來說更加最佳化。
以太坊區塊鏈是永久性的,但要求每個節點永遠儲存所有資料是實現這種永久性的一種非常「矯枉過正」的方式。
一種方法是針對舊曆史的簡單點對點洪流網絡。另一種是針對以太坊使用進行更明確優化的協議,例如入口網站網路。
或者,以迷因格式:
減少運行以太坊節點所需的儲存量可以大大增加願意這樣做的人數。 EIP-4444 也可以減少節點同步時間,這也簡化了許多節點操作員的工作流程。因此,EIP-4444可以大幅提高以太坊的節點去中心化。潛在地,如果每個節點預設儲存一小部分歷史記錄,我們甚至可以像今天一樣在網路上儲存每個特定歷史記錄的大致相同數量的副本。
紀錄改革
直接引用這個EIP草稿:
日誌最初的引入是為了讓應用程式能夠記錄有關鏈上事件的信息,以便去中心化應用程式(dapp)能夠輕鬆查詢這些資訊。使用布隆過濾器,dapp 將能夠快速瀏覽歷史記錄,識別包含與其應用程式相關的日誌的幾個區塊,然後快速識別哪些單一交易具有所需的日誌。
實際上,這種機制太慢了。幾乎所有訪問歷史記錄的dapp 最終都不是透過對以太坊節點(甚至遠端託管節點)的RPC 調用,而是透過集中式額外協定服務。
我們可以做什麼?我們可以刪除布隆過濾器,並簡化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樹。