作者：shew

概述

在Pectra 升級中，出現了最複雜的治理爭端問題。當EIP3074 被納入Pectra 升級後，造成了巨大的爭論，特別是來自ERC4337 的團隊反對。

EIP3074 陷入了困境，治理流程無法繼續進行。直到Vitalik 提出EIP7702 結束了ERC4337 團隊對於EIP3074 的質疑。

GCC Research 發現對於Pectra 升級中EIP3074 和ERC7702 的治理問題在中文世界少有討論。但該治理問題也反映了以太坊治理的深層問題，即在code is law 的前提下，誰可以控制code 的具體內容。 EIP3074 和ERC7702 的治理問題可以帶給我們一個很好的視角去觀察以太坊內部的真實治理流程。

本文的最終結論是轉述自ZeroDev 發表的評論文章，該文章指出以太坊治理系統是VVRC 模型，任何一個提案的納入都需要首先符合以太坊價值觀(Value)，然後該提案應該反映在Vitalik 設計的願景(Vision) 中，最後提案應該反映到客戶端(Roadmap) 中，最後核心開發者討論後將其納入客戶端。

GCC Research 在上一篇文章中介紹的EIP2537 只是在Client 層級出現了實現問題導致最終延遲加入硬分叉，而EIP3074 則是因為Vision 和Roadmap 問題導致最終沒有被納入硬分叉，而以太坊核心開發者直接選擇了Vitalik 編寫的EIP7702 作為最終的帳戶抽象提案。

提案內容概述

在介紹具體的治理流程前，我們首先需要簡單介紹一下本文涉及EIP3074、EIP7702 和ERC4337 的具體內容。

EIP3074 是一個執行層提案，執行該提案需要節點軟體升級。 EIP3074 的核心目的是實現gas sponsoring 和批量交易的功能。所謂的gas sponsoring 是指用戶可以使用任意代幣繳納gas 費用，或者用戶可以在線上繳納gas 費用。但需要注意的，相較於其他帳戶抽象提案允許更改簽章校驗演算法，EIP3074 並不允許使用者使用secp256k1 以外的任何簽章演算法。換言之，EIP3074 並不是一個滿足所有帳戶抽像功能的提案。這也是EIP3074 備受詬病的一點。

為了實現預期目標，EIP3074 引入了兩個操作碼，分別是AUTH 和AUTHCALL。其中AUTH 操作碼可以透過校驗簽名，當簽名校驗通過後，該操作碼就會配置目前EVM 上下文中的authorized 為簽署人的位址。當配置上下文中的authorized 後，AUTHCALL 可以使用authorized 的位址作為呼叫交易的msg.sender 來發起交易。從某種程度上來說，用戶可以透過簽名將自己的帳戶在一筆交易中委託給一個智能合約使用。我們一般稱這個被用戶委託的智能合約為invoker 合約。

那用戶的具體簽名內容是什麼？用戶需要簽名如下內容:

以太坊治理戰爭：EIP3074、ERC4337與EIP7702

上述內容中的invoker address 是指用戶希望委託的invoker 合約地址，EVM 會校驗用戶簽名內容與真正校驗簽名的合約是否一致，避免用戶的AUTH 簽名內容被其他合約使用。

而nonce 是一個防止交易重播的識別。但是需要注意的時，AUTH 操作碼會校驗簽名中的nonce 與當前簽署的EOA 的nonce 是否一致，理論上只要用戶不使用EOA 帳戶發起交易增加nonce 數值，那麼用戶發出的AUTH 簽名可以一直被invoker 合約使用。這是一個巨大的安全漏洞，意味著使用EIP3074 的使用者必須信任獲得簽署的中繼服務商。若要取得使用者簽署的中繼服務商是惡意的，該服務商可能會在某一時刻重播使用者的AUTH 簽章以竊取使用者資產。

另一個具有安全問題的是commit 欄位。 commit 欄位用於確保某些操作，使用者可以在commit 內精細化控制自己的簽名權限，例如在commit 內寫入一些內容避免自己的簽名內容被用於ETH 轉帳。在EIP3074 文件內，提案人給了一系列的利用commit 欄位的範例。但是問題是commit 的作用完全依靠智能合約定義，本質是一個可選內容。不同的智能合約對commit 中內容的解析可能完全不一致，甚至可能某些合約完全不讀取commit 中的內容。假如用戶希望安全使用EIP3074 必須自己簡單審查智能合約。

最後，我們介紹一個EIP3074 對目前以太坊交易記憶體池的影響。引入EIP3074 後可能會出現一種對於記憶體池的攻擊方法，駭客可以使用大量的帳戶發起交易，然後在交易即將被打包時，使用EIP3074 交易一次性抽空這些帳戶內的ETH，這會導致之前發起的交易全部失敗。這種攻擊方式會對執行層節點造成相當大的影響，本質上就是一種DoS 攻擊。但需要注意的，用於替代EIP3074 的EIP7702 也出現了這種問題，但EIP7702 引入了一些限制避免此問題出現，我們會在後文討論。

除了上文介紹的EIP3074 本身有問題，所以ERC4337 的作者Yova 在Implications of EIP-3074 inclusion 一文中介紹了更多的反對意見。簡單來說，這些意見主要包括:

  1. 中心化風險。由於AUTH 簽署的特殊屬性，使用者必須完全信任EIP3074 的中繼服務商和底層基礎設施。同時目前ERC4337 等帳戶抽象協定所建構的基礎設施完全不相容EIP3074
  2. 用戶的安全性。如上文所述，EIP3074 沒有統一設計的權限控制方法，而且簽名nonce 設計也存在安全隱患，很有可能導致嚴重安全問題的出現
  3. 不完整的帳戶抽像功能。相較於其他帳戶抽象提案，EIP3074 並不完整，無法實作例如更換用戶簽章演算法等功能
  4. 使用者體驗存在問題。當使用者需要將自己的帳戶委託給智慧合約時，使用者需要進行一次AUTH 簽名，然後將包含AUTH 簽名的呼叫發佈到鏈上。用戶需要進行兩次簽名。

EIP7702 是由Vitalik 提出的一個用於替換EIP3074 的提案。該提案沒有引入新的EVM 操作碼，而是引入了一個新的交易類型，該交易類型稱為SET_CODE_TX_TYPE。一旦用戶發起EIP7702 類型的交易，用戶可以將自己的EOA 在保留EOA 基礎功能的前提下增加智慧合約的功能。簡單來說，使用者既可以繼續使用MetaMask 等錢包發起交易，也可以由其他使用者以智慧合約的形式呼叫EOA 位址。

我們以一個簡單的批量交易的例子介紹EIP7702 的功能。使用者可以使用EIP7702 將自己的EOA 位址委託給某一個可以執行批次呼叫的智慧合約，然後使用者可以直接以智慧合約的方式呼叫自己的EOA 位址發起批次交易。

從技術實現上來講，EIP7702 引入的交易類型的相比於傳統的交易增加了authorization_list 列表，該列表內具體內容為[[chain_id, address, nonce, y_parity, r, s], ...]。其中address 是用戶希望委託的智慧合約位址，而nonce 是用戶目前的nonce 數值。剩下的y_parity、r 和s 都是使用者的簽章結果。在具體執行過程中，我們會先遍歷authorization_list 內的每一項進行處理，處理的方法是透過y_parity 等簽章參數恢復出EOA 位址，然後將EOA 位址指向位址為address 的智慧合約。之後EOA 位址就可以接受呼叫發揮合約的功能。

EIP7702 的優點非常明顯，其中最核心的優點是EIP7702 本質上就是允許EOA 擁有智慧合約的功能。這與ERC4337 等帳戶抽象化的基本規則是一致的，這意味著EIP7702 可以利用目前帳戶抽象領域內的所有探索和復用已有基礎設施，例如EIP7702 可以直接使用ERC4337 的基礎設施。目前ERC4337 已經推出了支援EIP7702 呼叫的EntryPoint v0.8。從復用已有的基礎設施角度來看，EIP7702 與ERC4337 具有同等的去中戲化程度。

當然，EIP7702 其實並沒有完全修復EIP3074 中出現的問題。大部分EIP3074 中存在的問題依舊存在。 EIP7702 要求帳戶合約擁有安全實現，而協議本身不對任何安全進行保證。在EIP7702 提出的早期，存在某些開發者提出將簽章nonce 標準化以避免可能的重播攻擊，但是EIP7702 最後也沒有接受這些建議。所以如果用戶希望安全使用EIP7702，那麼用戶就需要自己審查合約安全性。

同時EIP7702 也會為執行層帶來一系列問題。在上文我們介紹過一個可能的利用EIP3074 對執行層記憶體池進行DoS 攻擊的一種方法。這種方法在EIP7702 也是有效的。所以EIP7702 建議所有使用EIP7702 的EOA 位址只可以在記憶體池內存在一筆待處理交易，避免大規模DoS 攻擊出現。

綜上所述，EIP3074 最大的問題是EIP3074 沒有實現完整的帳戶抽像功能，而EIP7702 實現了完整的帳戶抽象的功能。而定義「完整的帳戶抽象」包含哪些內容的正是ERC4337 的作者。讀到這裡，讀者應該可以理解為什麼EIP3074 被ERC4337 團隊反對，最後被EIP7702 取代。我們會在後文介紹整體治理和討論的全部流程。

EIP3074 和EIP7702 的治理流程

EIP3074 在以太坊核心開發者會議內提及的非常早。在2021 年4 月2 日的Meeting #109 內，以太坊核心開發者就對EIP3074 進行了簡單的討論。討論結果非常簡單:

  1. Alexey 提出EIP3074 簽章內容有安全風險，可能對使用者造成嚴重的安全損失，建議EIP3074 進一步規範AUTH 簽章的具體內容，該提議得到了Martin 的支持
  2. James 提出EIP3074 可能帶來潛在的執行層漏洞，例如DoS 攻擊等，建議EIP3074 給予書面的威脅分析
  3. Alexey 和Martin 抱怨EIP3074 文件品質一般，並花了大量時間閱讀和理解
  4. Martin 認為EIP3074 的核心是與應用，特別是錢包開發者的合作和實現，EIP3074 的作者表示已經和應用開發者進行了一系列交流

比較有趣的是，Vitalik 在這次會議中認為無論如何，以太坊需要一種為EOA 設計的交易產生多次呼叫的技術方案。雖然EIP3074 存在可能的安全性問題，但EIP3074 給出了一個可能的技術方案，開發者需要在EIP3074 的基礎上前進。

顯然，由於EIP3074 有安全問題，這次會議並沒有將EIP3074 納入London 升級。

在2021 年6 月11 日的Meeting #115 內，EIP3074 開發者提交了安全審計方面的報告，會議主要討論了EIP3074 的安全問題。一個簡單的結論是EIP3074 invoker 合約在系統內是十分重要的，所以是否需要對invoker 合約進行管理是一個問題。 EIP3074 開發者希望對invoker 合約進行形式化證明，以此增加安全性。

當然，還有部分討論關於有一些合約使用msg.sender == tx.origin 進行了調用地址是否是EOA 判斷，當EIP3074 被引入了，這些判斷都會失效，但結論是這部分判斷失效不會產生嚴重的安全問題。簡而言之，該次會議主要是EIP3074 提出者向核心開發者介紹3074 的安全審計結果。會議最終的結論是3074 還需要考慮invoker 合約問題，建議不要在London 硬分叉內加入。

在2021 年6 月25 日的Meeting #116 內，ERC4337 的核心作者Yova 提交了A case for a simpler alternative to EIP 3074 的材料，該材料指出EIP3074 存在較多安全問題，建議修改其中部分內容，比如簽名內的commit 欄位內容，commit 字段要求字段為{nonce,to,gas,calldata,value,chainid} 形式。使用此簽章模式後，EIP3074 僅可用於執行某些特定交易以確保交易的安全。

此處會議中EIP3074 的作者回應了Yova 提交的資料:

  1. 希望將invoker 合約地址納入EIP 規範，然後由以太坊核心開發者編寫一個安全的invoker 合約避免安全問題
  2. 關於簽名中commit 的內容，EIP3074 開發者認為這完全是用戶和錢包軟體方面的問題，並不需要在EIP 內進行規範

Vitalik 在此次會議中提出以下三點內容:

  1. EIP3074 仍使用了傳統的secp256k1 簽章方案無法實現抗量子特性。
  2. EIP3074 沒有未來相容性，使用EIP3074 也無法使得一個EOA 演化為智慧合約帳戶
  3. EIP3074 生命週期有限。 3074 引入了AUTH 和AUTHCALL 兩個預彙編代碼，但是按照帳戶抽象的路線圖，未來以太坊內所有的錢包都可能是智能合約錢包，EIP3074 的預彙編代碼在未來會被廢棄

在2022 年2 月4 日的Meeting #131 內，開發者討論ShangHai 升級內應該包含的EIP 類型。 EIP3074 被納入討論範圍，但開發者只是簡單同步了EIP3074 的開發動態。值得注意的，在會議開始前，nethermind 寫了Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337 一文，文章內沒有包含對EIP3074 的反對意見。

在2023 年8 月3 日的Meeting #167 內，核心開發者在討論另一個EIP5806 時提及了EIP3074。 EIP5806 是一個允許EOA 在交易過程中使用delegate call 的方式呼叫外界合約。此方案在某種程度上類似EIP7702。但核心開發者對此方案的安全性也提出了質疑，Ansgar 指出過去EIP3074 因為可能存在的安全問題一直無法被納入硬分叉，而EIP5806 是一個更激進的方案。

在2024 年2 月29 日的Meeting #182 內開發者詳細討論了EIP3074 的是否應該被納入Pectra 升級。 Vitalik 提出任何帳戶抽象標準都需要有以下三種功能:

  1. 密鑰輪換
  2. 密鑰棄用
  3. 可相容抗量子簽名

Vitalik 對指出EIP5806 可能是優於EIP3074 的選擇。 Andrew 認為EIP3074 相比於EIP5806 更通用，建議使用EIP3074。 Vitalik 對Andrew 進行了反駁，Vitalik 認為未來所有的錢包可能都是智能合約錢包，一旦此情況發生，EIP3074 引入的預彙編操作碼就會失效。 Yoav 作為ERC4337 的作者在此次會議中進行了篇幅較長的發言，其發言內容主要包括:

  1. EIP3074 可能導致對以太坊記憶體池的DoS 攻擊，而ERC4337 對這部分進行大量研究給出了一些規則避免攻擊
  2. EIP3074 在用戶發起大量交易時需要簽名兩次，這是不合理的
  3. EIP3074 要求使用中心化中繼器

Yova 更傾向於使用EIP5806 作為帳戶抽象方案。

在2024 年3 月14 日的Meeting #183 會議內部，核心開發者邀請MetaMask 的Dan Finlay 討論關於錢包對EIP3074 的看法。 Dan 對EIP3074 持贊成態度，同時指出MetaMask 也會為EIP3074 的測試提供支援。 MetaMask 認為EIP3074 在功能上可以讓EOA 享受帳戶抽象化的全部功能。在安全性上，EIP3074 為錢包服務商提供了一種方案，即冷熱密鑰分離。錢包服務商可以持有EOA 的EIP3074 簽章發起交易，用戶在正常交易中都可以使用熱私鑰，但冷私鑰可以保存在用戶的硬體錢包內，當發現緊急情況時，用戶可以使用冷錢包內的冷私鑰發起交易撤銷EIP3074 的簽章。這種冷熱私鑰分離的方案為錢包提供者帶來了靈活性。

Vitalik 指出在EIP3074 內，錢包設計者必須設計嚴格的授權邏輯，避免使用者的EIP3074 簽名被濫用。有趣的是，在討論MetaMask 增加EIP3074 功能支援時，Vitalik 指出可以使用L2 作為過渡方案，即任何新的執行層修改應該在L2 內進行率先實踐，因為L2 資金體積有限，即使發生嚴重問題也會造成嚴重損失。

Dror Tiros 在討論中指出確保EIP3074 安全的最佳方式是以太坊官方直接給定invoker 合約。但Dan Finlay 反對官方給出合約的意見，Dan 認為invoker 合約應該完全由用戶決定，市場最終會選擇出最安全的invoker 合約。

Ansgar 仍堅持EIP3074 一次簽名應該只對應一筆交易，錢包服務商不應該重複使用用戶簽章發起交易，但Dan Finlay 也表達了反對意見。 Dan Finlay 認為EIP3074 應該由冷錢包簽名，然後錢包服務商可以復用該簽名直接為用戶發起交易，假如每次都要求用戶重新簽名，可能導致冷私鑰被多次使用。這與冷熱私鑰分離的思想不符。

在此次會議中，核心開發者討論了另一個重要的主題是包含清單。包含清單是增加以太坊抗審查屬性的一種手段。簡單來說，包含清單允許一些交易被承諾直接包含在下一個區塊內。但核心開發者指出EIP3074 與包含清單是抵觸的。

在2024 年4 月11 日的Meeting #185 會議內部大部分的客戶端實作都同意EIP3074 加入Pectra 硬分叉中，但Geth 表示反對，原因是EIP3074 可能導致Verkle 樹方面的問題。 Danno 仍表示反對，因為EIP3074 可能出現簽名複用的情況。 Yoav 也表示反對，Yoav 給了一個使用EIP3074 和Blob 交易對記憶體池進行攻擊的方案。簡單來說，攻擊者可以發動大量的Blob 交易，這些Blob 交易都包含大量的數據，然後使用EIP3074 使這些Blob 交易全部失效。

簡而言之，在此次會議中，所有客戶端開發者都同意EIP3074 被納入最終的升級。

在2024 年5 月9 日的Meeting #187 內，核心開發者第一次討論EIP7702 替代EIP3074 的問題。而EIP7702 是在Vitalik 在核心開發者會議開始前90 分鐘內完成的。在會議中，核心開發者認可EIP7702 是更優於EIP3074 的標準。這次會議沒有出現對EIP7702 的反對聲音，只是存在部分研究員認為EIP7702 也存在類似EIP3074 的不可撤銷屬性，可能導致資金安全問題。

在2024 年5 月23 日的Meeting #188 會議內核心開發討論了EIP7702 替換EIP3074 的可能性。這次會議的最終結論是使用EIP7702 替換掉EIP3074 作為Pectra 硬分叉中的帳戶抽象標準。 Vitalik 指出EIP7702 也具有一些與EIP3074 一致的不可撤銷性，這些屬性在討論EIP3074 時已經得到了大量討論。比較有趣的是，會議中存在大量的ERC4337 代表參與發言。

事實上，EIP3074 被EIP7702 替換的討論在188 次核心開發者會議之前就已經被廣泛討論，當時的討論結果就是3074 會被替換，所以在核心開發者會議中並沒有大量的爭執。

路線圖與裁決

帳戶抽象的核心基礎設施Zerodev 在得知EIP3074 會被替換後，發表了一篇有趣的文章，該文章標題為Reflections on Ethereum Governance Following the 3074 Saga，這篇文章的結論是EIP7702 是一個好的提案，該提案可以使得所有用戶收益。但EIP7702 替換EIP3074 的治理流程不是最佳的，原因包括:

  1. EIP3074 經過了漫長的討論流程，在上文中我們已經介紹了EIP3074 在核心開發者會議中的多次討論
  2. EIP3074 被確定納入Pectra 升級後收到了ERC4337 社區的大量反對。當然，在上文中，我們已經指出ERC4337 的核心開發者yova 曾多次在核心開發者會議中表達自己對EIP3074 的反對

Zerodev 認為最好的治理路徑應該是在EIP3074 過去漫長的核心開發者討論過程中，ERC4337 社群應該廣泛參與並表達自己的意見。

EIP3074 開發者認為ERC4337 應該對治理失敗負責。因為EIP3074 在過去幾年積極參與治理，並多次和ERC4337 核心開發者yova 進行了交流。

而ERC4337 社群則認為EIP3074 應該對治理失敗負主要責任。 ERC4337 社群成員認為Yova 作為ERC4337 的核心開發者在多次核心開發者會議中對EIP3074 表達對反對意見，但核心開發者似乎並沒有聽取意見。 ERC4337 中大部分社群成員沒有關注EIP3074 的治理動態，大部成員都認為EIP3074 是個死掉的標準。 ERC4337 社群也認為核心開發者沒有積極與ERC4337 社群積極溝通。

EIP3074 和ERC4337 都認為自己進行了正確的治理工作，而對方應該對治理失敗負主要責任。顯然，在此次治理過程中存在著一個更深層的原因在發揮作用。

簡單來說，這個更深層的原因其實是以太坊的路線圖。以太坊路線圖具有高於核心開發者會議的權力。帳戶抽象的路線圖則是以ERC4337 為核心的。 EIP7702 完全相容ERC4337 標準，但EIP3074 沒有充分相容ERC4337 標準。所以從以太坊路線圖角度來看，EIP3074 被替換是一定會發生的。

當然，以太坊路線圖都是Vitalik 個人對以太坊未來願景的展現。以太坊在治理過程中一旦發生嚴重的爭論，那麼作為路線圖定義者Vitalik 擁有最終的裁決權。而正是Vitalik 的裁決使得EIP3074 被取代。

以太坊的治理模式是values ⇒ vision ⇒ roadmaps ⇒ clients 模型，或簡稱為VVRC 模型。其治理流程如下:

  1. values 價值觀，特別是社區的價值觀，以太坊社區的價值觀包括去中心化、抗審查等
  2. vision 願景，其實就是Vitalik 個人對以太坊未來的思考
  3. roadmaps 路線圖，研究員在願景的基礎上給出一些技術細節上的考慮給出較為完整的實現路線圖
  4. clients 用戶端實現，客戶端的核心開發者利用核心開發者會議等工具討論路線圖，並將路線圖內的需求實現

上述流程才是以太坊真正的治理流程。我們可以看到Vitalik 個人願景位於以太坊治理模式中的底層部分，所以一旦在客戶端實現內出現嚴重的爭論，Vitalik 的個人意見將進行最終裁決。

參考資料

ZeroDev Introduction

null

https://docs.zerodev.app/blog/3074-governance

ZeroDev Introduction

null

https://docs.zerodev.app/blog/4337-and-3074-disagreements

註 on the Account Abstraction roadmap - HackMD

# 註 on the Account Abstraction roadmap *Special thanks to Vitalik and the AA team for feedback

https://notes.ethereum.org/@yoav/AA-roadmap-May-2024