帳戶抽象旨在改善整個以太坊生態系統中用戶和開發者的體驗。除了使鏈上體驗更加便捷和愉悅外，它還賦能開發者在以太坊上做更強大的事情，以更有意義的方式為用戶提供服務。

我們對帳戶抽象方法的分類如下:

1. EOA增強/可程式化：這包括協議級別的更改，使EOA（外部擁有帳戶）能夠重新定義其有效性規則的執行邏輯部分。眾所周知，在開發社區中，EOA通常與終端用戶相關。因此，採用這種方法的解決方案將使終端用戶帳戶能夠更多地控制他們可以授權的操作類型，而不是像今天這樣管理。
2. EOA轉換/遷移：此方法包括旨在完全將EOA轉換為CA（合約帳戶）的提議。此方法的核心思想是，合約帳戶已經提供了智能帳戶提供的大部分好處，因此不應再讓事情變得複雜；每個人應該簡單地將合約帳戶作為其主要帳戶（通過智能合約錢包）。

此方法具有機制，允許 EOA 轉換為 CA，而不必移動其資產，例如EIP 7377和EIP 5003（與 EIP 3074 相結合時）

1. 智能帳戶：這組提案包括設計，使得外部帳戶（EOAs）和合約帳戶（CAs）都能夠表現為“智能帳戶”，因為它允許它們完全重新定義其有效規則。

先前曾提出各種提案，以在協議層面創建智能帳戶和帳戶抽象。EIP-86和EIP-2938然而，由於此設計引入的複雜性及絕大多數人認為以太坊尚未準備好應對這種複雜性，因此遭到了很多反對意見。

在 The Merge 之后，维塔利克重新复兴了这个话题，ERC-4337被提議作為智能帳戶標準的可選版本，類似於PBS（提議者-構建者分離）基礎設施用於MEV（最大可提取價值）。因此，希望獲得智能帳戶好處的用戶可以簡單地使用ERC-4337管道來重新定義其帳戶的邏輯和交易的有效性規則，並以UserOperation（或UserOps簡稱）結構來表示。

ERC 4337將智能帳戶的好處帶到了當前的以太坊，而不會使任何複雜性成為不可動搖的事實，它作為一種協議之外的替代智能帳戶而存在。然而，這並不意味著基礎設施在其當前狀態下就是最佳的，因為其自身的複雜性仍然是一個相當大的失敗點。

為了應對這種複雜性，RIP 7560被草擬為以太坊及其L2網絡上ERC 4337基礎設施的確定版本，因此它繼承了網絡的抗偽裝機制，而不需要定義一套新的規則（就像ERC 4337般）。ERC 7562).

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

Ethereum帳戶和交易入門

為了尋找可以抽象化的內容，我們需要對當前帳戶設計有（某種程度的）全面了解。 本節將主要作為對以太坊上帳戶實際是什麼，以及它們的交易如何被驗證和執行的一種修訂。

以太坊帳戶是具有以太（ETH）餘額並能在以太坊區塊鏈上發送交易的實體。它們被表示為42個字符的十六進制“地址”，該地址作為指向帳戶持有和交易的唯一指針。

地址作為區塊鏈狀態trie的鍵。該trie的葉節點是帳戶數據結構，可以分解為四個字段:

1. nonce:一個線性計數器，用於指示帳戶發起的出站交易數量。它在防止重放攻擊方面也非常重要。
2. balance：帳戶擁有的以太（ETH）的以wei計量的金額。
3. codeHash：帳戶中包含的EVM可執行代碼的哈希值。EVM（以太坊虛擬機）是以太坊專用執行環境，負責處理複雜的狀態轉換，超出了簡單的“發送”交易。帳戶的代碼內容被不可變地編程，以在以太坊區塊鏈上執行特定形式的狀態轉換，通過EVM。
4. storageHash: 帳戶存儲根的哈希，用於表示帳戶的存儲內容，作為默克爾帕特里夏樹根節點的256位哈希。 簡單來說，它是與帳戶代碼內容相關的狀態變量數據的哈希。

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

1. 外部擁有的帳戶（EOAs）- 它們作為一對加密金鑰進行初始化：

• 一個可加密並且可以證明是隨機的 64 位十六進位字元的私鑰，以及它的互補對應物;
• 一個從私鑰使用ECDSA（橢圓曲線數位簽名演算法）衍生出來的公鑰。

EOA（外部帳戶）的codeHash和storageHash字段是空的，只能由擁有私鑰的任何人控制。可以通過在帳戶的公鑰的keccak-256哈希的最後二十個字符前加上“0x”來獲取它們的地址。

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

他們的交易完全基於拉模式，並且建立在其部署的程式碼邏輯之上。

因為這些帳戶只能由它們的程式碼內容來控制，所以它們不需要私鑰，只有公鑰。因此，任何有能力更新/改變合約帳戶程式碼內容的代理人都能夠存取其餘額。

CA的地址是由其創建者的地址和合約部署點之前的nonce衍生而來的。

交易

我們最近將帳戶描述為能夠在以太坊上發送交易的實體。因此，我們可以理解帳戶的主要目的是發送和接收交易，而區塊鏈則作為一個記錄交易歷史並描述交易如何根據區塊鏈協議規範中的規則改變帳戶字段的分類帳。

那這些“交易”是什麼意思？

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

無需許可性帶來了錯誤的激勵，為了應對這些問題，在這樣的環境中必須制定嚴格的指南（或有效性規則）來定義互動。

在這種情況下，交易必須遵循某些有效性規則才能被視為有效並執行。這些有效性規則中的大多數都是通過對發送交易的帳戶施加的約束來實現的，並且根據其帳戶類型而有所不同。

帳戶和交易有效性

在以太坊上，EOAs（外部帳戶）在可用性方面進行了優化，因為它們面向最終用戶。它們具有以特定方式發送交易並完全自主運作的能力。它們也可以在本地創建，更常見的方法是使用錢包提供者，例如MetaMask、Rainbow、Rabby等。

另一方面，合約帳戶只能根據其邏輯發送被“調用”的交易。此外，它們只能由擁有足夠餘額支付其狀態存儲的EOA創建。

更高層次的描述將是，EOA 只能持有餘額，而 CA 可以同時持有餘額和規定如何花費這個餘額的邏輯。

這些特性是由以下邏輯參數決定的，這些參數定義了帳戶的交易必須遵守的規則:

1. 驗證邏輯-用於定義帳戶在改變其餘額和/或邏輯時向網絡證明其身份的方式。
2. 授權邏輯-用於定義帳戶的訪問策略，即誰能夠訪問並更改帳戶的餘額和/或邏輯。
3. Nonce邏輯- 定義了從帳戶執行交易的順序。
4. 燃氣支付邏輯-用於定義負責結算交易的燃氣費用的一方。
5. 執行邏輯 - 用於定義帳戶可以發送哪些形式的交易，或者交易應該如何執行。

這些參數旨在對EOAs進行嚴格設計:

• 身份驗證和授權是通過基於ECDSA的私鑰提供的，即，希望從他們的EOA（外部帳戶）發送交易的用戶必須使用他們的私鑰來訪問該帳戶，從而證明他們有權進行對其余額的任何更改。
• nonce邏輯實現了一個順序計數方案，它允許每個帳戶按順序執行每個唯一nonce的一筆交易。
• 瓦斯支付邏輯規定交易的瓦斯費必須由發送方/原始帳戶解決。
• 執行邏輯指定EOA只能發送以下交易形式:

1. 兩個EOA之間的定期轉帳。
2. 合約部署。
3. 合約調用目標為已部署的合約帳戶邏輯。

更一般地說，EOA的執行邏輯限制它們每個有效簽名只能執行一個交易。

另一方面，CA在這些參數方面具有更大的靈活性：

• 身份驗證不是必要的，因為他們的交易是後果導向/拉動式的。
• CAs的授權可以有兩種形式：

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

在大多數實際情況下，這種情況下使用的邏輯是一種多簽名方案，該方案規定需要從特定帳戶（通常是EOAs）獲得M個有效簽名（其中M < N），以使CA的邏輯變更有效。

• 它們的交易排序基於鬆散的nonce。CA本身能夠向盡可能多的不同呼叫方發送許多交易，但每個呼叫方基於其自身的能力而受到限制。
• Gas支付通常由CA邏輯的調用者處理。
• CA的執行邏輯更加多樣，以實現UX改進，如多調用交易和原子交易。

評估這些功能，我們觀察到每種類型的帳戶都設計有自主性和可程式化之間的權衡。

EOAs具有完全的自主權，但受到有限的程式設計能力的限制；它們可以在任何時候授權和發送交易，但這些交易必須遵循嚴格的格式才能被視為有效。CAs具有完全的程式設計能力（僅受限於EVM的設計），但受到有限的自主權的限制；它們的交易不需要遵循任何嚴格的格式，但只能在其邏輯被首先調用時發送出去。

在下一小節中，我們將研究這些設計選擇的含義，以便充分理解本系列中討論的每個EIP的建議。

以太坊的帳戶困境

現在我們對不同帳戶功能有了相對簡潔的了解，我們可以輕鬆辨認出它們在以太坊上的優勢以及對用戶和開發者體驗帶來的問題。

如先前提到的，EOA被設計為針對最終用戶的一級帳戶。應用程序被設計為與它們輕鬆交互，幾乎沒有複雜性，當然創建一個帳戶也沒有費用。然而，其簡單性帶來了顯著的新意損失，因為它們被設計為嚴格確定性的。

它們周圍的一些擔憂是:

1. 對量子攻擊的易受攻擊性 - 他們的金鑰對使用的ECDSA簽名方案並不具量子抵抗能力，樂觀的時間表預計工業量子系統在5至10年內取得成就，這對以太坊及其應用構成重大威脅，因為它們在密碼證明和安全性方面嚴重依賴ECDSA方案。
2. 表達不足 – EOAs有效性規則的嚴格格式消除了用戶通過特性（如交易原子性、批處理和交易委託）更簡潔地表達其交易的能力。
3. 自我可持續性 - 每個人都有自己的“燃料用完了”的時刻，在交易過程中。這是由於要求EOA自行解決其交易的燃料，如果以太幣（ETH）不是唯一可接受的燃料貨幣，這不會是一個很大的要求。儘管這是帳戶為基礎的狀態機（甚至是UTXO為基礎的機器）的一個普遍問題，但以太坊始終打算與眾不同。

並非每個人都希望（或能夠）始終持有ETH（我的意思是看看那價格行動），所以可行的解決方案要么允許多種燃料貨幣（太難，破壞了太多不變量，如“貨幣”一節所述這裡), 或者允許通過其他帳戶支付 gas 費用，而不是交易的發起方。

在帳戶譜的另一端，CA 針對開發人員和更技術的使用者群。它們作為智能合約的載具（即，我們考慮智能合約是它們所包含的邏輯或程式碼內容），因此可以實現以以太坊虛擬機所啟用的新型交易格式。

然而，對於所有這些特徵，它們都是美化的二等帳戶，因為它們沒有自主權。它們的一些缺點如下：

1. 完全缺乏自主性 - CA無法開始交易，他們只能根據特定方式被調用後發送交易。
2. 在其邏輯中容易出現人為錯誤 - 缺乏嚴格性通常導致不正確的不變量定義和其他類似邏輯，這導致智能合約的漏洞和黑客行為造成數十億美元的損失。然而，這幾乎是一個完全不同的話題，超出了我們在這裡的範圍。

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

帳戶抽象的時間軸

帳戶抽象的概念（通過智能帳戶至少）一直是以太坊路線圖的重要組成部分。傳說其實施所涉及的複雜性威脅到進一步延遲以太坊的發佈，因此被放棄，改為目前的設計，不同的帳戶提供不同的功能。以太坊在“合併”的重點上再次延遲，現在作為網絡下一個重大升級“Pectra”的主要部分再次浮出水面。然而，其複雜性仍被認為是一個重大缺點，阻礙了其立法地位，尤其是由於以太坊已轉向以Rollup為中心的路線圖。

現在的要求是兩個方面:

1. 帳戶標準必須更具表達性，但不能失去自主性。一個新的標準，封印了以太坊帳戶（EOA）和合約帳戶（CA）標準之間的鴻溝。
2. 新標準必須在保持與以太坊及其L2生態系統的完全兼容的同時，彌合EOA和CA之間的差距。

直觀地，這個概念在鏈抽象和互操作性的背景下扮演著更重要的角色，然而在本報告中，我們的範圍僅限於為實現帳戶抽象本身所採取的技術舉措。

帳戶抽象旨在將EOAs和CAs的最佳功能結合為一個新的帳戶標準-智能帳戶，可以將任何帳戶的有效性規則完全或部分分離為驗證邏輯和執行邏輯; 以便帳戶可以像合約帳戶一樣定義自己的有效性規則- 在EVM允許的範圍內- 同時保持完全自治，就像外部擁有的帳戶一樣。

關於智能帳戶和智能合約錢包之間的區別，常常會讓人感到困惑，因此讓我們明確地描述一下這些區別：

• 智能帳戶是以太坊帳戶的概念化，旨在提供程式設計和自主性的平等部分。其想法是，無論是EOA還是CA，只要利用某些機制（例如ERC 4337）便可成為智能帳戶，該機制允許他們將網絡強制施加的有效規則替換為根據自己需要制定的有效規則。
• 另一方面，智能合約錢包只是作為與合約帳戶進行交互的介面的錢包提供者（是的，錢包不是帳戶）。

智能合約錢包的商業化使得更廣泛的市場可以採用CAs，讓技術水平較低的用戶也能夠利用它們提供的功能。然而，它們仍然面臨與CAs相關的缺點。

回到對話;我們先前討論過用於定義帳戶交易有效規則的參數:

• 驗證
• 授權
• Nonce邏輯
• 燃氣支付邏輯
• 執行邏輯

首四個參數的值可以合稱為帳戶的驗證邏輯，這些是在交易執行開始之前發生的檢查。

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

在介紹中，我們提供了一個對當前AA景觀的高層次概述，以各種提出的設計形式進行分類。現在我們將專注於解決以太坊帳戶困境的第一類解決方案- EOA可編程性。

可編程EOA

以太坊最大的吸引力在於其年輕而充滿活力的去中心化金融生態系統，該生態系統擁有各種主要的流動性池，供應多樣化的去中心化應用。大部分這些去中心化應用都是為外部帳戶（EOAs）優化，因此很難與合約帳戶（CAs）和智能帳戶進行接口應用。雖然智能合約錢包在這種情況下可以幫助合約帳戶，但它們也有自己的限制和完全不同的用戶體驗（UX）。

在DApps和錢包提供者熟悉智能帳戶標準之前，正在探索的一個臨時解決方案是為EOA提供臨時增強功能，使它們能夠克服大部分強加的限制，無論是驗證還是執行邏輯。

以下是三個重要的EIP規格，提供對EOA可程式化的可行路線；從較不熟知的地方開始EIP 5806，對於雄心勃勃的EIP 3074然後最終到勝利者EIP 7702.

通過EIP-5806的可編程性

此提案旨在通過允許EOA標準執行對合約帳戶的邏輯（其智能合約）進行委託調用，從而為EOA標準帶來更多功能。這有效地使智能合約在呼叫者EOA的上下文中執行，即EOA仍然控制其驗證邏輯，而其執行邏輯由相應CA的邏輯處理。

在我們繼續之前，讓我們回顧一下以太坊的演進歷史。EIP-7.

EIP-7 提議創建了 0xf4/DELEgateCALL 操作碼，用於將消息調用發送到主帳戶中，同時保持主帳戶的 [sender] 和 [value] 字段的值，並具有次級帳戶的邏輯。

換句話說，主帳戶在消息呼叫中“繼承”（或者您更喜歡的話，借用）次要帳戶的邏輯一段特定時間，這樣後者的邏輯就在前者的上下文中執行。

此操作碼允許dApp開發人員將他們的應用邏輯拆分為多個智能合約，同時保持相互依賴，這樣他們就可以輕鬆地繞過代碼大小限制和燃氣限制。

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_limit: 單筆5806類型交易可以消耗的最大gas數量。
• 目的地: 交易接收者
• 資料: 可執行的程式碼內容
• access_list：有條件授權執行EIP-5806交易的代理人。
• signature_y_parity、signature_r 和 signature_s：這三個值共同代表對消息 keccak256(TX_TYPE || rlp([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list])) 的 secp256k1 簽名。

雖然在 EIP-2718 包裝中打包 EIP-5806 交易使它們具有很大的向後兼容性，但 EOAs 與 CAs 不是等價的。因此，必須定義某些限制，以防止 EOA 利用委託呼叫時不變式破壞。

這些限制針對以下操作碼:

• SSTORE/0x55：此操作碼允許帳戶將值保存到存儲器中。在EIP-5806交易中受限制，以防止外部帳戶使用代理呼叫設置/訪問存儲，從而防止由於帳戶遷移可能在未來出現的潛在問題。
• CREATE/0xF0，CREATE2/0xF5和SELFDESTRUCT/0xFF：這些操作碼廣泛允許調用方創建新帳戶。為了防止在執行不同的執行框架（在這種情況下是合約創建/銷毀）期間執行EIP-5806交易時改變EOA的nonce，因此對這些的訪問受到限制，以防止交易攜帶連續nonce的期望無效化。

潛在的適用性/使用案例

EIP 5806的主要適用性是對EOA的執行抽象。允許EOA與智能合約進行無信任互動，超出了對它們邏輯的簡單調用，賦予它們功能，例如：

• 交易的條件執行
• 交易批次處理
• 多項呼叫交易（例如核准和呼叫）

批評

EIP-5806提出的更改雖然可以啟用所需的功能，但並不是特別新穎；它的存在主要是基於已經功能完善的EIP-7。這使它能夠避開許多可能阻礙其被接受的障礙。

在早期，人們提出的一個主要擔憂是允許EOA存取和更改存儲的潛在風險，就像CAs目前所做的那樣。這打破了許多有關EOA交易的網絡內在性的不變性，因此通過引入前一小節中提到的限制來解決這個問題。

第二个批评（这是一个双刃剑）是 EIP-5806 的简单性；有些人认为接受 EIP-5806 可能不值得代价，因为它只能实现执行抽象，没有太多其他功能。与其他类似的 EIP 相比，选择 EIP-5806 的 EOAs 的所有其他有效性限制仍由网络定义，在下面的小节中我们将讨论其他类似的 EIP。

透過EIP-3074的可程式性

EIP-3074提議允許EOA將其大部分驗證邏輯委派給專門的合約帳戶，稱為調用者，通過在特定形式的交易中將後者的授權邏輯覆蓋在其上。

通過將其訪問策略簽署給調用者合約，它實現了這一點，然後該合約負責定義EOA的訪問策略。

本EIP提議向EVM添加兩個新的操作碼:

• [AUTH]，它根據第二個[授權]帳戶的ECDSA簽名，將上下文變數[授權]帳戶設置為代表第二個[授權]帳戶執行操作。
• [AUTHCALL] 從/作為 [authorized] 帳戶向 [authority] 帳戶發送/實施呼叫。

這兩個操作碼允許 EOA 將控制權委託給預先建立的 CA，因此，通過它行事，而無需部署合約並承擔相關成本和外部性。

規格

EIP-3074 允許交易使用 [MAGIC] 簽名格式，以防止與其他交易簽名格式發生碰撞。傳遞 [AUTHCALL] 指令的活躍帳戶被定義為一個上下文變量字段，名為 [authorized]，它只在單個交易中持續存在，並且必須為每個新的 [AUTHCALL] 重新定義。

在解決每個操作碼的複雜性之前，以下是 EIP-3074 交易中涉及的實體:

• [authority]：主要的簽署帳戶（一個EOA），將訪問/控制權委託給一個次要帳戶，通常是合約帳戶。
• [authorized]: [AUTHCALL]指令應傳遞以執行的帳戶。換句話說，它是執行[認證呼叫]的邏輯的帳戶，代表[權限]使用[調用者]定義的約束。
• [調用者]: 一個旨在管理[授權]帳戶與[授權調用]邏輯之間交互作用的子合約，尤其是在後者合約代碼的主要邏輯需要氣體贊助的情況下。

Invoker合約從[authority]收到帶有[COMMIT]值的[認證]消息；該值定義了帳戶希望對[authorized]執行的[AUTHCALL]指令加以限制。

因此，調用者負責確保 [授權] 帳戶中定義的 [contract_code] 不是惡意的，並且能夠滿足主簽名帳戶在 [COMMIT] 值中放置的不變量。

[AUTH]操作碼有三個堆棧元素輸入；或者更簡單地說 — 它由計算單個輸出的三個輸入定義。這些輸入是：

1. 權威: 是生成簽名的EOA地址
2. 抵銷
3. 長度

最後兩個輸入用於描述可修改的記憶體範圍從0到97，其中：

1. [memory(offset : offset+1)] – [yParity]
2. [memory(offset+1 : offset+33] – [r]
3. [memory(offset+33 : offset+65)] – [s]
4. [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]欄位將保持不變，保持其先前的狀態，或作為未設定的值。

此操作碼的燃氣成本是以下的總和:

1. 為 [ecrecover] 預編譯收取固定費用，並額外收取 keccak256 哈希和一些額外邏輯，價值為3100單位
2. 一種記憶擴展費，其計算方式類似於 [RETURN] 操作碼，在記憶體擴展超出當前分配範圍時應用(97單位)
3. 遭受100單位的固定成本以獲得溫暖[權威]，並且為了防止由於狀態訪問操作碼的定價錯誤而遭受攻擊，需要2600單位。

[AUTH]的實現不修改記憶體，並以[authority]的值作為參數，因此從提供的簽名中驗證其值是微不足道的。

[AUTHCALL] 操作碼有七個堆疊元素輸入，用於計算單個堆疊元素輸出。

它具有與[CALL]操作碼相同的邏輯，即；它用於向帳戶發送消息調用並觸發其合約中的特定邏輯。它們邏輯上唯一的偏差是，[AUTHCALL]是在執行之前設置[CALLER]的值。

因此，[AUTHCALL] 被[權威]用來觸發[已授權者]的特定上下文行為，邏輯檢查如下進行：

1. 檢查 [authorized] 的值。如果未設置，則執行被視為無效並立即退出。這有助於防止由於突發故障而產生不公平的費用。
2. 檢查 [authorized] 的預期行為的 gas 成本。
3. 檢查 [gas] 運算元的 EIP-150 符合值。
4. 檢查 [authority] 帳戶餘額中的總瓦斯成本 -[value]- 的可用性。
5. 從[authority]的帳戶餘額扣除[value]後執行。如果[value]大於他們的餘額，執行將被無效化。

[AUTHCALL]的燃氣成本被計算為以下之和：

• 調用[warm_storage_read]的固定費用
• 擴充記憶體的成本為 [memory_expansion_fee]，計算方式與 [CALL] 指令的 gas 成本類似
• 一個動態成本 [dynamic_gas]
• 子調用的執行成本 [subcall_gas]

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

• [RETURNDATASIZE] - 將返回數據緩衝區的大小壓入輸出堆棧
• [RETURNDATACOPY] - 將數據從返回數據緩衝區複製到內存中。

將所有這些結合在一起，遠離技術術語; 以太坊交易通常指定兩個值:

1. tx.origin - 提供交易授權。
2. msg.sender - 實際發生交易的地方。

在EOAs中，如前所述，授權與執行緊密耦合，即；(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允許EOA在發送[AUTH]消息後保持其nonce不變，同時它與每個[AUTHCALL]的nonce取決於它正在交互的調用者。通過這種方式，它為EOA啟用了nonce並行性，因此它們可以自由地發送多個不重疊的[AUTHCALL]。
• Gas payment logic: 如指定在EIP中，調用者可以設計為允許燃氣贊助。因此，用戶的[COMMIT]的燃氣費用可以從交易的起源或任何支持的帳戶中扣除，無論是個人帳戶還是基於服務的中繼（燃氣贊助服務）。

此外，執行邏輯在直觀上被抽象化；畢竟，調用者（也就是 CA）現在負責代表 EOA 執行交易請求。

批評

• Invoker 集中化

引用3074倡議所帶來的最大問題可能是，其上的創新很容易導致許可和專有交易流程，就像當前版本的以太坊MEV和PBS市場一樣。該倡議的一位作者表示：“我不希望錢包公開功能以便簽署任意的調用者……”。

默認情況下，調用合約需要接受嚴格的審計，以防止比目前可能的更糟糕的攻擊。這將不可避免地導致一個生態系統，只有少數由有影響力的人物開發的調用合約被採納為錢包開發者的默認選擇。因此，這歸結為在採取不斷審計和支持調用合約的硬性去中心化途徑，冒著用戶安全的風險；或者僅僅採用來自成熟和聲譽良好來源的調用合約，為用戶安全提供更好的保證，對合約的安全監督更少。

這一點的另一個方面是與設計、審核和營銷功能和安全的調用者相關的成本函數。較小的團隊幾乎總是會被較大的組織超越，尤其是在營銷方面，即使他們的產品更好，大組織已經建立了一定的聲譽。

• 向前兼容性問題

EIP-3074巩固了ECDSA签名方案，因为它仍被认为比通过调用者引入的授权方案更有效。尽管有人认为量子抗性目前并不是一个明确的问题，并且在ECDSA可以被破坏的未来有更严重的问题，但以太坊的隐含目标是始终走在这些问题的前面。未来为了略微改善用户体验而牺牲量子和审查抗性可能不是最佳选择。

前向兼容性論點的另一個觀點是，在評估3074的好處時，不需要任何協議更改的ERC-4337現在已經有了一個很好的市場，所以您也必須與它兼容，以避免生態系統的分隔。

即使具有本地帳戶抽象路線圖，[AUTH] 和 [AUTHCALL] 操作碼最終將在EVM中變得過時，在提供微不足道的UX改進的同時引入了大量的技術債務。

• ECDSA方案不可撤銷性

在發送[身份驗證]消息並委派控制後，預期EOA應該避免使用通常的私鑰授權方案，因為發送“正常”的交易會導致委派給每個調用者的授權被撤銷。

因此，ECDSA方案仍然嚴格優於任何其他授權方案，連帶合約可能啟用的，這意味著私鑰的丟失將導致帳戶資產的全部損失。

通過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]: which is the EOA/primary signing account
• [address]: 這是包含可委派代碼的帳戶地址。

當[authority]簽署一個指定[address]的SET_CODE_TX_TYPE時，將創建一個委派指示器。這是一個“指針程式”，它導致由[authority]在任何時刻引起的所有代碼檢索請求被導向到[address]的可觀察代碼。

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

1. 從提供的哈希值使用 [authority] 的簽名驗證: authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s)
2. 預防跨鏈重放攻擊和其他攻擊向量通過鏈的ID驗證。
3. 檢查 [authority] 是否已經有代碼內容。
4. Nonce檢查以確保[authority]的nonce等於元組中包含的nonce。
5. 如果交易是[authority]的第一個SET_CODE_TX_TYPE交易，則收取PER_EMPTY_ACCOUNT_COST費用。如果其餘額小於此費用的值，則操作將被放棄。
6. 委派指定發生，其中[權威]的代碼設置為[地址]的指針。
7. 簽署者的nonce -[authority]- 增加了一個。
8. [權限]被添加到一個列表-訪問地址，這些地址（過度簡化）是一組地址，使得從這些地址中撤消交易範圍導致它們（地址）恢復到它們進入撤消範圍之前的先前狀態。這是如EIP-2929以便緩存可重用的值並防止不必要的費用。

噢！回到正題吧；這個EIP允許EOA發送設定指向合約代碼的交易，使其能夠在後續交易中將此邏輯實現為自己的邏輯。從這個角度來看，它比EIP 5806更強大，因為它允許EOA實際上擁有自己想要的代碼內容（而不僅僅是允許EOA發送委託調用的EIP 5806）。

潛在的應用/使用案例

• 執行抽象

雖然可以說，由於EOA積極接受其希望執行的邏輯，它不再是一個抽象，但它仍然不是所述邏輯的“主要所有者”。此外，它並不直接包含邏輯，它只是指定了指向該邏輯的指針（以減少計算複雜度）。所以我們將執行抽象化！

• Gas 贊助

雖然破壞了require(msg.sender == tx.origin)不變式以允許自我贊助，但EIP仍允許集成贊助交易轉發器。然而，問題是這樣的轉發器需要一個基於聲譽或股份的系統，以防止煩惱攻擊。

• 條件存取政策

EOA只能指向帳戶代碼的特定部分，因此在它們的上下文中只有該部分的邏輯是可執行的。

這還使得子金鑰的存在成為可能，從而實現了“特權降級”，以便特定的dAPP只在特定條件下能夠訪問帳戶餘額。例如，你可以想象一個可以花費ERC-20代幣但不能花費ETH的許可權，或者每天可以花費總餘額的1%，或者只能與特定應用程序交互。

• 跨鏈智能合約部署

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

批評

• 缺乏向後兼容性

雖然EIP-7702仍然非常新，但已經有很多原型和測試來測試它的依賴性和潛在的缺點，但其極簡的模型保證了它在不同情境中具有很大的靈活性和實用性。但是它打破了太多的不變量，並且不立即向後兼容。

一些邏輯包括：

1. 交易中的EOA nonce更改：EIP-7702不限制任何操作碼，以確保一致性。這意味著在執行EIP-7702交易時，EOA可以實施CREATE、CREATE2和SSTORE等操作碼，從而使其nonce在不同的上下文中增加。
2. 允許具有非零codeHash值的帳戶成為交易發起者：EIP-3607的實施旨在減少外部帳戶（EOA）和智能合約帳戶（CA）之間“地址碰撞”的潛在影響。當EOA地址的160位值完全等同於CA地址時，就會發生地址碰撞。

大多數用戶對帳戶的實際內容（甚至帳戶和地址之間的區別）並不了解！所以允許地址碰撞意味著一個EOA可以冒充CA，並吸引用戶資金，最終竊取所有資金。 EIP-3607 通過規定包含代碼的帳戶不應該能夠使用自己的授權邏輯來花費餘額來解決這個問題。然而，EIP 7702 打破了這個不變量，以實現EOA在獲得一定的可編程性後仍能保持自治。

• 與EIP-3074的相似性

將帳戶的地址簽名轉交給其代碼內容，基本上就像3074的方案與調用者一樣。這並不提供關於跨鏈代碼內容一致性的嚴格保證，因為一個地址在不同鏈上可能包含不同的代碼內容。這意味著，一個地址在一條鏈上的代碼內容包含相同的邏輯，但在另一條鏈上可能是具有掠奪性或明顯惡意的，這可能導致用戶資金的損失。

結論

目前的EOA形式受到很大限制，因為它們不允許用戶充分利用以太坊虛擬機提供的可編程功能。雖然有各種升級帳戶的方法，正如我們在本報告開頭所概述的，所選解決方案必須保持安全和自我保管的原則。此外，EOA升級可能會顯著影響用戶體驗和應用開發人員，因此必須考慮所有利益相關者的聲音。

允許EOA以任何方式執行代碼極大地擴展了帳戶的功能，但這種新的表達能力伴隨著重大的風險和可能的盲點。解決這些權衡是關鍵，以提供對以太坊用戶具有爭議性的UX優勢的升級。

以太坊的開放討論文化使其成為這些創新的絕佳測試場，因為幾乎每個設計的每個含義都會被主題專家徹底解構。這種全面的考慮應有助於減輕對手的不當行為風險。

EIP-7702目前是尋求將EVM可程式性帶給EOA的機制的標誌性代表，已被標記為Pectra升級中取代EIP 3074的槽位。它繼承了3074機制的開放設計，同時大大降低了攻擊面/風險。它還通過避免3074對某些類型操作碼的限制，可以實現更多功能。

雖然在提案設計上仍在進行一些細化，但它已經獲得了許多來自開發者的支持和支持，特別是因為它直接得到了 Vitalik 的支持。

社區內部有人聲稱，這種帳戶抽象的方法甚至比智能帳戶更好。這條評論強調這種方法需要的改變較少，並且不會那麼複雜，而且EOA已經得到確立。然而，我們必須記住以太坊網絡在每個層面上未來的量子安全里程碑。由於使用基於ECDSA的簽名方案進行EOA授權，目前的帳戶模型核心無法實現這種量子安全。

因此，EOA的可程式化應該被視為智能帳戶發展道路上的一個步驟，而不是最終目標。它可以加速EOA並提供更好的用戶和開發者體驗，同時與智能帳戶的最終帳戶抽象目標兼容。

在我們的下一份報告中，我們將深入研究EOA遷移方案，看看它們在帳戶抽象路線圖上的適應情況，敬請期待！

免責聲明：

1. 本文轉載自[2077.xyz], 所有版权归原作者所有 [zhev]. 如果有異議，請聯繫Gate 學習團隊，他們將迅速處理。
2. 責任聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
3. 文章的翻譯由Gate Learn團隊進行。未經授權，禁止複製、分發或抄襲翻譯的文章。