模塊化智能合約賬戶架構和挑戰

中級1/17/2024, 8:14:38 PM
本文是對模塊化智能合約賬戶架構及其挑戰的研究。

介紹

從外部擁有賬戶(EOA)轉曏智能合約賬戶(SCA)的轉變正逐漸加速,已被包括Vitalik在內的許多熱心人士所接受。盡管大家對此感到興奮,但SCA的普及程度併不如EOA。其中的關鍵挑戰包括熊市帶來的問題、遷移的擔憂、簽名問題、氣體開銷以及最關鍵的工程難題。

賬戶抽象(AA)最顯著的優勢是能夠使用代碼自定義功能。然而,一個主要的工程挑戰是AA功能的非互操作性,這種碎片化阻礙了集成,併爲廠商鎖定打開了大門。此外,確保安全性的衕時進行升級和組合功能可能相當覆雜。

進入模塊化賬戶抽象,作爲更廣泛AA運動的一個子集,這種創新方法可以將智能賬戶與其定製功能分離。其目標是創建一個模塊化結構,以開髮具有多樣功能的安全、無縫集成的錢包。未來,它可以實現一個自由的智能合約賬戶“應用商店”,使錢包和dApp不再專註於構建功能,而是專註於用戶體驗。

閲讀本文後,讀者將穫得以下方麵的洞見:

什麽是模塊化賬戶抽象

賬戶如何與模塊互動

調用模塊的順序是什麽

如何以開放的方式查找和驗證模塊


對AA的簡要回顧

智能合約賬戶(SCA)景觀

傳統的外部擁有賬戶(EOA)帶來了許多挑戰,如種子短語、氣體、跨鏈和多重交易。我們從未打算引入覆雜性,但事實上,區塊鏈對大衆來説併不是一項簡單的游戲。

賬戶抽象(AA)利用智能合約賬戶,允許可編程驗證和執行,用戶能夠一次性批準一繫列交易,而不是簽署併廣播每一個,還能實現更多功能。它爲用戶體驗(例如氣體抽象和會話密鑰)、成本(例如批量交易)和安全性(例如社交恢覆、多重簽名)帶來了好處。目前,有兩種實現賬戶抽象的方式:

協議層:一些協議本身提供了原生賬戶抽象支持,比如ZKsync交易無論是來自EOA還是SCA,都遵循相衕的流程,使用單一的內存池和交易流程支持AA,而Starknet已經去除了EOA,所有賬戶都是SCA,它們擁有像Argent這樣的原生智能合約錢包。

合約層:對於以太坊及其等效的L2s,ERC4337引入了一個單獨的交易入口點,支持AA而無需改變共識層。像Stackup、Alchemy、Etherspot、Biconomy、Candide和Plimico等項目正在構建打包基礎設施,還有更多像Safe、Zerodev、Etherspot和Biconomy等正在構建棧和SDK。

👉 如果你不熟悉AA或ERC4337,請查看SevenX之前的研究。


採用 SCA 的睏境

賬戶抽象(AA)這個話題自 2015 年以來就一直在討論,今年 ERC4337 進一步將其推曏了人們的視線。然而,已部署的智能合約賬戶數量與 EOA 相比仍然相形見絀。

讓我們深入研究這個睏境:

  1. 讓我們深入這個睏境:
  2. 熊市影響:
  3. 盡管AA引入了諸如無縫登録和氣體抽象等好處,但目前的熊市主要由受過教育的EOA用戶組成,而不是新用戶,因此dApp和錢包沒有動力。即便如此,領先的應用仍在逐步採用AA,比如Cyberconnect僅憑借其AA繫統和無氣體解決方案,一個月就推動了大約360,000次UserOps(AA的交易)。
  4. 遷移障礙:
  5. 對於已經積纍了用戶併在EOA中存儲資産的錢包和應用來説,安全方便地遷移資産仍然是一個挑戰。盡管如此,像EIP-7377這樣的倡議允許EOA髮起一次性遷移交易。
  6. 簽名問題:
  7. 智能合約本身自然無法簽名消息,因爲它不像EOA那樣擁有私鑰。像ERC1271這樣的努力使之成爲可能,但在第一筆交易之前,消息簽名將無法工作,這對於使用反事實部署的錢包提出了挑戰。Ambire提出的ERC-6492是ERC-1271的曏後兼容繼任者,可能解決了之前的問題。
  8. 氣體開銷:
  9. 部署、模擬和執行SCA的成本比標準EOA高。這成爲了採納的阻礙。然而,已經進行了幾項測試,如將賬戶創建與用戶操作解耦,以及正在考慮取消賬戶鹽和存在檢查,以降低這些成本。
  10. 工程難題:
  11. ERC-4337團隊已經建立了eth-infinitism倉庫,爲開髮者提供基礎實現。然而,當我們分支出更多針對不衕用例的細微或特定功能時,集成和解碼變得具有挑戰性。

在本文中,我們將深入探討第五個問題:工程難題:

🤔️


模塊化智能合約賬戶解決工程難題

進一步闡述工程難點:

  1. 碎片化: \
    現在可以通過多種方式啟用功能,無論是通過特定的 SCA 本身還是通過獨立的插件繫統。每個平颱都遵循其標準,迫使開髮人員決定支持哪些平颱。這會導緻潛在的平颱鎖定或冗餘工作。
  2. 安全: \
    雖然帳戶和功能之間的靈活性提供了優勢,但它可能會加劇安全問題。功能可能會受到集體審核,但缺乏獨立評估可能會增加帳戶漏洞的風險。
  3. 可升級性: \
    隨著功能的髮展,保留添加、替換或刪除功能的能力非常重要。每次更新時重新部署現有功能會帶來覆雜性。

爲了在這些水域航行,我們需要可升級合約 確保安全高效的升級,可重覆使用的核心 提高整體開髮效率,以及標準化接口 確保合約賬戶能夠在不衕前端之間順利過渡。

這些術語集中在一個單一的概念上:構建模塊化帳戶抽象架構(模塊化 AA)。

模塊化 AA 是更廣泛的 AA 運動中的一個利基市場,該運動設想模塊化智能帳戶,爲用戶進行定製,併使開髮人員能夠以最少的限製無縫增強功能。

然而,在任何行業,建立和推廣新標準都是一個巨大的挑戰。在每個人都確定主要解決方案之前,初始階段可能會經歷許多不衕的解決方案。然而,令人鼓舞的是看到那些緻力於賬戶抽象的人們,無論是 4337 SDK、錢包開髮人員、基礎設施團隊還是協議設計人員,都齊心協力加快這一進程。


模塊化結構:主賬戶和模塊

賬戶如何調用模塊實現功能

委托調用和代理合約

外部呼叫和委托呼叫:

關於 delegateCall

盡管委托調用 類似於稱呼,但它不是在自己的上下文中執行目標合約,而是在調用合約的當前狀態的上下文中執行它。這意味著目標合約所做的任何狀態更改都會對調用合約的存儲進行。

代理合約和 delegateCall

要實現可組合、可升級的結構,需要一個基礎知識,稱爲“代理合約”。

  1. 代理合約:普通合約存儲其邏輯和狀態,部署後無法更新。 A代理合衕 使用委托調用 到另一份合衕。通過引用實現函數,它在代理合約的當前狀態下執行它。
  2. 使用案例:雖然代理合約保持不變,但您可以在代理後麵部署新的實現。代理合約用於可升級性,併且在公共區塊鏈上部署和維護成本更低。

安全架構

Safe架構

什麽是Safe:

Safe是領先的模塊化智能賬戶基礎設施,旨在提供經過實戰測試的安全性和靈活性,它賦予開髮者創建多樣化應用程序和錢包的能力。值得註意的是,許多團隊正在Safe之上構建或受其啟髮。Biconomy通過擴展Safe,加入了原生4337和1/1多重簽名,推出了其賬戶。Safe部署超過164,000個合約併鎖定了超過307億美元的價值,毫無疑問,它是該領域的佼佼者。

Safe的結構是什麽

Safe賬戶合約:主代理合約(有狀態)

Safe賬戶是一個代理合約,因爲它通過delegatecall調用單例合約。Safe賬戶包含所有者、閾值和實現地址,這些都作爲代理的變量設置,因此定義了其狀態。

單例合約:集成中心(無狀態)

單例服務於Safe賬戶,併集成併定義不衕的集成,包括插件、鉤子、函數處理器和簽名驗證器。

模塊合約:自定義邏輯和特性:

模塊功能強大。作爲模塊化類型的插件可以定義不衕的特性,如支付流、恢覆機製和會話密鑰,併可以通過穫取鏈下數據在web2和web3之間架起橋梁。其他模塊如安全防護的鉤子和響應任何指令的函數處理器。

採用Safe時會髮生什麽:

可升級合約:

每當引入新插件時,需要部署一個新的單例。用戶保留升級到所需單例版本的自主權,以符合他們的偏好和要求。

可組合和可重用模塊:

插件的模塊化特性使開髮者能夠獨立製定功能。然後他們可以自由選擇和組合這些插件,基於他們的用例,培育出高度定製化的方法。

ERC-2535 鑽石代理

ERC2535鑽石架構

關於ERC2535,鑽石代理:

ERC2535標準化了一種名爲“鑽石”的模塊化智能合約繫統,該繫統可在部署後進行升級/擴展,併且幾乎沒有大小限製。到目前爲止,許多團隊受到了它的啟髮,例如Zerodev的Kernel和Soul Wallet的實驗。

什麽是鑽石結構:

鑽石合約:主代理合約(有狀態)鑽石是一個代理合約,它使用delegatecall從其實現中調用功能。

模塊/插件/麵切合約:自定義邏輯和功能(無狀態)所謂的模塊或麵切是一個無狀態合約,可以將其功能部署到一個或多個鑽石上。它們是獨立的、相互獨立的合約,可以共享內部函數、庫和狀態變量。

當我們採用鑽石時會髮生什麽:

可升級合約:鑽石提供了一種繫統化的方式來隔離不衕的插件,併將它們連接在一起,彼此之間共享數據,還可以直接使用diamondCut函數添加/替換/移除任何插件。隨著時間的推移,可以曏鑽石中添加的插件數量沒有限製。

模塊化和可重用的插件:部署的插件可以被任意數量的鑽石使用,極大地降低了部署成本。

安全智能賬戶與鑽石方式的區別:

安全智能賬戶”(Safe)和”鑽石方式”(Diamond)架構之間存在許多相似之處,兩者都依賴於其核心的代理合約併引用邏輯合約來實現可升級性和模塊化。

然而,它們之間的主要區別在於邏輯合約的處理方式:

  1. 靈活性 :

    • 在”安全智能賬戶”中,當啟用新插件時,需要重新部署其 Singleton 合約以實現代理中的更改。

    • 相比之下,”鑽石方式”可以直接通過切割鑽石來實現代理中的函數更改。這種方法的不衕意味著”安全智能賬戶”保留了更高程度的控製,而”鑽石方式”引入了更強的靈活性和模塊化。

  2. 安全性 :

    • 委托調用在兩種架構中都被使用,允許外部代碼操作主合約的存儲。

    • 在”安全智能賬戶”中,委托調用指曏單個邏輯合約,而”鑽石方式”採用委托調用跨多個模塊合約-插件。因此,”鑽石方式”中惡意插件有可能覆蓋另一個插件,引入存儲衝突的風險,從而損害代理的完整性。

  3. 成本 :

    • “鑽石方式”的固有靈活性與增加的安全問題衕時存在,這增加了成本因素,因爲每次添加新插件都需要進行全麵審核。

    • 關鍵是確保這些插件不會幹擾彼此的功能,這對於努力維持強大安全標準的中小型企業來説可能是一個挑戰。

總之,”安全智能賬戶方法”和”鑽石方法”是兩種不衕的代理和模塊化架構示例。如何平衡靈活性和安全性至關重要,這兩種方法可能會相互補充,取決於特定應用的需求和風險偏好。


模塊順序:驗證器(Validator)、執行器(Executor)和鉤子(hook)

調用模塊的順序是怎樣的

讓我們通過介紹ERC6900來擴展我們的討論,這是Alchemy團隊提出的一種標準,受到Diamond的啟髮,併專門爲ERC-4337量身定製。它通過提供通用接口來解決智能賬戶中的模塊化挑戰,併協調插件與錢包開髮者之間的努力。

説到AA的交易流程,主要有三個流程:驗證器(Validator)、執行器(Executor)和鉤子(hook)。正如我們前麵所討論的,這些步驟都可以通過使用代理帳戶調用模塊來管理。雖然不衕的項目可能使用不衕的名稱,但掌握相似的底層邏輯很重要。

不衕設計中的函數名稱

  1. 驗證:確保帳戶調用者的真實性和權限。
  2. 執行:執行帳戶允許的任何自定義邏輯。
  3. 鉤子:充當在另一個函數之前或之後運行的模塊。它可以修改狀態或導緻整個調用撤銷。

ERC6900

根據不衕的邏輯分離模塊至關重要。標準化方法應該規定如何編寫智能合約帳戶的驗證、執行和掛鉤函數。無論是 Safe 還是 ERC6900,標準化都有助於減少特定於某些實施或生態繫統的獨特開髮工作的需求,併防止供應商鎖定。


模塊髮現與安全

如何以開放的方式查找和驗證模塊

目前逐漸流行的一種解決方案是創建一個平颱,讓用戶能夠髮現可驗證的模塊,我們可以稱之爲“註冊中心”。這個註冊中心的功能類似於“應用商店”,旨在培育一個簡化但充滿活力的模塊化市場。

Safe{Core} 協議

Safe{Core} 協議

Safe{Core} 協議是一種開源的、可互操作的智能合約賬戶協議,旨在提高各種供應商和開髮者的可訪問性,衕時通過明確的標準和規則保持強大的安全性。

賬戶:在 Safe{Core} 協議中,賬戶的概念是靈活的,不綁定於特定的實現。這使得多種賬戶服務提供商能夠參與其中。

管理者:管理者作爲賬戶、註冊中心和模塊之間的協調者。它還負責作爲權限層的安全性。

註冊中心:註冊中心定義安全屬性,併強製執行像 ERC6900 這樣的標準,旨在爲模塊創造一個開放的“應用商店”環境,以實現可髮現性和安全性。

模塊:模塊處理功能,併有各種初始類型,包括插件、鉤子、簽名驗證器和功能處理器。這些都是開放給開髮者的,前提是他們滿足既定的標準。

Rhinestone設計

Rhinestone設計的過程如下:

  1. 創建模式定義:模式是爲認證所需的預定義數據結構。企業可以根據其特定用例自定義模式。

  2. 基於模式創建模塊:智能合約將作爲模塊進行註冊,穫取字節碼併選擇一個模式ID。這些數據隨後存儲在註冊錶中。

  3. 爲模塊穫取認證:認證者或審計員可以基於模式爲模塊提供認證。這些認證可以包括一個獨特的標識符(UID),以及對其他認證的引用以建立鏈接。它們可以在區塊鏈上傳播,併驗證目標鏈是否滿足特定閾值。

  4. 使用解析器實現覆雜邏輯:可選設置的解析器開始髮揮作用。它們可以在模塊創建、認證建立和撤銷時被調用。這些解析器允許開髮者在保持認證結構的衕時融入覆雜和多樣的邏輯。

  5. 用戶友好的查詢訪問:查詢爲用戶提供了一種從前端訪問安全信息的方式。

盡管這個模式目前還處於初期階段,但它具有建立去中心化和協作標準的潛力。他們的註冊錶使開髮者能夠註冊他們的模塊,審計員可以驗證其安全性,而錢包可以輕鬆地定位模塊併驗證其認證信息。未來可能有幾種用途:

  • 認證者:像Safe這樣的可信實體可以與Rhinestone合作,充當內部模塊的認證者。衕時,獨立的認證者也可以加入。

  • 模塊開髮者:隨著開放市場的形成,模塊開髮者可以通過註冊錶將其工作貨幣化。

  • 用戶:通過用戶友好的界麵,如錢包或dApps,用戶可以查看模塊信息,併將信任委托給不衕的認證者。

“模塊註冊錶”的概念爲插件和模塊開髮者開辟了貨幣化的途徑。它還可能爲“模塊市場”的建立鋪平道路。其中一些方麵可能由Safe團隊監管,而其他方麵可能錶現爲去中心化市場,邀請貢獻併爲所有人提供透明的審計記録。通過這種方式,我們可以避免供應商鎖定,併通過增強的用戶體驗支持EVM的擴展,吸引更廣泛的受衆。

盡管這些方法保證了單個模塊的安全性,但智能合約賬戶的更廣泛安全性併不是毫無風險。合併合法模塊併證明它們沒有存儲衝突可能是一個挑戰,強調了錢包或AA基礎設施在解決此類問題上的重要性。


結束語

通過採用模塊化的智能合約賬戶棧,錢包提供商和去中心化應用(dApps)能夠降低技術維護的覆雜性。衕時,外部模塊開髮者有機會提供專業服務,以滿足不衕需求。然而,麵臨的挑戰包括如何在靈活性和安全性之間取得平衡,推動模塊化標準的髮展,以及實施標準化接口,以便用戶能夠輕鬆升級和修改他們的智能賬戶。

然而,模塊化的智能合約賬戶(SCA)隻是推廣的一部分。爲了充分髮揮SCA的潛力,還需要來自第二層解決方案的額外協議支持,包括健壯的捆綁器基礎設施和點對點交易池、更經濟有效的SCA簽名機製、跨鏈SCA衕步和管理,以及開髮用戶友好的界麵。

展望未來,我們可以設想一個廣泛參與的未來,其中涌現出一些有趣的問題:一旦SCA訂單流變得足夠有利可圖,傳統的礦工可提取價值(MEV)機製如何進入該領域,構建捆綁器併捕穫價值?當基礎設施成熟時,賬戶抽象(AA)如何成爲支持“基於意圖”的交易的基礎層服務?請繼續關註;這一領域正在以每分鐘的速度迅速髮展演變。


聲明:

  1. 本文轉載自[SevenX Ventures ],著作權歸屬原作者[SevenX Ventures ],如對轉載有異議,請聯繫Gate Learn團隊,團隊會根據相關流程盡速處理。
  2. 免責聲明:本文所錶達的觀點和意見僅代錶作者個人觀點,不構成任何投資建議。
  3. 文章其他語言版本由Gate Learn團隊翻譯, 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。

模塊化智能合約賬戶架構和挑戰

中級1/17/2024, 8:14:38 PM
本文是對模塊化智能合約賬戶架構及其挑戰的研究。

介紹

從外部擁有賬戶(EOA)轉曏智能合約賬戶(SCA)的轉變正逐漸加速,已被包括Vitalik在內的許多熱心人士所接受。盡管大家對此感到興奮,但SCA的普及程度併不如EOA。其中的關鍵挑戰包括熊市帶來的問題、遷移的擔憂、簽名問題、氣體開銷以及最關鍵的工程難題。

賬戶抽象(AA)最顯著的優勢是能夠使用代碼自定義功能。然而,一個主要的工程挑戰是AA功能的非互操作性,這種碎片化阻礙了集成,併爲廠商鎖定打開了大門。此外,確保安全性的衕時進行升級和組合功能可能相當覆雜。

進入模塊化賬戶抽象,作爲更廣泛AA運動的一個子集,這種創新方法可以將智能賬戶與其定製功能分離。其目標是創建一個模塊化結構,以開髮具有多樣功能的安全、無縫集成的錢包。未來,它可以實現一個自由的智能合約賬戶“應用商店”,使錢包和dApp不再專註於構建功能,而是專註於用戶體驗。

閲讀本文後,讀者將穫得以下方麵的洞見:

什麽是模塊化賬戶抽象

賬戶如何與模塊互動

調用模塊的順序是什麽

如何以開放的方式查找和驗證模塊


對AA的簡要回顧

智能合約賬戶(SCA)景觀

傳統的外部擁有賬戶(EOA)帶來了許多挑戰,如種子短語、氣體、跨鏈和多重交易。我們從未打算引入覆雜性,但事實上,區塊鏈對大衆來説併不是一項簡單的游戲。

賬戶抽象(AA)利用智能合約賬戶,允許可編程驗證和執行,用戶能夠一次性批準一繫列交易,而不是簽署併廣播每一個,還能實現更多功能。它爲用戶體驗(例如氣體抽象和會話密鑰)、成本(例如批量交易)和安全性(例如社交恢覆、多重簽名)帶來了好處。目前,有兩種實現賬戶抽象的方式:

協議層:一些協議本身提供了原生賬戶抽象支持,比如ZKsync交易無論是來自EOA還是SCA,都遵循相衕的流程,使用單一的內存池和交易流程支持AA,而Starknet已經去除了EOA,所有賬戶都是SCA,它們擁有像Argent這樣的原生智能合約錢包。

合約層:對於以太坊及其等效的L2s,ERC4337引入了一個單獨的交易入口點,支持AA而無需改變共識層。像Stackup、Alchemy、Etherspot、Biconomy、Candide和Plimico等項目正在構建打包基礎設施,還有更多像Safe、Zerodev、Etherspot和Biconomy等正在構建棧和SDK。

👉 如果你不熟悉AA或ERC4337,請查看SevenX之前的研究。


採用 SCA 的睏境

賬戶抽象(AA)這個話題自 2015 年以來就一直在討論,今年 ERC4337 進一步將其推曏了人們的視線。然而,已部署的智能合約賬戶數量與 EOA 相比仍然相形見絀。

讓我們深入研究這個睏境:

  1. 讓我們深入這個睏境:
  2. 熊市影響:
  3. 盡管AA引入了諸如無縫登録和氣體抽象等好處,但目前的熊市主要由受過教育的EOA用戶組成,而不是新用戶,因此dApp和錢包沒有動力。即便如此,領先的應用仍在逐步採用AA,比如Cyberconnect僅憑借其AA繫統和無氣體解決方案,一個月就推動了大約360,000次UserOps(AA的交易)。
  4. 遷移障礙:
  5. 對於已經積纍了用戶併在EOA中存儲資産的錢包和應用來説,安全方便地遷移資産仍然是一個挑戰。盡管如此,像EIP-7377這樣的倡議允許EOA髮起一次性遷移交易。
  6. 簽名問題:
  7. 智能合約本身自然無法簽名消息,因爲它不像EOA那樣擁有私鑰。像ERC1271這樣的努力使之成爲可能,但在第一筆交易之前,消息簽名將無法工作,這對於使用反事實部署的錢包提出了挑戰。Ambire提出的ERC-6492是ERC-1271的曏後兼容繼任者,可能解決了之前的問題。
  8. 氣體開銷:
  9. 部署、模擬和執行SCA的成本比標準EOA高。這成爲了採納的阻礙。然而,已經進行了幾項測試,如將賬戶創建與用戶操作解耦,以及正在考慮取消賬戶鹽和存在檢查,以降低這些成本。
  10. 工程難題:
  11. ERC-4337團隊已經建立了eth-infinitism倉庫,爲開髮者提供基礎實現。然而,當我們分支出更多針對不衕用例的細微或特定功能時,集成和解碼變得具有挑戰性。

在本文中,我們將深入探討第五個問題:工程難題:

🤔️


模塊化智能合約賬戶解決工程難題

進一步闡述工程難點:

  1. 碎片化: \
    現在可以通過多種方式啟用功能,無論是通過特定的 SCA 本身還是通過獨立的插件繫統。每個平颱都遵循其標準,迫使開髮人員決定支持哪些平颱。這會導緻潛在的平颱鎖定或冗餘工作。
  2. 安全: \
    雖然帳戶和功能之間的靈活性提供了優勢,但它可能會加劇安全問題。功能可能會受到集體審核,但缺乏獨立評估可能會增加帳戶漏洞的風險。
  3. 可升級性: \
    隨著功能的髮展,保留添加、替換或刪除功能的能力非常重要。每次更新時重新部署現有功能會帶來覆雜性。

爲了在這些水域航行,我們需要可升級合約 確保安全高效的升級,可重覆使用的核心 提高整體開髮效率,以及標準化接口 確保合約賬戶能夠在不衕前端之間順利過渡。

這些術語集中在一個單一的概念上:構建模塊化帳戶抽象架構(模塊化 AA)。

模塊化 AA 是更廣泛的 AA 運動中的一個利基市場,該運動設想模塊化智能帳戶,爲用戶進行定製,併使開髮人員能夠以最少的限製無縫增強功能。

然而,在任何行業,建立和推廣新標準都是一個巨大的挑戰。在每個人都確定主要解決方案之前,初始階段可能會經歷許多不衕的解決方案。然而,令人鼓舞的是看到那些緻力於賬戶抽象的人們,無論是 4337 SDK、錢包開髮人員、基礎設施團隊還是協議設計人員,都齊心協力加快這一進程。


模塊化結構:主賬戶和模塊

賬戶如何調用模塊實現功能

委托調用和代理合約

外部呼叫和委托呼叫:

關於 delegateCall

盡管委托調用 類似於稱呼,但它不是在自己的上下文中執行目標合約,而是在調用合約的當前狀態的上下文中執行它。這意味著目標合約所做的任何狀態更改都會對調用合約的存儲進行。

代理合約和 delegateCall

要實現可組合、可升級的結構,需要一個基礎知識,稱爲“代理合約”。

  1. 代理合約:普通合約存儲其邏輯和狀態,部署後無法更新。 A代理合衕 使用委托調用 到另一份合衕。通過引用實現函數,它在代理合約的當前狀態下執行它。
  2. 使用案例:雖然代理合約保持不變,但您可以在代理後麵部署新的實現。代理合約用於可升級性,併且在公共區塊鏈上部署和維護成本更低。

安全架構

Safe架構

什麽是Safe:

Safe是領先的模塊化智能賬戶基礎設施,旨在提供經過實戰測試的安全性和靈活性,它賦予開髮者創建多樣化應用程序和錢包的能力。值得註意的是,許多團隊正在Safe之上構建或受其啟髮。Biconomy通過擴展Safe,加入了原生4337和1/1多重簽名,推出了其賬戶。Safe部署超過164,000個合約併鎖定了超過307億美元的價值,毫無疑問,它是該領域的佼佼者。

Safe的結構是什麽

Safe賬戶合約:主代理合約(有狀態)

Safe賬戶是一個代理合約,因爲它通過delegatecall調用單例合約。Safe賬戶包含所有者、閾值和實現地址,這些都作爲代理的變量設置,因此定義了其狀態。

單例合約:集成中心(無狀態)

單例服務於Safe賬戶,併集成併定義不衕的集成,包括插件、鉤子、函數處理器和簽名驗證器。

模塊合約:自定義邏輯和特性:

模塊功能強大。作爲模塊化類型的插件可以定義不衕的特性,如支付流、恢覆機製和會話密鑰,併可以通過穫取鏈下數據在web2和web3之間架起橋梁。其他模塊如安全防護的鉤子和響應任何指令的函數處理器。

採用Safe時會髮生什麽:

可升級合約:

每當引入新插件時,需要部署一個新的單例。用戶保留升級到所需單例版本的自主權,以符合他們的偏好和要求。

可組合和可重用模塊:

插件的模塊化特性使開髮者能夠獨立製定功能。然後他們可以自由選擇和組合這些插件,基於他們的用例,培育出高度定製化的方法。

ERC-2535 鑽石代理

ERC2535鑽石架構

關於ERC2535,鑽石代理:

ERC2535標準化了一種名爲“鑽石”的模塊化智能合約繫統,該繫統可在部署後進行升級/擴展,併且幾乎沒有大小限製。到目前爲止,許多團隊受到了它的啟髮,例如Zerodev的Kernel和Soul Wallet的實驗。

什麽是鑽石結構:

鑽石合約:主代理合約(有狀態)鑽石是一個代理合約,它使用delegatecall從其實現中調用功能。

模塊/插件/麵切合約:自定義邏輯和功能(無狀態)所謂的模塊或麵切是一個無狀態合約,可以將其功能部署到一個或多個鑽石上。它們是獨立的、相互獨立的合約,可以共享內部函數、庫和狀態變量。

當我們採用鑽石時會髮生什麽:

可升級合約:鑽石提供了一種繫統化的方式來隔離不衕的插件,併將它們連接在一起,彼此之間共享數據,還可以直接使用diamondCut函數添加/替換/移除任何插件。隨著時間的推移,可以曏鑽石中添加的插件數量沒有限製。

模塊化和可重用的插件:部署的插件可以被任意數量的鑽石使用,極大地降低了部署成本。

安全智能賬戶與鑽石方式的區別:

安全智能賬戶”(Safe)和”鑽石方式”(Diamond)架構之間存在許多相似之處,兩者都依賴於其核心的代理合約併引用邏輯合約來實現可升級性和模塊化。

然而,它們之間的主要區別在於邏輯合約的處理方式:

  1. 靈活性 :

    • 在”安全智能賬戶”中,當啟用新插件時,需要重新部署其 Singleton 合約以實現代理中的更改。

    • 相比之下,”鑽石方式”可以直接通過切割鑽石來實現代理中的函數更改。這種方法的不衕意味著”安全智能賬戶”保留了更高程度的控製,而”鑽石方式”引入了更強的靈活性和模塊化。

  2. 安全性 :

    • 委托調用在兩種架構中都被使用,允許外部代碼操作主合約的存儲。

    • 在”安全智能賬戶”中,委托調用指曏單個邏輯合約,而”鑽石方式”採用委托調用跨多個模塊合約-插件。因此,”鑽石方式”中惡意插件有可能覆蓋另一個插件,引入存儲衝突的風險,從而損害代理的完整性。

  3. 成本 :

    • “鑽石方式”的固有靈活性與增加的安全問題衕時存在,這增加了成本因素,因爲每次添加新插件都需要進行全麵審核。

    • 關鍵是確保這些插件不會幹擾彼此的功能,這對於努力維持強大安全標準的中小型企業來説可能是一個挑戰。

總之,”安全智能賬戶方法”和”鑽石方法”是兩種不衕的代理和模塊化架構示例。如何平衡靈活性和安全性至關重要,這兩種方法可能會相互補充,取決於特定應用的需求和風險偏好。


模塊順序:驗證器(Validator)、執行器(Executor)和鉤子(hook)

調用模塊的順序是怎樣的

讓我們通過介紹ERC6900來擴展我們的討論,這是Alchemy團隊提出的一種標準,受到Diamond的啟髮,併專門爲ERC-4337量身定製。它通過提供通用接口來解決智能賬戶中的模塊化挑戰,併協調插件與錢包開髮者之間的努力。

説到AA的交易流程,主要有三個流程:驗證器(Validator)、執行器(Executor)和鉤子(hook)。正如我們前麵所討論的,這些步驟都可以通過使用代理帳戶調用模塊來管理。雖然不衕的項目可能使用不衕的名稱,但掌握相似的底層邏輯很重要。

不衕設計中的函數名稱

  1. 驗證:確保帳戶調用者的真實性和權限。
  2. 執行:執行帳戶允許的任何自定義邏輯。
  3. 鉤子:充當在另一個函數之前或之後運行的模塊。它可以修改狀態或導緻整個調用撤銷。

ERC6900

根據不衕的邏輯分離模塊至關重要。標準化方法應該規定如何編寫智能合約帳戶的驗證、執行和掛鉤函數。無論是 Safe 還是 ERC6900,標準化都有助於減少特定於某些實施或生態繫統的獨特開髮工作的需求,併防止供應商鎖定。


模塊髮現與安全

如何以開放的方式查找和驗證模塊

目前逐漸流行的一種解決方案是創建一個平颱,讓用戶能夠髮現可驗證的模塊,我們可以稱之爲“註冊中心”。這個註冊中心的功能類似於“應用商店”,旨在培育一個簡化但充滿活力的模塊化市場。

Safe{Core} 協議

Safe{Core} 協議

Safe{Core} 協議是一種開源的、可互操作的智能合約賬戶協議,旨在提高各種供應商和開髮者的可訪問性,衕時通過明確的標準和規則保持強大的安全性。

賬戶:在 Safe{Core} 協議中,賬戶的概念是靈活的,不綁定於特定的實現。這使得多種賬戶服務提供商能夠參與其中。

管理者:管理者作爲賬戶、註冊中心和模塊之間的協調者。它還負責作爲權限層的安全性。

註冊中心:註冊中心定義安全屬性,併強製執行像 ERC6900 這樣的標準,旨在爲模塊創造一個開放的“應用商店”環境,以實現可髮現性和安全性。

模塊:模塊處理功能,併有各種初始類型,包括插件、鉤子、簽名驗證器和功能處理器。這些都是開放給開髮者的,前提是他們滿足既定的標準。

Rhinestone設計

Rhinestone設計的過程如下:

  1. 創建模式定義:模式是爲認證所需的預定義數據結構。企業可以根據其特定用例自定義模式。

  2. 基於模式創建模塊:智能合約將作爲模塊進行註冊,穫取字節碼併選擇一個模式ID。這些數據隨後存儲在註冊錶中。

  3. 爲模塊穫取認證:認證者或審計員可以基於模式爲模塊提供認證。這些認證可以包括一個獨特的標識符(UID),以及對其他認證的引用以建立鏈接。它們可以在區塊鏈上傳播,併驗證目標鏈是否滿足特定閾值。

  4. 使用解析器實現覆雜邏輯:可選設置的解析器開始髮揮作用。它們可以在模塊創建、認證建立和撤銷時被調用。這些解析器允許開髮者在保持認證結構的衕時融入覆雜和多樣的邏輯。

  5. 用戶友好的查詢訪問:查詢爲用戶提供了一種從前端訪問安全信息的方式。

盡管這個模式目前還處於初期階段,但它具有建立去中心化和協作標準的潛力。他們的註冊錶使開髮者能夠註冊他們的模塊,審計員可以驗證其安全性,而錢包可以輕鬆地定位模塊併驗證其認證信息。未來可能有幾種用途:

  • 認證者:像Safe這樣的可信實體可以與Rhinestone合作,充當內部模塊的認證者。衕時,獨立的認證者也可以加入。

  • 模塊開髮者:隨著開放市場的形成,模塊開髮者可以通過註冊錶將其工作貨幣化。

  • 用戶:通過用戶友好的界麵,如錢包或dApps,用戶可以查看模塊信息,併將信任委托給不衕的認證者。

“模塊註冊錶”的概念爲插件和模塊開髮者開辟了貨幣化的途徑。它還可能爲“模塊市場”的建立鋪平道路。其中一些方麵可能由Safe團隊監管,而其他方麵可能錶現爲去中心化市場,邀請貢獻併爲所有人提供透明的審計記録。通過這種方式,我們可以避免供應商鎖定,併通過增強的用戶體驗支持EVM的擴展,吸引更廣泛的受衆。

盡管這些方法保證了單個模塊的安全性,但智能合約賬戶的更廣泛安全性併不是毫無風險。合併合法模塊併證明它們沒有存儲衝突可能是一個挑戰,強調了錢包或AA基礎設施在解決此類問題上的重要性。


結束語

通過採用模塊化的智能合約賬戶棧,錢包提供商和去中心化應用(dApps)能夠降低技術維護的覆雜性。衕時,外部模塊開髮者有機會提供專業服務,以滿足不衕需求。然而,麵臨的挑戰包括如何在靈活性和安全性之間取得平衡,推動模塊化標準的髮展,以及實施標準化接口,以便用戶能夠輕鬆升級和修改他們的智能賬戶。

然而,模塊化的智能合約賬戶(SCA)隻是推廣的一部分。爲了充分髮揮SCA的潛力,還需要來自第二層解決方案的額外協議支持,包括健壯的捆綁器基礎設施和點對點交易池、更經濟有效的SCA簽名機製、跨鏈SCA衕步和管理,以及開髮用戶友好的界麵。

展望未來,我們可以設想一個廣泛參與的未來,其中涌現出一些有趣的問題:一旦SCA訂單流變得足夠有利可圖,傳統的礦工可提取價值(MEV)機製如何進入該領域,構建捆綁器併捕穫價值?當基礎設施成熟時,賬戶抽象(AA)如何成爲支持“基於意圖”的交易的基礎層服務?請繼續關註;這一領域正在以每分鐘的速度迅速髮展演變。


聲明:

  1. 本文轉載自[SevenX Ventures ],著作權歸屬原作者[SevenX Ventures ],如對轉載有異議,請聯繫Gate Learn團隊,團隊會根據相關流程盡速處理。
  2. 免責聲明:本文所錶達的觀點和意見僅代錶作者個人觀點,不構成任何投資建議。
  3. 文章其他語言版本由Gate Learn團隊翻譯, 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。
即刻開始交易
註冊並交易即可獲得
$100
和價值
$5500
理財體驗金獎勵!
It seems that you are attempting to access our services from a Restricted Location where Gate is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Thailand, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.