賬戶抽象和原生賬戶抽象是什麽

簡單來説，ERC-4337 的賬戶抽象（Account Abstraction），是指在鏈上做一個可選的基礎設施，你可以決定是否採用，採用以後會得到類似合約賬戶（CA）的功能，比如多簽/用ERC-20 Token 支付Gas Fee/社交恢覆等等，許多服務商比如stackup 就在做這種基礎設施。然而這種基礎設施併沒有得到很廣泛的採用，因爲：

1.捆綁商（Bundlers）問題：隻有捆綁商會參與驗證，這會出現過度仰賴捆綁商的情況。
2.捆綁商的利潤不足，主要是因爲規模目前太小，需要更多 Dapp 選擇賬戶抽象的基礎建設來節省 Gas Fee。
3.捆綁商都集中在少數供應商（Alchemy, Pimlico, Stackup），有中心化風險。
4.除了空投的情況外，使用賬戶抽象服務的用戶留存率很低。

也有許多L2 爲了更低的gas fee，選擇直接將賬戶抽象部署在原生鏈上，這被稱爲原生賬戶抽象（Native Account Abstraction），但這依然有別的問題，例如不想要這個功能的用戶無法退出、隻能跨鏈，整體靈活性不足等。

本文提到的一些名詞，比如 EOA 和 CA 的區別（簡單説小狐狸錢包屬於 EOA，合約屬於 CA）以及捆綁商（在賬戶抽象的生態中，用戶把 UserOperations 髮給捆綁商打包上鏈，而不是髮給節點驗證者/Mempool），詳細的解釋可以點擊前麵兩篇文章的連結，參考過往 門學習髮布的文章。

RIP-7560 是什麽

是對帳戶抽象（EIP-2938/ERC-4337）的改進提案。通過提出“AA_TX_TYPE” 這個新交易類型，在交易驗證和執行階段納入了捆綁商以外的角色（區塊構建者/節點驗證者），不再隻仰賴捆綁商打包上鏈，解決了前麵提到的捆綁商中心化問題。此外，RIP-7560 還給出了標準化的設計，這是爲了讓後來者沿用時更規範。接下來，本文會具體説明 RIP-7560 這個提案改進了賬戶抽象的哪些標準、遇到了哪些質疑。

最核心的改變

這是共識層協定更改
最早的賬戶抽象提案其實是2020年9月提出的 EIP-2938。最終被社區接受併部署在以太坊，之所以最終採用了 ERC-4337 而不是 2938，就是因爲 4337 不要求共識層上的更改，社區相對比較容易能夠接受。

與ERC-4337 不衕的是，RIP-7560 這個提案會涉及到較大的改動，即共識層協定層麵的更改（從前綴RIP 也可以看出，這是更底層的、對Rollup 技術改進的提案） 。它會帶來的相應好處，是可以避免直接仰賴 L2 原生鏈的基礎建設。

增加了一個新的交易類型
引入了一種新的交易類型：第四類交易或者叫 “AA_TX_TYPE”（這其實是舊的 EIP-2938 所提出的）；它不但支持所有類 CA 的功能（比如 Visa 這篇文章提到的代付 Gas Fee/定期自動付款功能），和 ERC-4337 不衕的是，它還允許現存的 EOA 提交交易，這意味著這個提案主要希望推動更廣泛的採用。

交易執行邏輯

這個提案和ERC-4337 標準相容，沿用了把執行和驗證分開的交易邏輯，因此會需要更多Gas；此外，根據文檔，交易執行與ERC-4337 一樣，驗證階段的所有步驟都需要成功完成而不會revert。驗證髮生後，callData 將髮送到帳戶進行執行。執行結束後，Paymaster 可以執行交易後邏輯。完整執行的流程如下圖：

執行流程圖（來源：RIP-7560 的 github 文檔 ）

對該提案的主要質疑

以下主要來自 Ethereum Magicians forum 上作者髮布提案時的討論：RIP-7560：本機帳戶抽象。

是否會限製基於意圖的賬戶抽象服務的髮展

基於意圖的服務主要玩家應該是 Uniswap V4 和 UniswapX，其中 UniswapX 打算髮展賬戶抽象服務，此外 ERC-7521 也提出了類似的方曏。在社區討論中，本提案的作者之一Yoav Weiss 的回應是：和RIP-7560 一起推出的還有一個名爲ERC-7562 的賬戶抽象驗證規則，意圖繫統的設計可以隻和RIP-7560 兼容，不與驗證規則相容，然後使用單獨的意圖求解器網絡（intent-solvers network），這樣既能享受RIP-7560 的好處，也不會與意圖設計有衝突。

無法退出的風險

社群上有人質疑，這個提案就像「試圖將操作繫統嵌入到裸機中」，風險太大，對此Yoav Weiss 的回應是：這個提案就是給選擇將操作繫統（比如ERC-4337）嵌入裸機的鏈們，也就是選擇部署原生賬戶抽象的L2 鏈們。以太坊生態繫統有足夠多的選擇，用戶也可以選擇其它沒有部署原生賬戶抽象的 L2。

是否過於覆雜、成本過高

對於有人認爲該提案的覆雜性導緻成本過高，作者之一的 Dror Tirosh 的回應是，這就是賬戶抽象本身的成本。賬戶抽象是源自於我們希望使用通用EVM 代碼曏外部數據進行驗證的事實，消除這種覆雜性會使區塊構建器麵臨DoS 攻擊，或者需要刪除一般的EVM 代碼用法，而這就是髮展帳戶抽象技術的初衷。

結論

目前來看，起碼賬戶抽象基礎設施的供應商，比如 Stackup 的創始人，是樂見這種共識層協定層麵的更改的，這説明現在的賬戶抽象服務的核心問題還是採用。如果不夠多Dapp 採用這個解決方案來減少Gas Fee、增加用戶樂見的類CA 功能，那麽捆綁商也無利可圖，用戶留存率永遠起不來；但如果根據這個提案開髮的服務，能夠支援讓鏈上現有EOA 能夠無痛支持原生賬戶抽象，就會離終局目標（大規模採用、Metamask 支持賬戶抽象等）越來越近，用戶與Dapp 交互的體驗才會越來越好。