一文梳理Devcon大會熱議「帳戶抽象」背後相關知識點

133次閱讀

原文標題:《名詞解釋:Web3 賬戶相關概念大梳理》

原文作者:zhixian.eth

剛剛結束的 Devcon 上,賬戶抽象算是是最熱的幾個話題之一,最近可以經常看到 AA / EOA / SCW / 4337 等縮寫和代號在各種 talk、panel 和資訊流裡出現。再加上敘事開始往「Onboarding next billion users」的方向發展,一些新的形容詞也開始出現在產品之前,比如 seedless / gasless / social recovery / non-custodial。相信看完這兩句的你已經開始腦殼疼了,那麼接下來就讓我盡自己所能來幫大家梳理一下這些名詞概念到底代表甚麼。

閱前提示:本文不是嚴肅的技術文檔,可能會用不精確但容易理解的語言進行闡述或比喻,歡迎大家以此為起點深入探索這些技術的細節。

EOA – Externally Owned Accounts

EOA 中文叫做 外部賬戶,我們最熟悉的 MetaMask 生成的地址就是 EOA。它的特點是原理簡單,比如生成規則是:

私鑰 – 公鑰 – Keccak256 哈希 – 最後 20 Bytes – 十六進制字元串(EOA 地址)

可以看出這個規則非常直接,全是由數學變換計算出來的,生成的地址內部沒有任何結構和邏輯。節點 驗證一筆交易是否被地址 owner 授權的時候也是固定的規則:

交易簽名 – ec_recover – 公鑰 -(用上面的規則生成)地址 – 對比要操作的地址

對比結果一致那麼驗簽通過,進行後續流程;不通過則直接打回,不會進一步廣播交易。

EOA 的另一個設定是作為交易的發起方並支付 gas,相對應的 CA(合約賬戶)只能被其他 CA 或者 EOA 調用。也就是說,EOA 是交易的觸發器,一筆交易無論後面有多少合約調用,一開始都必須由一個 EOA 發起並且支付足夠的 gas 才可以進行。

需要指出的是,EOA 是以太坊以及其他 EVM 兼容鏈(或類 EVM 鏈)才有的概念,嚴格來說包括 BTC 在內的主流非 EVM 鏈都沒有這個設定。

CA – Contract Accounts

CA 中文叫做 合約賬戶 (也曾被稱為 內部賬戶),我們常見的 ERC-20 Token 合約、DeFi 業務合約等都有一個跟 EOA 長得很像的地址,這就是 CA。

在設定上,CA 是以太坊世界的原住民,EOA 和 ETH 是為 CA 的業務邏輯準備的觸發器和燃料;實際使用下來,以太坊上除 ETH 之外的所有資產都是由 CA 承載,DeFi 等業務邏輯就更是全都由 CA 來實現。然而 CA 無法主動進行操作和支付 gas 的設定也限制了它的能力,早在 2016 年就有提案 希望能讓 CA 自己支付 gas。

簡單來說,CA 是具備內部邏輯的以太坊賬戶,裡面既可以是業務邏輯(Token 合約用來記賬,質押合約用來放貸和清算),也可以是賬戶邏輯(比如 gnosis safe 的多簽邏輯),而後者就是我們即將提到的「SCW – 智能合約 錢包」概念。

CA 的地址規則是通過計算生成的,有 CREATE 和 CREATE2 兩種方式,這裡不再展開。大家只需要記住 CA 和公鑰沒有必然對應關系即可,比如 gnosis safe 創建的 CA 裡可以設定任意多把公鑰來解鎖它的地址對應的資產;當然 CA 也可以不設定任何密鑰,而是由其他 CA 的邏輯決定是否可以解鎖,比如 DeFi 的 借貸 合約,只要還了錢就能取回質押的資產。

SCW/A – Smart Contract Wallet/Account

智能合約錢包 應該是字面意思最好理解的了,也就是用 CA 作為地址的錢包方案,而我們常用的 EOA 錢包方案是用前述的公鑰變換結果作為地址。由於具備內部邏輯,智能合約錢包可以實現很多 EOA 無法實現的功能,比如 gas 代付,批量交易,權限管理,離線授權,社交恢複等等。

這裡舉幾個例子來展示一下智能合約錢包的擴展潛力:

1. Gnosis safe 利用智能合約錢包架構實現多簽邏輯;

2. 用戶可以在一筆上鏈交易中同時給多個地址發送不同的 token,也可以在用 uniswap 時讓 approve 和 swap 在一筆交易裡完成,從而做到需要多少授權多少,避免因為過度授權造成 安全 隱患。

3. 用戶可以給不同資產設定不同的操作權限,比如給 PFP 設定比普通 ERC-20 token 更高的操作門檻(例如需要一把由硬件錢包管理的 admin key 才能轉移),這樣即便日常使用的環境發生密鑰洩露,黑客也無法將高價值資產轉走,在安全和便利中間取得平衡。

4. 用戶可以簽署一個離線授權「誰能給我 100 ETH,就可以轉走我的某個 BAYC」,這樣不需要授權給第三方合約,用戶就可以跟其他人 P2P 地完成原子交易。

AA – Account Abstraction

賬戶抽象 其實不是一個新概念了,最早可以追溯到 2015 年的一些討論,當時 Vitalik 認為至少要讓以太坊用來驗證交易的密碼學算法做到可替換,比如換成性能更優的 ed25519(詳見這裡),可以說 7 年來 Vitalik 和 EF 都沒有停止對賬戶抽象方案的討論和探索,這裡有個整理好的 link tree 可以幫大家回顧一下历史。

那麼賬戶抽象怎麼理解呢?這裡我引用一下 ERC-4337 裡對其目標的描述:

Achieve the key goal of account abstraction: allow users to use smart contract wallets containing arbitrary verification logic instead of EOAs as their primary account. Completely remove any need at all for users to also have EOAs (as status quo SC wallets and EIP-3074 both require)

可以看出以太坊對於賬戶抽象的期望是改變目前大多數人都在使用 EOA 的現狀,希望用戶轉向 SCW,並且把生態對 EOA 的依賴完全去除。除了裡面提到的 EIP-3074 之外,還有一個更為激進和遠期的 EIP-5003,這裡同樣引述幾段原文(有省略):

EOAs …… are limited by the protocol in a variety of critical ways. These accounts do not support rotating keys for security, batching to save gas, or sponsored transactions to reduce the need to hold ether yourself. There are countless other benefits that come from having a contract account or account abstraction, like choosing one’s own authentication algorithm, setting spending limits, enabling social recovery, allowing key rotation, arbitrarily and transitively delegating capabilities, and just about anything else we can imagine.

……This EIP provides a path not to enshrine EOAs, but to provide a migration path off of them, once and for all.

不難看出,EIP-5003 的目標是一次性將 EOA 轉換為 CA,讓所有用戶用上 SCW,徹底解決向前兼容的問題。(經過上面的名詞解釋,看這些縮寫是不是順暢了些?)

到這裡大家對 AA 的來龍去脈和未來目標應該有所了解了。但需要指出的是,AA 這個概念不是以太坊和 EVM 專屬的,很多鏈原生已經具備了不同程度的 AA 特性。比如 EOS / Polkadot / Near / Solona / Flow / Aptos …… 甚至 BTC(單簽 / 多簽 / Taproot),這些鏈在設計時就已經將賬戶做成了有內部結構甚至具備權限管理能力的狀態,還有 StarkNet / CKB 等具備更完善的賬戶抽象能力。說到這裡大家不難發現,以太坊的 AA 是在解決 EOA 意外地流行帶來的历史遺留問題,從而在賬戶層面上變得更加先進和靈活。

4337 – ERC 4337

從上面對 AA 的討論裡不難看出,ERC-4337 只是這個方向眾多提案中的一個,但是為甚麼大家一提到 AA 或者 SCW 就會說到它呢?我們來看這個文檔的副標題:

An account abstraction proposal which completely avoids consensus-layer protocol changes, instead relying on higher-layer infrastructure.

也就是說,ERC-4337 是 AA 的路線第一次從「暴力革命」轉向「和平演變」,不再追求利用共識層的改變實現 AA,而是轉而使用 SCW 這種用戶層的方案。並且為了實現更好的互操作性,ERC-4337 定義了一些 SCW 應該實現的接口,以及元交易打包、gas 代付等基礎設施的框架。它的出現讓目前差異極大的各種 SCW 方案能夠擁有統一的用戶交互界面以及共用一些生態層面搭建的開放基礎設施,有助於各種場景快速實現自己需要的 SCW 方案。另一方面,ERC-4337 的推動有助於促進生態其他參與方提升對 SCW 的兼容性,比如驗簽需要的 EIP-1271 和有些 DeFi 協議裡定義的禁止 CA 交互的一些規則。

Seedless

這裡的 seed 指的是 seed phrase,就是我們創建錢包的時候經常被要求備份的助記詞。那麼 seedless 的意思就是「無助記詞的」,或者也可以說成「無私鑰的」。註意這個「無」並不是實際意義上的沒有密鑰,而是指不需要用戶備份助記詞 / 私鑰或者感知到它們的存在。

一個常見的問題是,如果用戶不備份助記詞,用戶是不是就沒有賬戶的控制權了?一旦用戶切換新設備環境,賬戶不就無法訪問了嗎?沒錯,只是把用戶備份助記詞的功能砍掉的話只能算是產品設計失誤,而 seedless 追求的是用戶「不需要」知道助記詞的存在,同時依然擁有賬戶的完全控制權。也就是說,用戶(且只有用戶自己)擁有在新設備自主恢複賬戶控制的能力,只是不再依賴助記詞這種 UX 很差、過於 geek 的方式,比如下面要講到的社交恢複就是非常好的一種。

Gasless

這裡的 gas 指的是 gas fee,所以 gasless 的意思是「免 gas fee 的」。同樣的,gasless 也不是真的不需要支付 gas fee,而是指用戶不需要被迫去了解 gas 概念,更不用提前購買各種原生 Token 來支付 gas。

那麼 gas 誰來付?分兩種情況:

一種是用戶賬戶裡已經有 crypto asset 的時候,比如 play to earn 得到 token,或者領到的 空投,亦或是別人的轉賬,只要這些 token 有一定的價值和流動性,就會有 relayer 願意接受它們並幫用戶支付 gas,以此賺取收益。

另一種是用戶賬戶裡沒有有價 token,比如剛剛創建的賬戶。如果此時需要鏈上交互,應用方可以選擇資助用戶一些「定向」用途的 gas 來幫他們 bootstrap,從而降低用戶流失,這時即便算上 gas 補貼的消耗,整體的用戶獲取成本反而可能會更低;或者可以通過讓用戶觀看廣告等方式來換取一些 gas。這兩種策略在 gas 成本較低的 L2 上都非常有效。

Social Recovery

社交恢複 是指利用社交關系幫助用戶在丟失密鑰的情況下重新獲得賬戶訪問權的機制。如果你用微信登錄過新設備,應該有過「讓你的兩個朋友發送 xxx 給你的賬號以登錄」的體驗——這就是社交恢複想達到的效果,只不過驗證方從微信變成了智能合約。

一種常見的誤區是把利用社交賬號來創建 / 登錄錢包的方案稱為社交恢複,這是錯把「社交關系」與「社交平臺賬號」劃了等號。老牌智能合約錢包 Argent 就內置了社交恢複能力,它要求你的 guardian 提供一個以太坊地址,從而在你需要登陸新設備時提供簽名來進行授權,然而這一方案的潛在設定就是:你的 guardian 一定比你在管理以太坊賬戶上更專業,否則當你需要他們簽名的時候,如果他們自己的賬戶已經無法訪問,你的賬戶也會連帶遭殃。所以一種更加可行的辦法是利用 email 的密碼學證明(DKIM Signature)或者電子護照等生活中常見的密碼學工具來增強社交恢複方案的實用性。

Non-custodial

非托管 可以說是 crypto 行業最政治正確、也是被濫用最多的概念之一了,因為很多時候各家都會有自己的定義。這裡我也分享一下我們對非托管的定義,主要有兩方面:

1. 錢包開發商無法擅自操作用戶的賬戶

2. 錢包開發商無法阻止用戶操作自己的賬戶

如果你也認同這兩點,那麼判斷一個錢包是托管、半托管還是非托管就可以直接拿這兩個規則去檢驗了:

不滿足 1 – 托管;滿足 1 – 不滿足 2 – 半托管;1、2 都滿足 – 非托管。

那麼知道了是哪種托管程度有甚麼用嗎,用戶可能並不 care 背後的原理,只要好用就行了唄!沒錯,其實我也部分認同這種觀點,至少在現在的階段,行業還沒有發展到發生用戶認知範式轉移的程度。其實我認為三種類型的方案分別適用於不同的場景:

1. 托管方案 – 適用於交易平臺、大機構金服、強合規等場景,比如 coinbase 提供的一些服務。特點是用戶量少,不需要應對高頻交互,而且客單價高,能支撐服務商花費大成本來維護一系列高防系統。

2. 半托管方案 – 適用於相對高端的個人用戶群體。他們明白服務方可以審查自己的交易,並且有能力提前準備備份方案(比如導出私鑰),在服務方主動或被動拒絕服務時可以不影嚮自己的資產安全。這樣日常使用時可以享受安全和便利,極端情況下可以保全資產。註意這種方案對服務商的運維能力要求也非常高,畢竟個人用戶量大,日常跟各種應用的交互需求也更高,再就是對數據可用性要求高,畢竟一旦丟失服務端保存的數據有可能導致所有沒備份的用戶永遠無法訪問賬戶。

3. 非托管方案 – 適用於面向 mass adoption 的場景。初聽上去可能是反直覺的,但是從成本上講,非托管方案是唯一能夠在低客單價的場景裡保證足夠的安全性和可用性的方案。如果一個面向大規糢用戶場景的應用方打算選擇上面兩種方案,就一定要考慮對方能否為自己的用戶群提供足夠安全可用的服務,否則一旦內部人員作惡、黑客入侵或不可抗力導致服務停擺,自己的所有用戶都會受到牽連,自己的業務也可能因此一蹶不振。历史上的無數次案例都在講述一個故事,安全無小事,為用戶負責就是為自己負責。

MPC – Multi-Party Computation

多方安全計算 跟零知識證明(ZKP)可以並稱當下 Web3 兩大「魔法」,一旦跟它們沾邊,似乎原來做不到的事情 somehow 就能做了。實際上有些情況是這樣的,尤其是 ZKP,可以利用概率換可行性;MPC 則是通過分散控制權來達成風控或者災備能力。

MPC 其實是一種範式,包含很多技術方案,在目前 Web3 的語境下大都指的是 tss。

TSS – Threshold Signature Scheme

門限簽名 是一種分布式多方簽名協議,包含分布式密鑰生成、簽名,以及在不改變公鑰的情況下更換私鑰碎片的 re-sharing 等算法。

一個 m-n 的 tss 指的是一個公鑰對應了 n 個私鑰碎片,其中 m 個碎片的聯合簽名可以被公鑰驗簽成功。不難發現這個邏輯類似於多簽(multi-sig),他們的區別主要在公鑰的數量上。

舉例來說,2-2 的多簽是一個門上掛了 2 把鎖,必須用兩個鑰匙把它們都打開才能開門;2-2 的 tss 是一個門上掛了 1 把鎖,但是鑰匙有兩片,合起來用才能打開門。這裡為了好理解,描述並不嚴謹,兩把鑰匙合成一把其實更符合 Shamir Secret Sharing 算法的情況;tss 算法下的密鑰碎片是不會相遇的,而是它們分別簽名之後,通過特定算法可以用對應的公鑰驗簽通過。

那麼 tss 是不是一定是托管或者非托管的?其實沒有必然聯繫,主要看最終的方案如何設計和取舍。非托管方案要求用戶擁有獨立操作賬戶的能力,所以用戶必須掌握不少於門限數量的密鑰碎片,例如 2-3 的話用戶需要掌握 2 片,而 2-2 的方案無法達成非托管,最多可以做到半托管(比如 ZenGo);但是如果用戶管理最多的私鑰碎片,那麼勢必會提高對用戶能力的要求,很難做到 mass adoption。

以太全書
版權聲明:本站原創文章,由 以太全書 2022-10-24發表,共計6552字。
轉載說明:除特殊說明外,本站文章如需轉載請註明出處。