賬戶抽象旨在改善整個以太坊生態系統中的用戶和開發者體驗。它不僅使鏈上用戶體驗更加易於使用和順暢，還使開發者能夠在以太坊上實現更強大的功能，並以更加有意義的方式為用戶提供服務。

我們將賬戶抽象的方法進行了如下分類：

1. EOA增強/可編程性：這一方法包括協議層面的變化，使 EOA（外部擁有賬戶）能夠重新定義其有效性規則中的執行邏輯部分。EOA 是通常與最終用戶相關聯的賬戶。因此，相較於現有的管理方式，屬於此方法的解決方案將賦予終端用戶更多控制權，使其能夠授權更多類型的操作。
2. EOA轉換/遷移：這一方法包括一些提案，旨在將 EOA 完全轉換為 CA（合約賬戶）。這一方法的核心思想是，合約賬戶已經提供了智能賬戶大多數的優勢，因此無需再將事情複雜化；每個人應簡單地使用合約賬戶作為其主要賬戶（通過智能合約錢包）。

這種方法提供了使 EOA 過渡到 CA 的機制，而無需轉移其資產，例如 EIP 7377 和 EIP 5003（當與 EIP 3074 一起考慮時）。

1. 智能賬戶：這類提案包括允許 EOA 和 CA 表現為“智能賬戶”的設計，這些設計是通過使它們能夠完全重新定義其有效性規則來實現這一點的。

先前已提出了多種創建智能賬戶和在協議層面實施賬戶抽象的提案；EIP-86 和 EIP-2938 是其中被引用較多的幾個。然而，這一設計曾遭遇了較大的反對，是因為它帶來的複雜性，以及人們認為以太坊尚未準備好應對這種複雜性。

在合併後，Vitalik 重新提出了這個話題，ERC-4337 被提議作為智能賬戶標準的可選版本，類似於 MEV（最大可提取價值）的 PBS（提議者-構建者分離）架構。因此，用戶如果希望訪問智能賬戶的優勢，可通過 ERC-4337 管道來重新定義賬戶邏輯和交易的有效性規則，這些結構稱為 UserOperation（簡稱 UserOps）。

ERC-4337 不需要引入複雜性就能將智能賬戶的優勢帶入現有的以太坊，作為智能賬戶的協議外替代方案。然而，這並不意味著該基礎設施在現有狀態下是最優的，因為其本身的複雜性仍然是一個潛在的故障點。

為了應對這一複雜性，草擬了 RIP 7560 作為以太坊及其 L2 網絡上 ERC-4337 基礎設施的正式版本，使其繼承網絡的 Sybil 抗性機制，而不必重新定義一套新的規則（如 ERC-4337 與 RC 7562 所做的那樣）。

在本報告中，我們將重點探討 EOA 的可編程性，評估描述這一方向解決方案的各種 EIP，並討論它們的優缺點。在本系列的第二部分和第三部分中，我們將涵蓋以太坊正在探索的賬戶抽象的另外兩種方法類別。

以太坊賬戶與交易概述

要探討什麼可以進行抽象化處理，我們首先需要對當前的賬戶設計有一個（較為）完整的瞭解。本節將主要回顧以太坊賬戶實際情況，介紹它們的交易是如何被驗證和執行的。

以太坊賬戶是存有以太幣（ETH）餘額並能夠在以太坊區塊鏈上發送交易的實體。賬戶通過一個 42 字符的十六進制“地址”表示，該地址是賬戶資產和交易的唯一標識。

地址充當區塊鏈狀態樹的入口鍵。該狀態樹的葉節點是賬戶數據結構，可以被分解為以下四個字段：

1. nonce： 一個線性計數器，用於表示賬戶發起的外部交易的數量。它在防止重放攻擊方面也起著至關重要的作用。
2. balance： 賬戶擁有的以太幣（ETH）數量，以 wei 為單位表示。
3. codeHash： 賬戶中包含的 EVM 可執行代碼的哈希。EVM（以太坊虛擬機）是以太坊的專用執行環境，負責處理除了簡單的“發送”交易之外的複雜狀態轉換。賬戶的代碼內容是不可變的，並被編程為執行特定類型的狀態轉換。
4. storageHash： 賬戶存儲根的哈希，用於表示賬戶存儲內容，作為一個 256 位哈希值，代表 merkle patricia 樹的根節點。簡單來說，它是與賬戶代碼內容相關的狀態變量數據的哈希。

這四個字段的內容用於定義賬戶的類型，並最終決定其功能的範圍。因此，以太坊的賬戶可以分為以下兩種類型：

1. 外部擁有賬戶（EOAs） - 通過加密密鑰對初始化：
   • 一個私鑰，它是一個可加密且可證明隨機的 64 字符十六進制數；
   • 其對應的公鑰，通過使用 ECDSA（橢圓曲線數字簽名算法）從私鑰導出。

EOAs 的 codeHash和 storageHash字段為空，只能由持有私鑰的人控制。其地址可以通過將“0x”前綴加到賬戶公鑰的 keccak-256 哈希後的最後 20 個字符來獲得。

1. 合約賬戶（CAs） - 只能由已存在的 EOA 創建。它們是由於 EOA 在 EVM 上部署可執行代碼內容而被初始化的。這個代碼內容（存儲為 codeHash）被寫入 EVM 中，並負責通過定義其邏輯和交互來控制賬戶。

它們的交易完全基於拉取模式，並且以其已部署代碼的邏輯為前提。
由於這些賬戶只能通過其代碼內容進行控制，因此它們不需要私鑰，僅有公鑰。因此，任何能夠更新或更改合約賬戶代碼內容的代理人，都能訪問其餘額。
CA 的地址是通過其創建者的地址和合約部署時的 nonce 派生出來的。

交易

我們剛剛將賬戶描述為能夠在以太坊上發送交易的實體。因此，可以理解，賬戶的一個主要功能就是發送和接收交易，而區塊鏈則充當著記錄交易歷史的賬本，並描述交易如何根據區塊鏈協議規範的規則改變賬戶字段。

那麼，“交易”到底是什麼呢？

交易是從賬戶發出的操作，導致網絡“狀態”的變化。它們是由賬戶加密簽名的指令，執行時會更新整個網絡狀態。

無許可性伴隨著扭曲激勵的風險，必須定義嚴格的準則（或有效性規則）來應對這種環境中的交互。

在此背景下，交易必須遵循一定的有效性規則，才能被視為有效並執行。大多數有效性規則是通過對發送交易的賬戶施加約束來實現的，並且這些規則會根據賬戶類型的不同而有所變化。

賬戶與交易有效性

在以太坊上，外部擁有賬戶（EOAs）是為終端用戶優化的賬戶類型。它們能夠以特定的方式發送交易，並且能夠完全自主地運作。EOAs 還可以在本地創建，常見的方式是通過使用如MetaMask、Rainbow、Rabby 等錢包服務提供商。

另一方面，合約賬戶（CAs）只能發送其邏輯允許的交易，並且只有在被“調用”時才會發送交易。此外，合約賬戶只能由擁有足夠餘額支付其狀態存儲費用的 EOA 創建。

從更高層次來看，EOAs 僅能持有餘額，而 CAs 既可以持有餘額，又可以持有邏輯，用以決定如何使用這些餘額。

這些屬性是由以下邏輯參數決定的，這些參數定義了賬戶交易必須遵循的規則：

1. 身份驗證邏輯：用於定義賬戶如何在改變餘額和/或邏輯時向網絡證明其身份。
2. 授權邏輯：用於定義賬戶的訪問權限，即誰有權訪問和更改賬戶的餘額和/或邏輯。
3. nonce邏輯：定義賬戶交易的執行順序。
4. Gas 支付邏輯：用於定義誰負責支付交易的 Gas 費用。
5. 執行邏輯：用於定義賬戶可以發送哪些形式的交易，或定義交易如何執行。

這些參數對 EOAs 而言是嚴格的，因此：

• 身份驗證和授權是通過基於 ECDSA 的私鑰提供的，即用戶希望從 EOA 發送交易時，必須使用其私鑰來訪問賬戶，從而證明其有權對餘額執行任何變動。
• nonce 邏輯實現了一個順序計數器機制，每個唯一的 nonce 只能按順序執行一次交易。
• Gas 支付邏輯規定，交易的 Gas 費用必須由發送方/發起賬戶結算。
• 執行邏輯規定，EOAs只能發送以下幾種交易形式：

1. 兩個 EOAs 之間的常規轉賬。
2. 合約部署。
3. 針對已部署合約賬戶邏輯的合約調用。

更廣泛地說，EOAs 的執行邏輯限制了它們每個有效簽名只能發送一次交易。

另一方面，CAs 在這些參數上更加靈活：

• 身份驗證不是必需的，因為它們的交易本質上是基於結果/拉取的。
• CAs 的授權可以有兩種形式：

1. 能夠“調用” CAs 的內容代碼（或執行其智能合約），這取決於賬戶智能合約的邏輯及其不變性。
2. 能夠更改 CAs 的內容代碼，這主要取決於代碼內容是否可升級。

在大多數實際情況中，使用的邏輯是多簽名方案，該方案規定，必須由特定賬戶（通常是EOAs）提供有效的 M 簽名（M < N），才能使對 CA 邏輯的更改有效。

• 它們的交易順序是鬆散地基於 nonce 的。CA 本身可以向儘可能多的不同調用者發送儘可能多的交易，但每個調用者因其自身能力而受到限制。
• Gas 支付通常由調用 CA 邏輯的調用者處理。
• CAs 的執行邏輯更加多樣化，可改進用戶體驗，如多重調用交易和原子交易。

評估這些特性後，我們觀察到，每種類型的賬戶都在自治性和可編程性之間做出了權衡。

• EOAs 具有完全的自治性，但可編程性有限；它們可以隨時授權併發送交易，但這些交易必須遵循嚴格的格式才能被認為是有效的。
• CAs 擁有完全的可編程性（僅受 EVM 設計的限制），但自治性有限；它們的交易不需要遵循任何嚴格的格式，但只能在其邏輯被首先調用時發送。

在接下來的小節中，我們將研究這些設計選擇的影響，從而充分理解本系列中討論的每個 EIP 的提案。

以太坊賬戶困境

現在我們對不同類型賬戶的功能有了相對簡明的瞭解，我們可以更容易地理解它們的優點以及它們對以太坊用戶體驗和開發者體驗所帶來的問題。

正如我們之前提到的，EOAs（外部擁有賬戶）是面向終端用戶的一級賬戶。應用程序設計上便於與 EOAs 進行交互，幾乎沒有複雜性，創建一個 EOA 也沒有成本。然而，它的簡易性也帶來了顯著的侷限性，因為它們是嚴格確定性的設計。

與 EOAs 相關的一些問題有：

1. 易受量子攻擊——它們的密鑰對所使用的 ECDSA 簽名方案並不具備抗量子攻擊的能力，並且樂觀的預期是量子計算工業系統在 5 到 10 年內可能實現，這對以太坊及其應用構成了重大威脅，因為以太坊及其應用嚴重依賴 ECDSA 方案來進行加密證明和安全性保障。
2. 缺乏表達性——EOAs 的有效性規則格式嚴格，無法使用戶通過諸如交易原子性、批量處理和交易委託等功能，更簡潔地表達他們的交易。
3. 自我維持能力差——每個人都經歷過“我在交易過程中沒了Gas”的情況。這是因為 EOA 需要自己支付交易的 Gas 費用，如果以太幣（ETH）不是唯一可接受的 Gas 貨幣，這個問題其實不會這麼嚴重。雖然這是基於賬戶的狀態機（甚至是基於 UTXO 的狀態機）的普遍問題，但以太坊的初衷是有所不同的。

不是每個人都想（或者能夠）一直持有 ETH（看看那價格波動），所以可行的解決方案是要麼允許多種 Gas 貨幣（但這太複雜了，會打破“貨幣”部分描述的多個不變性），要麼允許由不是交易來源賬戶的其他賬戶結算 Gas 費用。

另一方面，合約賬戶（CAs）主要面向開發者和更技術化的用戶群體。它們作為智能合約的載體（即我們認為智能合約是其包含的邏輯或代碼內容），因此可以實現由 EVM 支持的新型交易格式。

然而，儘管具備這些特性，CAs 仍然是被美化的二級賬戶，因為它們沒有自主性。它們有如下一些缺點：

• 完全缺乏自主性——CAs 無法主動發起交易，它們只能在以特定方式被調用後，響應性地發送交易。
• 邏輯上容易出錯——缺乏嚴格性往往會導致錯誤定義不變性和其他邏輯，這導致了由於智能合約漏洞和黑客攻擊而造成的數十億美元損失。然而，這是一個幾乎完全不同的話題，超出了本討論的範圍。

在回顧了導致本小節所定義問題的設計選擇之後，我們現在可以繼續評估提出的解決方案。

賬戶抽象時間表

賬戶抽象的概念（至少是通過智能賬戶）一直是以太坊路線圖的重要組成部分。傳說中，其實現所涉及的複雜性曾威脅到以太坊的發佈進度，因此它被放棄，取而代之的是當前的設計，不同類型的賬戶提供不同的功能。隨著以太坊將重點轉向“合併”（The Merge），這一概念再次被推遲，而如今它作為網絡下一個重大升級——Pectra 的核心部分重新浮出水面。然而，它的複雜性仍被視為一個重大缺點，導致其無法得到正式確立，尤其是以太坊已經轉向了以 Rollup 為中心的路線圖。

當前的要求可以總結為兩方面：

1. 賬戶標準必須更加具備表達性，但不能失去自主性。需要一種新的標準，能夠明確劃分 EOA（外部擁有賬戶）和 CA（合約賬戶）標準之間的界限。
2. 新標準必須彌合 EOA 和 CA 之間的差距，同時保持與以太坊及其 L2 生態系統的充分兼容性。

直觀來看，這一概念在鏈抽象和互操作性的背景下扮演著更重要的角色，但我們在本報告中僅討論實現賬戶抽象的技術舉措。

賬戶抽象旨在將 EOA 和 CA 的最佳特性結合成一種新的賬戶標準——智能賬戶。這種智能賬戶允許完全或部分地將賬戶的有效性規則分離為驗證邏輯和執行邏輯；使賬戶能夠像合約賬戶一樣定義自己的有效性規則——在 EVM 允許的範圍內，同時又能像外部擁有賬戶一樣保持完全的自主性。

常常有人將智能賬戶和智能合約錢包混淆，不明白它們之間的區別，因此我們將在下文明確描述這兩者的差異：

智能賬戶是以太坊賬戶的一種設計理念，旨在實現編程靈活性和自主性的平衡。其理念是， EOA 和 CA 都可以通過某些機制（例如 ERC 4337）變成智能賬戶，這些機制允許它們根據需要用定製的有效性規則替換由網絡強加的有效性規則。

另一方面，智能合約錢包只是作為合約賬戶接口的錢包提供者（是的，錢包並不是賬戶）。

智能合約錢包的商業化推動了 CA 在更廣泛市場的普及，使得技術門檻較低的用戶能夠利用其功能。然而，它們仍然面臨與 CA 相關的固有問題。

回到之前的討論；我們曾討論過用於定義賬戶交易有效性規則的參數：

• 身份驗證
• 授權
• 隨機數邏輯
• Gas 支付邏輯
• 執行邏輯

前四個參數的值可以統稱為賬戶的驗證邏輯，這些驗證邏輯是在交易執行開始之前進行的檢查。

最後一個參數定義了交易執行的方式。

在介紹部分，我們通過對各種提議設計進行某種分類，概述了當前賬戶抽象（AA）領域的整體情況。接下來，我們將重點關注以太坊賬戶困境的第一類解決方案——EOA 可編程性。

可編程 EOA（外部擁有賬戶）

以太坊最大的吸引力在於其新興且充滿活力的 DeFi 生態系統，該生態系統包含多種去中心化應用（DApp），它們是主要的流動性匯聚點。多數去中心化應用（DApps）都優化為服務外部擁有賬戶（EOAs），因此難以與合約賬戶（CAs），也就是智能賬戶，進行交互。雖然智能合約錢包在這種情況下可以幫助 CAs，但它們也有自身的侷限性，而且提供的用戶體驗完全不同。

在 DApp 和錢包提供商逐漸適應智能賬戶標準的過程中，正在探索一種過渡性解決方案，即為 EOA 提供臨時增強功能，使其能夠克服大部分限制，無論是驗證邏輯還是執行邏輯。

下面，我們將介紹三項主要的 EIP（以太坊改進提案）規範，這些提案為 EOA 的可編程性提供了可操作的路徑；從較少被關注的 EIP 5806，到雄心勃勃的 EIP 3074，再到最終取得勝利的 EIP 7702。

通過EIP-5806實現可編程性

該提案旨在通過允許外部擁有賬戶（EOA）執行委託調用（delegate call）來擴展其功能，使其能夠調用合約賬戶（CA）的邏輯（即智能合約）。這實際上使得智能合約在調用方 EOA 的上下文中執行，也就是說，EOA 依然掌控驗證邏輯，而執行邏輯則由相應的 CA 的邏輯處理。

在進一步討論之前，讓我們回到 EIP-7，回顧一下以太坊演進的歷史。

EIP-7 提議創建 0xf4/DELEGATECALL 操作碼，用於在調用主賬戶時使用輔助賬戶的邏輯，同時保持主賬戶的 [sender] 和 [value] 字段的值不變。

換句話說，主賬戶“繼承”（或者如果你願意，可以稱為借用）次賬戶的邏輯，並在指定的消息調用期間內執行，這樣次賬戶的邏輯就在主賬戶的上下文中被執行。

這個操作碼使得 DApp 開發者可以將應用邏輯拆分到多個智能合約中，同時保持相互依賴性，從而輕鬆繞過代碼大小和 gas 費用的限制。

EIP-5806 概述

那麼，委託調用如何讓合約賬戶（CAs）相互依賴呢？EIP-5806 以 EIP-7 為靈感，提出了將委託調用功能擴展到外部擁有賬戶（EOAs）的建議；也就是說，讓我們允許 EOAs 也與 CAs 互相依賴，因為為什麼不呢。

規範

EIP 5806 引入了一種新的符合 EIP-2718 的交易類型，具體內容如下： rlp([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, signature_y_parity, signature_r, signature_s])

這些交易設計使得 [to] 字段——表示接收方地址——只能接受 20 字節的地址輸入，從而禁止發送方使用 CREATE 操作碼。

RLP 方案中每個組件的動機如下：

• chainID：當前鏈的符合 EIP-115 標準的標識符，填充為 32 字節。這個值提供了重放攻擊保護，防止在原鏈上的交易在歷史相似但經濟安全性較低的其他 EVM 鏈上被輕易複製。
• nonce：每筆交易的唯一標識符，同樣提供重放攻擊保護。
• max_priority_fee_per_gas 和 max_fee_per_gas：分別表示 EIP-5806 交易為排序和包含支付的 gas 費用。
• gas_limit：單個 5806 類型交易可以消耗的最大 gas 量。
• destination：交易的接收方。
• data：可執行的代碼內容。
• access_list：有條件授權執行 EIP-5806 交易的代理。
• signature_y_parity, signature_r, signature_s：三個值共同表示對消息的 secp256k1 簽名 —— keccak256 (TX_TYPE || rlp ([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list]))。

雖然 EIP-5806 交易被封裝在 EIP-2718 信封中，使其在很大程度上兼容舊版，但 EOA 與 CA 並不等同。因此，必須在 EOA 使用委託調用時定義某些限制，以防止破壞不變性。

這些限制主要針對以下操作碼：

• SSTORE/0x55：該操作碼允許賬戶將一個值保存到存儲中。在 EIP-5806 交易中對此操作碼進行了限制，以防止 EOA 通過委託調用設置或訪問存儲，從而避免未來因賬戶遷移而可能出現的問題。
• CREATE/0xF0, CREATE2/0xF5 和 SELFDESTRUCT/0xFF：這些操作碼允許調用者創建新賬戶。對這些操作碼的訪問進行了限制，以防止 EOA 在執行 EIP-5806 交易時，因合約創建/銷燬等操作改變其 nonce 值，進而使得交易的連續性受到破壞。

潛在適用性/用例

EIP 5806 的主要適用場景是外部擁有賬戶（EOAs）的執行抽象。允許 EOAs 無需信任即可與智能合約進行交互，超越簡單的調用合約邏輯，從而為它們提供以下功能：

• 條件性執行交易
• 交易批處理
• 多重調用交易（例如：批准並調用）

批評意見

EIP-5806 提出的變化，雖然啟用了所需的功能，但並不特別創新；它的存在大多基於已經有效的 EIP-7。這使得它可以繞過許多可能的接受障礙。

其中一個早期提出的主要擔憂是，允許外部擁有賬戶（EOAs）像當前的合約賬戶（CAs）一樣訪問並修改存儲數據的潛在風險。這打破了網絡上關於 EOAs 如何進行交易的許多固定規則，因此通過引入前面小節中提到的限制來處理這一問題。

第二個批評（有點像雙刃劍）是 EIP-5806 的簡單性；有一種觀點認為，接受 EIP-5806 所帶來的回報可能不足以彌補其成本，因為它只啟用了執行抽象，而沒有更多的功能。與其他類似的 EIP 相比，接受 EIP-5806 後，所有其他有效性限制仍然由網絡定義，而不是像其他類似提案那樣提供更多的功能。

通過EIP-3074實現可編程性

EIP-3074 提議允許外部擁有賬戶（EOAs）將大部分驗證邏輯委託給專門的合約賬戶，稱為‘調用者（invokers）’，通過將調用者的授權邏輯覆蓋在自己的驗證邏輯上，來處理特定形式的交易。

它通過將其訪問策略的簽名授權給一個 invoker 合約來實現這一點，之後該合約就負責定義 EOA 的訪問策略。

此 EIP 提議向以太坊虛擬機（EVM）中添加兩個新的操作碼：

• [AUTH]：該操作碼通過基於第二個賬戶的 ECDSA 簽名，設置一個上下文變量 [authorized] 賬戶，授權該賬戶代表另一個 [authority] 賬戶執行操作。
• [AUTHCALL]：該操作碼允許通過 [authorized] 賬戶從 [authority] 賬戶發起/執行調用。

這兩個操作碼使得 EOA 可以將控制權委託給一個預先建立的合約賬戶（CA），從而通過該合約賬戶行事，而無需部署一個合約，避免了部署合約所帶來的成本和外部影響。

規範

EIP-3074 允許交易使用 [MAGIC] 簽名格式，以防止與其他交易簽名格式發生衝突。傳遞 [AUTHCALL] 指令的活動賬戶被定義為一個上下文變量字段 [authorized]，該字段只在一個交易內存在，並且必須在每次新的 [AUTHCALL] 中重新定義。

在理解每個操作碼的複雜性之前，先來了解 EIP-3074 交易中涉及的實體：

• [authority]：主簽名賬戶，通常是外部擁有賬戶（EOA）。該賬戶將控制權委託給第二個賬戶，通常是合約賬戶（CA）。
• [authorized]：該賬戶是執行 [AUTHCALL] 指令的目標賬戶，代表 [authority] 執行邏輯，並遵循 [invoker] 定義的約束條件。
• [invoker]：子合約，負責管理 [authorized] 賬戶與 [AUTHCALL] 邏輯之間的交互，尤其是當 [authorized] 合約的主要邏輯涉及 gas 資助時。

調用者合約接收來自 [authority] 的 [AUTH] 消息及其 [COMMIT] 值；該值定義了賬戶希望對 [authorized] 執行 [AUTHCALL] 指令時施加的限制。

因此，調用者合約負責確保在 [authorized] 賬戶中定義的 [contract_code] 不存在惡意行為，並且能夠滿足由主簽名賬戶在 [COMMIT] 值中定義的不變性。

[AUTH] 操作碼有三個棧元素輸入；簡而言之，它由三個輸入計算一個輸出。這些輸入為：

• authority：EOA的地址，用於生成簽名
• offset
• length

後兩個輸入用於描述一個從 0 到 97 的可修改內存範圍，其中：

• [memory(offset : offset+1)] – [yParity]
• [memory(offset+1 : offset+33)] – [r]
• [memory(offset+33 : offset+65)] – [s]
• [memory(offset+65 : offset+97)] – [COMMIT]

變量 [yParity]、[r] 和 [s] 共同解釋為 ECDSA 簽名 [magic]，它基於 secp256k1 曲線和以下消息生成：

[keccak256 (MAGIC || chainID || nonce || invoker address || COMMIT)]

其中：

• [MAGIC] 是 ECDSA 簽名，由以下變量組合而成：
  • [chainID]：當前鏈的 EIP-115 兼容標識符，用於在歷史相似且經濟安全性較低的替代 EVM 鏈上提供重放攻擊保護。
  • [nonce]：交易簽名者地址的當前 nonce 值，左填充為 32 字節。
  • [invokerAddress]：包含 [AUTH] 執行邏輯的合約地址。
  • [COMMIT]：一個 32 字節的值，用於指定在調用者預處理邏輯中額外的交易有效性條件。

如果計算出的簽名有效且簽名者地址與 [authority] 相同，[authorized] 字段將更新為 [authority] 提供的值。如果這些要求未得到滿足，[authorized] 字段將保持其先前的狀態，或作為未設置值。

該操作碼的 gas 費用計算為以下各項的總和：

• 固定費用，包括 [ecrecover] 預編譯和額外的 keccak256 哈希及一些附加邏輯，總計 3100 單位。
• 內存擴展費用，計算方式類似於 [RETURN] 操作碼，當內存超出當前分配的指定範圍時（97 單位）。
• 為了防止因誤定價的狀態訪問操作碼而發生攻擊，[AUTH] 操作碼有一個固定費用：對於熱的 [authority] 賬戶為 100 單位，對於冷的 [authority] 賬戶為 2600 單位。

[AUTH] 被設計為不修改內存，並將 [authority] 的值作為參數，因此可以輕鬆驗證其簽名。

[AUTHCALL] 操作碼

[AUTHCALL] 操作碼有七個棧元素輸入，用於計算一個棧元素輸出。其邏輯與 [CALL] 操作碼相同；即，它用於向賬戶發送消息調用並觸發其合約中的特定邏輯。唯一的不同之處在於， [AUTHCALL] 被設計為在執行前先設置 [CALLER] 的值。

因此， [AUTHCALL] 由 [authority] 用來在 [authorized] 中觸發特定上下文的行為，執行過程中的邏輯檢查如下：

1. 檢查 [authorized] 的值。如果未設置，則認為執行無效，立即退出當前框架。這有助於防止由於前所未有的失敗而產生不公平的費用。
2. 檢查 [authorized] 預期行為的 gas 費用。
3. 檢查 [gas] 操作數是否符合 EIP-150 的規範值。
4. 檢查 [authority] 賬戶餘額中是否有足夠的總 gas 費用 [value]。
5. 執行時，從 [authority] 的餘額中扣除 [value]。如果 [value] 超過其餘額，則執行無效。

[AUTHCALL] 的 gas 費用由以下部分組成：

• 固定費用：調用 [warm_storage_read]。
• 內存擴展費用：計算方式類似於 [CALL] 操作碼的 gas 費用。
• 動態費用 [dynamic_gas]。
• 子調用執行費用 [subcall_gas]。

[AUTHCALL] 返回的數據通過以下方式訪問：

• [RETURNDATASIZE] – 將返回數據緩衝區的大小推送到輸出棧。
• [RETURNDATACOPY] – 將數據從返回數據緩衝區複製到內存。

為了簡化技術細節，通常以兩種方式指定以太坊交易的值：

• tx.origin：提供交易的授權。
• msg.sender：交易實際發生的賬戶。

在 EOA 中，如前所述，授權與執行緊密結合，即（tx.origin == msg.sender）。這一簡單的不變性導致了報告中“賬戶與交易有效性”小節所討論的大多數問題。

[AUTH] 消息來自 [authority]，允許將 tx.origin 功能偏移到 [authorized]，而保持 msg.sender 不變。它還允許使用 [COMMIT] 值定義對這一權限的限制。

[AUTHCALL] 允許 [authorized] 訪問合約邏輯，通過 [invoker] 作為中介，確保其訪問的合約無害。也就是說，每個 [AUTHCALL]，[authorized] 必須為其 [COMMIT] 指定一個特定的 [invoker]。

潛在適用性/用例

EIP-3074 主要用於允許 EOA 將其授權邏輯委託給不同的賬戶，但其開放設計在不同的上下文中能夠實現更多功能。

EOA 的整個驗證邏輯可以通過應用必要的約束/創新來抽象化，基於目標邏輯的一些可能設計包括：

• Nonce 邏輯：EIP-3074 允許在發送 [AUTH] 消息後，EOA 的 nonce 保持不變，而每個 [AUTHCALL] 的 nonce 則取決於它與哪個 invoker 交互。這樣，它支持 EOA 的 nonce 並行性，使得它們可以根據需要發送多個互不重疊的 [AUTHCALL]。
• Gas 費用支付邏輯：如 EIP 中所述，invoker 可以被設計為支持 gas 贊助。因此，用戶的 [COMMIT] 的 gas 費用可以從交易的 origin 賬戶或任何支持賬戶（無論是個人賬戶還是服務型中繼，如 gas 贊助服務）中扣除。
• 執行邏輯直觀地被抽象化；畢竟，invoker（作為一個合約賬戶）現在負責代表 EOA 執行交易請求。

批評意見

• 調用者合約的中心化問題

正如其一位作者所言：“我不希望錢包暴露出可以授權任意調用者的功能…”。EIP-3074 所帶來的最大問題之一是，在其基礎上創新可能很容易導致許可化和專有的交易流程，就像當前以太坊的 MEV 和 PBS 市場的演變一樣。

默認情況下，調用者合約需要經過廣泛的審計，以防止比目前更嚴重的攻擊。這不可避免地會導致一個生態系統，其中只有少數由有影響力人物開發的調用者合約會被錢包開發者作為默認選項採用。因此，這就變成了一個權衡問題：是在不斷審計和支持調用者合約的過程中，承擔用戶安全風險，還是選擇採用來自已建立和信譽良好的來源的調用者合約，這些合約對用戶安全有更好的保障，同時對合約安全的監督較少。

這一點的另一個方面是，與設計、審計和推廣一個功能性和安全的 invoker 相關的成本問題。較小的團隊幾乎總是會被更大的組織超越——尤其是在營銷方面——即便他們的產品更好，較大的組織由於已有一定的聲譽，通常更容易獲得成功。

• 向前兼容性問題

EIP-3074 使 ECDSA 簽名機制更加根深蒂固，因為它仍然被認為比通過 invoker 引入的授權機制更有效。儘管有一些觀點認為量子抗性目前不是一個確定的問題，而且在未來 ECDSA 可能被攻破的情況下，實際上面臨的風險更大；以太坊的目標通常是始終走在這些問題前面。為了獲得在用戶體驗上的微小改進，可能犧牲量子抗性和審查抗性，並不是近未來的最佳選擇。

關於向前兼容性的問題，在 EIP-3074 的好處尚在評估時，ERC-4337（無需任何協議更改）已經取得了一個良好的市場，因此你也必須兼容它，以避免生態系統的隔離。而且即使在本地賬戶抽象的路線圖中，[AUTH] 和 [AUTHCALL] 操作碼最終會在 EVM 中變得過時，給以太坊帶來大量的技術債務，來換取用戶體驗的微小改善。

• ECDSA 方案的不可逆性

在發送 [AUTH] 消息並委託控制後，EOA 必須避免使用常規的私鑰授權方案，因為發送“普通”交易會導致其委託給每個調用者的授權被撤銷。

因此，ECDSA 方案仍然優於任何其他授權方案，意味著私鑰丟失會導致賬戶資產的完全喪失。

通過 EIP-7702 進行編程

通過 EIP-7702 實現可編程性

該提案最初作為 EIP 3074 的一個簡化變種提出，甚至旨在作為其更新版本。它的誕生是為了應對 EIP 3074 的一些效率問題，特別是它與已經蓬勃發展的 4337 生態系統以及原生賬戶抽象提案 RIP 7560 的不兼容性問題。

它的設計方法是引入一種新的符合 EIP 2718 的交易類型——[SET_CODE_TX_TYPE]，使得 EOA（外部擁有賬戶）能夠在指定交易中表現為智能賬戶。

此設計不僅實現了與 EIP 5806 相同的功能，還提供了更多功能，同時與原生賬戶抽象路線圖和現有提議保持兼容。

規範

EIP-7702 允許 EOA 通過 [SET_CODE_TX_TYPE] 2718 規範交易導入合約的代碼內容，交易格式為：

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

此負載與 EIP 5806 非常相似，唯一的不同是它引入了一個“授權列表”。該列表是按順序排列的值，格式為：

[[chain_id, address, nonce, y_parity, r, s], ...]

其中每個元組定義了 [address] 的值。

在進行下一步操作之前，涉及 [SET_CODE_TX_TYPE] 的各方為：

• [authority]：EOA/主要簽名賬戶。
• [address]：包含可委託代碼的賬戶地址。

當 [authority] 簽署一個指定 [address] 的 [SET_CODE_TX_TYPE] 時，便會創建一個委託設計者。這是一個“指針程序”，它使得所有由於 [authority] 的操作而導致的代碼檢索請求都會被引導到 [address] 可見的代碼中。

對於每個 [chain_id, address, nonce, y_parity, r, s] 元組，7702 類型交易的邏輯流程如下：

1. 使用 authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s) 驗證 [authority] 的簽名。
2. 通過驗證鏈的 ID 來防止跨鏈重放攻擊和其他攻擊向量。
3. 檢查 [authority] 是否已經有代碼內容。
4. 檢查 nonce，確保 [authority] 的 nonce 等於元組中包含的 nonce。
5. 如果這是 [authority] 的第一次 SET_CODE_TX_TYPE 交易，則收取 PER_EMPTY_ACCOUNT_COST 費用。如果其餘額低於此費用，操作將被放棄。
6. 發生委託指定，其中 [authority] 的代碼被設置為 [address] 的指針。
7. 簽名者 [authority] 的 nonce 增加 1。
8. [authority] 被加入到一個列表——已訪問地址。該列表（簡化版）是一個地址集合，進入其範圍的交易會使這些地址恢復到先前的狀態，如同未進入該範圍一樣。這是根據 EIP-2929 定義的，用於緩存可重複使用的值並防止不必要的費用。

簡而言之，這個 EIP 允許 EOAs 發送交易，設置指向合約代碼的指針，使它們在後續交易中能夠實現此邏輯。因此，它比 EIP 5806 更強大，因為它允許 EOAs 持有代碼內容，直到它們希望為止（而 EIP 5806 僅允許 EOAs 發送委託調用）。

潛在適用性/用例

• 執行抽象化

雖然可以爭論說它不再是一個抽象，因為 EOA 積極地選擇它希望執行的邏輯，但它仍然不是該邏輯的‘主要擁有者’。此外，它並不直接包含邏輯，而只是指定了指向邏輯的指針（以減少計算複雜度）。所以我們仍然稱之為執行抽象！

• Gas 贊助

儘管 require(msg.sender == tx.origin) 不變式被打破以允許自我贊助，但該 EIP 仍然允許集成贊助交易中繼。需要注意的是，這些中繼需要一個基於聲譽或股份的系統來防止惡意攻擊。

• 條件訪問策略

EOAs 只能指向賬戶代碼的特定部分，從而使得只有該部分的邏輯可以在其上下文中執行。

這還使得子密鑰的存在成為可能，從而實現“權限降級”，確保特定的 dApp 僅在特定條件下能夠訪問賬戶餘額。例如，你可以設想一個權限，允許支出 ERC-20 代幣但不允許支出 ETH，或者每日至多支出總餘額的 1%，或僅與特定應用交互。

• 跨鏈智能合約部署

由於其非限制性的性質，EIP-7702 交易可以允許用戶訪問 CREATE2 操作碼，並使用它將字節碼部署到某個地址，而無需其他限制性參數（如費用市場邏輯，例如 EIP-1559 和 EIP-4844）。這使得該地址可以在多個狀態機中恢復並使用相同的字節碼，其中每個鏈上的賬戶負責定義其他上下文變量參數。

批評意見

• 缺乏向後兼容性

儘管 EIP-7702 仍然非常新，但其依賴項和潛在缺點已經進行了大量原型設計和測試。由於其極簡主義的模型，它在不同的上下文中具有很大的靈活性和實用性。然而，它打破了許多不變式，並且不立即向後兼容。

其中的一些邏輯包括：

* **交易中途 EOA nonce 修改**：EIP-7702 不限制任何操作碼，以確保一致性。這意味著 EOA 可以在執行 EIP-7702 交易時實現 CREATE、CREATE2 和 SSTORE 等操作碼，從而允許其 nonce 在不同的上下文中增加。
* **允許非零 codeHash 值的賬戶作為交易發起者**：EIP-3607 的實施是為了減少 EOA 和 CA 之間的“地址碰撞”潛在影響。地址碰撞發生在 EOA 的地址與 CA 的地址完全相同時。大多數用戶對賬戶的實際內容（甚至對賬戶和地址之間的區別）並不熟悉，因此允許地址碰撞意味著 EOA 可以偽裝成 CA，吸引用戶資金並最終竊取這些資金。EIP-3607 通過規定包含代碼的賬戶不能使用自己的授權邏輯來花費其餘額來解決這個問題。然而，EIP-7702 打破了這一不變式，使得即使獲得了一些可編程性，EOA 仍能保持自主性。

• 與 EIP-3074 的相似性

簽署賬戶地址而不是其代碼內容實際上類似於 3074 中使用的調用者方案。它沒有提供嚴格的跨鏈代碼內容一致性保證，因為一個地址在不同鏈上的代碼內容可能不同。這意味著一個在某條鏈上包含相同邏輯的地址，在另一條鏈上可能是掠奪性或完全惡意的，這可能導致用戶資金的損失。

結語

目前的 EOA（外部擁有賬戶）形式受限，無法讓用戶充分利用 EVM 提供的可編程功能。雖然我們在本報告開始時概述了多種升級賬戶的路徑，但選擇的解決方案必須保持安全、可靠的自主管理原則。此外，EOA 升級可能會顯著影響用戶體驗和應用開發者，因此必須考慮所有利益相關者的聲音。

允許 EOA 以任何方式執行代碼極大地擴展了賬戶的功能，但這種新型的可表達性也帶來了實際的風險和可能的盲點。解決這些權衡對於為以太坊用戶提供一個無可爭議的更好用戶體驗（UX）至關重要。

以太坊的開放討論文化使其成為這種創新的絕佳試驗場，因為幾乎每個設計的每個影響都被領域專家徹底解構。這樣的全面考慮有助於減輕來自對手的不當行為風險。

EIP-7702 目前是將 EVM 可編程性引入 EOA 的典型機制，被視為替代 EIP 3074 在 Pectra 升級中的位置。它繼承了 3074 機制的開放設計，同時大幅降低了攻擊面和風險。它還通過避免 3074 對某些操作碼類別的限制，實現了更多功能。

儘管該提案的設計仍在進行一些完善，但它已經獲得了開發者的大量支持，尤其是因為它得到了 Vitalik 的支持。

在社區中，有觀點認為這種賬戶抽象方式可能比智能賬戶更優。這一評論強調，這種方式需要更少的變動，且不如智能賬戶複雜，同時 EOA 已經得到認可。然而，我們必須牢記以太坊網絡各層級未來的量子抗性安全目標。由於 EOA 授權使用基於 ECDSA 的簽名方案，當前賬戶模型核心無法實現這一量子安全性。

因此，EOA 的可編程性應被視為邁向智能賬戶的一個步驟，而非終點。它為 EOA 提供了更強大的功能，提升了用戶和開發者體驗，同時與最終的智能賬戶目標保持兼容。

在我們的下一個報告中，我們將深入探討 EOA 遷移方案，看看它們在賬戶抽象路線圖中的適配程度，敬請關注！

免責聲明：

1. 本文轉載自【2077.xyz】，所有版權歸原作者【zhev】所有。若對本次轉載有異議，請聯繫Gate Learn 團隊，他們會及時處理。
2. 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
3. Gate Learn 團隊將文章翻譯成其他語言。除非另有說明，否則禁止複製、分發或抄襲翻譯文章。