作者：Seungmin Jeon 來源：medium 翻譯：善歐巴，金色財經(jīng)
首爾國立大學(xué)區(qū)塊鏈學(xué)院的 Decipher Open Source Warriors 團(tuán)隊(duì)撰寫了一篇關(guān)于 ERC-6900 的文章。本文基于代碼進(jìn)行分析，從提案的背景到實(shí)現(xiàn)的方法和意義。
ERC-4337是一個標(biāo)準(zhǔn)，允許在不改變以太坊客戶端的情況下順利使用合約錢包（賬戶），通過一個名為“用戶操作”的對象進(jìn)行額外的驗(yàn)證，取代傳統(tǒng)交易。遵循 ERC-4337 標(biāo)準(zhǔn)的合約賬戶可以包含各種功能，例如支付 Gas 費(fèi)用的 Paymaster、批量交易、BLS 簽名聚合、社交恢復(fù)和會話密鑰。
與傳統(tǒng)的 EOA（外部擁有帳戶）相比，這可以實(shí)現(xiàn)更高水平的用戶體驗(yàn)。例如，使用ERC-4337的paymaster，用戶可以使用ERC-20代幣而不是ETH來支付gas費(fèi)，或者讓協(xié)議支付。此外，如果用戶可以通過會話密鑰臨時將其帳戶委托給協(xié)議，則不必為每筆交易單擊按鈕，他們只需單擊一下即可與協(xié)議進(jìn)行交互。
然而，ERC-4337的提出是為了在不改變協(xié)議的情況下實(shí)現(xiàn)賬戶抽象，因此并沒有定義智能合約賬戶應(yīng)該采取什么形式。于是，各種形式的合約賬戶被提出，導(dǎo)致以下兩個問題：
1.不同賬戶形式導(dǎo)致的兼容性問題
目前，各個公司（例如ZeroDev、Biconomy）都提供SDK形式的合約賬戶，但每個公司提供的賬戶形式都不同，導(dǎo)致兼容性問題。這使得支持合約錢包的應(yīng)用程序的用戶很難在應(yīng)用程序之外使用這些錢包，也使得應(yīng)用程序很難容納各種合約賬戶的用戶。換句話說，雖然通過 ERC-4337 改進(jìn)了 UX，但它具有將用戶鎖定在應(yīng)用內(nèi)的副作用。
2.賬戶的擴(kuò)展性問題
通過 ERC-4337 提供的大多數(shù)功能都在賬戶內(nèi)運(yùn)行，但由于賬戶采用智能合約的形式，因此更改和可擴(kuò)展性都受到限制。雖然可以對賬戶應(yīng)用Proxy結(jié)構(gòu)來進(jìn)行升級，但這個過程也很不方便。例如，如果用戶想要向其現(xiàn)有合約帳戶添加新功能，則必須將整個代碼轉(zhuǎn)移到具有該功能的新合約中。此升級過程可能會導(dǎo)致新合同的額外審計成本等問題。此外，由于為所有用戶提供統(tǒng)一形式的帳戶，因此存在用戶無法選擇其帳戶內(nèi)的功能的缺點(diǎn)。
為了解決這些問題，2023 年 4 月提出了名為 ERC-6900 的新標(biāo)準(zhǔn)。
ERC-6900 是一個名為“模塊化智能合約賬戶和插件”的 EIP，為與 ERC-4337 兼容的賬戶提供了標(biāo)準(zhǔn)。它基于模塊化結(jié)構(gòu)，允許在帳戶中自由安裝和刪除各種功能，類似于在 Android 上安裝或卸載應(yīng)用程序。包含要包含在帳戶中的功能的模塊合約稱為插件。
ERC-6900通過其模塊化結(jié)構(gòu)，使用戶能夠輕松地向其帳戶添加或刪除各種插件（功能）。特別是，由于當(dāng)前的合約帳戶通常僅限于特定應(yīng)用程序，因此使用 ERC-6900 可以允許單個合約帳戶輕松地在多個應(yīng)用程序中使用。
雖然這是一個非常有趣的想法，但在實(shí)際代碼中實(shí)現(xiàn)它時必須考慮以下因素，重點(diǎn)關(guān)注安全性和用戶體驗(yàn)：
插件的安裝和刪除
首先考慮的應(yīng)該是如何實(shí)現(xiàn)插件的安裝和刪除。ERC-6900 的開發(fā)者從 Diamond Proxy 中汲取了靈感。Diamond Proxy 是典型可升級代理的擴(kuò)展結(jié)構(gòu)，將合約劃分為多個組件（或方面），并只允許其中的某些組件進(jìn)行升級。與簡單的可升級代理結(jié)構(gòu)不同，簡單的可升級代理結(jié)構(gòu)需要更改整個邏輯合約才能進(jìn)行升級，鉆石代理允許僅選擇和升級所需的組件。
在 Diamond Proxy 中，合約的各種功能被劃分為稱為 Facet 的組件，Proxy 使用 來調(diào)用它們delegatecall。delegatecall是一個“借用”外部合約函數(shù)并在自己的合約上下文中使用它們的函數(shù)，允許通過外部函數(shù)對其自己的合約存儲進(jìn)行強(qiáng)大的操作。
此外，Diamond Proxy 維護(hù)基于函數(shù)選擇器的映射，以指定每個方面的訪問路徑。這允許代理合約自由訪問每個方面內(nèi)的功能。
Diamond Proxy 的結(jié)構(gòu) 來源：ERC-2535 官方文檔
此外，為了安全起見，Diamond Proxy 將所有數(shù)據(jù)存儲在代理合約中，并將可訪問的數(shù)據(jù)分配給每個方面。如果對facet使用的數(shù)據(jù)沒有權(quán)限限制，在某些情況下可能會出現(xiàn)問題。例如，zkSync 在以太坊上部署了類似 Diamond 代理的合約，為治理、L1 ? L2 橋接和匯總數(shù)據(jù)發(fā)布創(chuàng)建了方面。如果治理方面可以訪問用于橋接的參數(shù)，則可能會因不當(dāng)操作或攻擊而危及整個系統(tǒng)。
總結(jié)起來，Diamond Proxy 具有三個主要特點(diǎn)：
協(xié)議功能分為多個方面合約，通過 訪問delegatecall。
代理合約可以通過函數(shù)的選擇器調(diào)用切面函數(shù)。
每個方面可訪問的數(shù)據(jù)都受到限制。
Diamond Proxy 具有這些特性，針對構(gòu)建多功能合約系統(tǒng)進(jìn)行了優(yōu)化。這與 ERC-6900 創(chuàng)建“具有各種功能的智能合約賬戶”的目標(biāo)非常吻合。因此，ERC-6900借用了Diamond Proxy的結(jié)構(gòu)來實(shí)現(xiàn)安裝和刪除插件的功能。然而，ERC-6900 和 Diamond Proxy 之間存在顯著差異，稍后將討論。
2. 用戶與賬戶交互
假設(shè)建立了一個可以自由安裝和刪除插件的環(huán)境，那么要考慮的第二個方面是用戶如何與帳戶交互。合約賬戶與用戶的交互主要分為兩種：一是通過ERC-4337的入口點(diǎn)合約進(jìn)行用戶操作進(jìn)行交互，二是用戶直接調(diào)用合約賬戶內(nèi)的函數(shù)。ERC-6900 將這兩種類型的交互分別區(qū)分為“用戶操作驗(yàn)證”和“運(yùn)行時驗(yàn)證”，并為每種交互提供單獨(dú)的驗(yàn)證和執(zhí)行流程。
3. 許可
要考慮的第三個方面是許可。如果任何人都可以創(chuàng)建和安裝插件，則必須考慮這些插件被濫用的可能性。例如，想象一個會話密鑰插件，它可以在一段時間內(nèi)提供帳戶所有權(quán)。如果會話密鑰所有者與惡意合約交互，則帳戶的資金可能會完全丟失。因此，嚴(yán)格設(shè)置和驗(yàn)證插件可以訪問的外部合約功能以及插件之間交互的權(quán)限至關(guān)重要。
4. 保證模塊化
最后要考慮的是如何保證模塊化。在可以自由安裝和從帳戶中刪除各種插件的環(huán)境中，存在一些可能導(dǎo)致意外結(jié)果的邊緣情況。例如，插件 A 和 B 可能具有具有相同選擇器的功能。與 Diamond Proxy 一樣，ERC-6900 使用選擇器映射來調(diào)用插件內(nèi)的函數(shù)，但如果這些選擇器重疊，則存儲在先前安裝的插件的選擇器中的信息可能會被刪除，并替換為后來安裝的插件中的信息。
這可能會導(dǎo)致帳戶出現(xiàn)意外錯誤，因此需要加以預(yù)防。
為了解決這個問題，ERC-6900 引入了一項(xiàng)稱為“依賴性”的功能。當(dāng)想要從中借用函數(shù)或插件中的特定函數(shù)具有相同的選擇器和功能時，此機(jī)制通過將已部署的插件設(shè)置為依賴項(xiàng)來防止沖突。
因此，ERC-6900的特點(diǎn)可以概括為四點(diǎn)：
它遵循 Diamond Proxy 的結(jié)構(gòu)（但有顯著差異，稍后將討論）。
用戶交互分為用戶操作和運(yùn)行時，每種交互都有不同的驗(yàn)證和執(zhí)行過程。
它嚴(yán)格限制通過插件進(jìn)行的操作權(quán)限。
為了防止沖突并確保插件安裝和刪除過程中的模塊化，可以設(shè)置依賴關(guān)系。
在接下來的章節(jié)中，我們將仔細(xì)研究這四個方面。
Diamond Proxy
ERC-6900采用Diamond Proxy的結(jié)構(gòu)，形成插件和合約賬戶的模塊化結(jié)構(gòu)。該帳戶充當(dāng)代理合約，每個插件充當(dāng)一個方面。因此，當(dāng)帳戶發(fā)生用戶操作或直接調(diào)用時，它會通過后備函數(shù)（當(dāng)在合約中找不到被調(diào)用函數(shù)的選擇器時執(zhí)行的函數(shù)，通常在代理模式中使用）在插件內(nèi)進(jìn)行處理。在這個過程中，與前面提到的Diamond Proxy有一個至關(guān)重要的區(qū)別。
Diamond Proxy 用于delegatecall調(diào)用構(gòu)面內(nèi)的函數(shù)。由于facet是只包含執(zhí)行邏輯并且不需要存儲（有時甚至部署為沒有存儲的庫）的合約，因此delegatecall被使用。然而，在 ERC-6900 中，插件內(nèi)的函數(shù)被調(diào)用 using call，并且插件有自己的存儲。原因如下：
如果delegatecall帳戶允許插件，則插件的功能可以訪問帳戶的存儲數(shù)據(jù)。這是非常危險的，因?yàn)閻阂獠寮赡軙h除或操縱帳戶的存儲信息。這在最初的 Diamond Proxy 中并不是一個主要問題，因?yàn)椴⒎侨魏稳硕伎梢蕴砑訕?gòu)面。然而，由于 ERC-6900 的目標(biāo)是一個任何人都可以自由構(gòu)建插件的環(huán)境，因此delegatecall可能會帶來重大風(fēng)險。
因此，在 ERC-6900 中，call使用 代替delegatecall，允許數(shù)據(jù)也存儲在插件的存儲中。
MSCA 內(nèi)部的調(diào)用流程
在 ERC-6900 中，合約賬戶被稱為模塊化智能合約賬戶 (MSCA)。ERC-6900 定義的 MSCA 內(nèi)部的調(diào)用流程可以概括如下：
我們來看看用戶操作部分。在ERC-4337中，用戶操作的驗(yàn)證和執(zhí)行是分離的，因此流程分為驗(yàn)證和執(zhí)行，如上圖左側(cè)所示。另一方面，對于MSCA內(nèi)的直接調(diào)用，流程通過運(yùn)行時驗(yàn)證功能進(jìn)行驗(yàn)證，如右圖所示。每個流程都會經(jīng)歷幾個階段，包括驗(yàn)證函數(shù)、掛鉤和執(zhí)行函數(shù)。
這里使用的函數(shù)大致可以分為三種類型。首先，在帳戶或插件內(nèi)執(zhí)行某些操作的函數(shù)稱為執(zhí)行函數(shù)。隨后，對于每個執(zhí)行函數(shù)，都有一個驗(yàn)證函數(shù)對其調(diào)用進(jìn)行驗(yàn)證。此外，可以在每個函數(shù)調(diào)用之前和之后應(yīng)用掛鉤。讓我們更詳細(xì)地研究每一個。
驗(yàn)證功能
該函數(shù)對賬戶調(diào)用者進(jìn)行權(quán)限驗(yàn)證。如前所述，如果任何人都可以調(diào)用賬戶內(nèi)的函數(shù)，則該賬戶可能容易受到通過 Gas 消耗耗盡資金的攻擊。因此，消耗gas或訪問存儲的函數(shù)必須通過驗(yàn)證函數(shù)進(jìn)行控制。
有兩種類型的驗(yàn)證函數(shù)：用于從入口點(diǎn)傳入的調(diào)用的用戶操作驗(yàn)證函數(shù)，以及當(dāng) EOA 直接調(diào)用帳戶內(nèi)的函數(shù)時執(zhí)行的運(yùn)行時驗(yàn)證函數(shù)。
這些驗(yàn)證功能并不存在于賬戶本身；它們都可以在插件中找到。因此，對帳戶的所有調(diào)用都會通過插件中的驗(yàn)證函數(shù)。根據(jù)用例，可以有各種類型的驗(yàn)證函數(shù)，例如：
驗(yàn)證簽名并僅允許所有者的地址通過的功能。
驗(yàn)證簽名并僅允許指定地址通過的功能。
允許任何地址通過的函數(shù)。
2. 執(zhí)行函數(shù)
這些是實(shí)際資金轉(zhuǎn)移和與外部合約交互發(fā)生的功能。主要有兩種類型：
1) 標(biāo)準(zhǔn)執(zhí)行函數(shù)
指與ERC-4337參考實(shí)現(xiàn)的接口execute和executeBatch功能兼容。IAccount這些函數(shù)可以根據(jù)賬戶的gas費(fèi)執(zhí)行所有類型的交互，因此需要嚴(yán)格的驗(yàn)證函數(shù)（例如，只允許所有者調(diào)用）。
2）執(zhí)行函數(shù)
這些是每個插件中存在的功能以及可以從帳戶執(zhí)行的常用功能。例如，考慮recoverOwner在社交恢復(fù)插件中調(diào)用的函數(shù)。由于只有分配用于恢復(fù)的監(jiān)護(hù)人才能調(diào)用此函數(shù)，因此它必須具有適當(dāng)?shù)尿?yàn)證函數(shù)。在ERC-6900中，這應(yīng)用于執(zhí)行函數(shù)，如下所示：
通過將此信息存儲在帳戶的存儲中，當(dāng)recoverOwner調(diào)用該函數(shù)時，可以通過onlyGuardiansValidationFunction.
執(zhí)行函數(shù)的選擇器存儲在帳戶存儲中，在插件安裝時映射到插件地址。
3. 掛鉤
還有一個稱為鉤子的函數(shù)，它在其他函數(shù)之前和之后運(yùn)行。與Uniswap V4的Hook類似，它定義了特定任務(wù)之前和之后需要執(zhí)行的操作。例如，可能有一個DailyGasSpendingLimit限制每日燃?xì)庀牡?Hook。該鉤子可以在執(zhí)行函數(shù)之前和之后使用該函數(shù)檢查gas消耗情況gasleft()，如果一天內(nèi)消耗了一定量的gas，則阻止該函數(shù)的執(zhí)行。
驗(yàn)證函數(shù)之前還可以有一個預(yù)驗(yàn)證鉤子，主要用于需要多次驗(yàn)證的情況。例如，如果會話密鑰插件中的會話密鑰是多重簽名錢包，則它需要同時通過多重簽名和會話密鑰驗(yàn)證。在這種情況下，多重簽名的驗(yàn)證可以作為預(yù)驗(yàn)證掛鉤來執(zhí)行，而會話密鑰的驗(yàn)證可以作為驗(yàn)證函數(shù)來執(zhí)行。
更詳細(xì)的調(diào)用流程可以用下圖表示：
每個過程總結(jié)如下：
封裝并調(diào)用要執(zhí)行的插件的執(zhí)行函數(shù)calldata。如果帳戶中沒有與此函數(shù)匹配的選擇器，fallback則執(zhí)行該函數(shù)（這適用于除標(biāo)準(zhǔn)執(zhí)行函數(shù)（如 、 或稍后提到的 、 ）之外的execute所有executeBatch情況executeFromPlugin）executionFromPluginExternal。
解析出哪個插件地址包含 中的執(zhí)行函數(shù)后calldata，就會執(zhí)行關(guān)聯(lián)的預(yù)驗(yàn)證鉤子和驗(yàn)證函數(shù)。如果調(diào)用通過 ERC-4337 入口點(diǎn)，則驗(yàn)證邏輯已經(jīng)執(zhí)行，因此會被跳過。
執(zhí)行與 Execution 函數(shù)相關(guān)的預(yù)執(zhí)行鉤子。此掛鉤執(zhí)行的結(jié)果返回有關(guān)要運(yùn)行哪個執(zhí)行后掛鉤的信息。
執(zhí)行函數(shù)被執(zhí)行。
根據(jù)步驟3返回的結(jié)果，執(zhí)行執(zhí)行后掛鉤。
這里重要的一點(diǎn)是，msg.sender對插件的調(diào)用始終是帳戶。因此，在插件中存儲或查詢帳戶相關(guān)信息時，msg.sender使用如下：
這意味著該插件的功能是建立在從賬戶調(diào)用的前提下的。但是，這可能會導(dǎo)致以下問題：
如果從另一個帳戶或插件調(diào)用特定插件的函數(shù)，msg.sender則將其設(shè)置為調(diào)用者，引用與從帳戶調(diào)用時不同的存儲，從而導(dǎo)致不同的結(jié)果。如果某個特定插件需要調(diào)用另一個插件中的函數(shù)，如何解決這個問題？
executeFromPlugin 為了解決這個問題，ERC-6900 定義了和 等函數(shù)executeFromPluginExternal。這些功能不僅解決了上述問題，還可以防止賬戶受到各種攻擊場景。
executeFromPlugin和executeFromPluginExternal是定義和限制可以通過插件執(zhí)行的任務(wù)的函數(shù)，每個函數(shù)都具有以下功能：
executeFromPlugin當(dāng)一個插件想要調(diào)用另一個插件中的函數(shù)時使用。它設(shè)置msg.sender為帳戶，允許在另一個插件中執(zhí)行執(zhí)行函數(shù)，而不會引用錯誤的存儲或丟失調(diào)用的上下文。此外，為了防止惡意插件的攻擊，如果該函數(shù)不是安裝時預(yù)先指定的插件的函數(shù)，則該函數(shù)會恢復(fù)調(diào)用。
另一方面，executeFromPluginExternal更加注重安全問題。當(dāng)插件想要調(diào)用外部實(shí)體中的函數(shù)時使用它。一個典型的用例是會話密鑰插件。如果具有會話密鑰的地址可以調(diào)用任何外部函數(shù)，則會帶來重大的安全風(fēng)險。因此，有必要預(yù)先指定會話密鑰可以訪問的外部合約和函數(shù)，并在嘗試訪問未列出的函數(shù)時恢復(fù)調(diào)用。根據(jù) ERC-6900 標(biāo)準(zhǔn)實(shí)現(xiàn)這一點(diǎn)如下所示：
首先，在插件內(nèi)指定可以訪問的外部合約和函數(shù)。這在插件部署期間被硬編碼到合約中，使其以后不可變。
然后，在同一個插件中定義以下執(zhí)行函數(shù)：
executeFromPluginExternal當(dāng)會話密鑰通過調(diào)用帳戶內(nèi)的函數(shù)發(fā)送令牌時，使用此函數(shù)。在executeFromPluginExternal帳戶內(nèi)執(zhí)行以下步驟：
從存儲中檢索預(yù)定義的允許呼叫信息。
將此信息與輸入的呼叫信息進(jìn)行比較，如果不允許呼叫，則恢復(fù)。
執(zhí)行調(diào)用。如果有執(zhí)行鉤子，它也會被執(zhí)行。
因此，executeFromPlugin并executeFromPluginExternal限制插件可以執(zhí)行的功能。msg.sender這不僅可以防止從插件內(nèi)直接調(diào)用另一個插件時調(diào)用 () 的上下文發(fā)生更改，而且還可以限制對外部合約的訪問。
然而，不可能完全禁止插件通過executeFromPluginExternal. 它無法阻止插件內(nèi)的執(zhí)行函數(shù)對地址進(jìn)行硬編碼并從外部調(diào)用。因此，只有已完成審核的插件才應(yīng)安裝在帳戶上，以防止黑客攻擊等問題。
依賴性
最后，一個插件可以對其他插件有依賴性（dependency）。這主要在從其他插件借用函數(shù)（驗(yàn)證函數(shù)、執(zhí)行函數(shù)）時使用。一個典型的例子是SingleOwnerPlugin參考實(shí)現(xiàn)中的。它包含一個只允許所有者調(diào)用的函數(shù)，如下所示：
由于這是一個非常通用的驗(yàn)證函數(shù)，其他插件可能會借用并使用它。在這種情況下，如果在安裝插件時將其作為依賴項(xiàng)輸入，則可以在插件中使用驗(yàn)證功能，而無需單獨(dú)實(shí)現(xiàn)該功能。
當(dāng)特定執(zhí)行函數(shù)的驗(yàn)證函數(shù)重疊時，此功能極大地有助于減少代碼的大小并提高可讀性。具有只有所有者才能訪問的功能的插件可以將上述 SingleOwnerPlugin 設(shè)置為依賴項(xiàng)，并對其功能使用其驗(yàn)證功能。
因此，可以從其他插件接收所有 Hook、驗(yàn)證函數(shù)和執(zhí)行函數(shù)，如上所示。換句話說，可以基于依賴關(guān)系來實(shí)現(xiàn)插件的模塊化架構(gòu)。
這方面的一個例子可以在上面提到的類似代理的結(jié)構(gòu)中看到。基本驗(yàn)證函數(shù)和必要的數(shù)據(jù)位于“父插件”中，多個“子插件”僅包含邏輯并依賴于父插件中的驗(yàn)證函數(shù)。這允許安全地添加、刪除或替換邏輯，同時保留父插件合約中的數(shù)據(jù)和上下文。
Decipher Open Source Warriors 團(tuán)隊(duì)利用插件的模塊化架構(gòu)和上述功能，實(shí)現(xiàn)了符合 ERC-6900 標(biāo)準(zhǔn)的會話密鑰插件，executeFromPluginExternal并向官方 ERC-6900 實(shí)現(xiàn) GitHub 請求拉取請求。目前，我們正在根據(jù) PR 后收到的反饋對其進(jìn)行修改，并計劃為基于社區(qū)的插件提供一個單獨(dú)的位置。
會話密鑰插件由一個名為 的父插件BaseSessionKeyPlugin和一個名為 的子插件組成TokenSessionKeyPlugin。與現(xiàn)有的會話密鑰實(shí)現(xiàn)相比，該插件具有以下兩個優(yōu)點(diǎn)：
通過使用依賴關(guān)系，它可以管理單個父插件中的所有會話密鑰信息。
通過使用executeFromPluginExternal，它嚴(yán)格限制子插件可以訪問的外部合約，從而即使在會話密鑰被惡意或被黑客攻擊的情況下也可以防止帳戶內(nèi)的資金外流。
顯現(xiàn)
最后，為了確保安全安裝而不與其他安裝的插件發(fā)生沖突，插件有一個名為manifest. 它包括有關(guān)插件的執(zhí)行函數(shù)、驗(yàn)證函數(shù)、掛鉤以及依賴項(xiàng)、允許的調(diào)用等的信息。在安裝過程中，會驗(yàn)證此信息，并將插件內(nèi)函數(shù)的所有選擇器存儲在帳戶的存儲中。
ERC-6900仍有許多問題需要解決，原因如下：
1.合約規(guī)模
參考實(shí)現(xiàn)中智能賬戶UpgradeableModularAccount.sol的合約大小約為33KB。以太坊將可在主網(wǎng)上部署的合約的最大大小限制為 24KB，這是 2016 年Spurious Dragon硬分叉中設(shè)置的限制。因此，該合約尚無法部署在主網(wǎng)或測試網(wǎng)上。
原因之一是因?yàn)?ERC-6900 使用call而不是delegatecall. 通過在外部庫或合約中實(shí)現(xiàn)一些函數(shù)并通過調(diào)用它們delegatecall，可以在縮小合約大小的同時修改帳戶存儲。然而，由于ERC-6900出于安全原因限制了使用delegatecall，訪問存儲的功能必須在合約內(nèi)實(shí)現(xiàn)，從而增加了合約的大小。
因此，需要努力減少合約的規(guī)模，例如重構(gòu)冗余部分。
2. Gas Consumption
從調(diào)用流程圖中可以看出，ERC-6900 包括賬戶和插件之間的多次調(diào)用，這增加了 Gas 成本。根據(jù)實(shí)現(xiàn)情況，每次外部合約調(diào)用大約消耗 2,000 GAS。雖然如果只涉及一個插件（熱/冷地址），這一成本可能會略有降低，但如果涉及多個插件，成本就會變得昂貴，增加用戶的負(fù)擔(dān)。然而，通過gas優(yōu)化來降低用戶成本至關(guān)重要，例如在賬戶和插件合約的功能中使用組裝塊。實(shí)現(xiàn) ERC-6900 的 Alchemy 團(tuán)隊(duì)正在考慮根據(jù)各種選項(xiàng)修改架構(gòu)，例如應(yīng)用 Dencun 更新附帶的 EIP-1153 的臨時存儲或?qū)⒍鄠€驗(yàn)證步驟捆綁到多重調(diào)用中。
同時，當(dāng)前的參考實(shí)現(xiàn)部分犧牲了可讀性的優(yōu)化。Alchemy 團(tuán)隊(duì)計劃在明年初將其更新為可部署在主網(wǎng)上，屆時，第 1 點(diǎn)和第 2 點(diǎn)提到的問題預(yù)計將大部分得到解決。
3. 插件實(shí)現(xiàn)的復(fù)雜性
從開發(fā)人員的角度來看，實(shí)現(xiàn)插件需要考慮許多因素。雖然有很多復(fù)雜性，但一些例子包括：
決定是直接定義與每個執(zhí)行函數(shù)關(guān)聯(lián)的驗(yàn)證函數(shù)，還是通過其他插件的依賴設(shè)置接收它們。
當(dāng)需要對調(diào)用者進(jìn)行多次驗(yàn)證時，確定如何劃分和設(shè)置預(yù)驗(yàn)證鉤子和驗(yàn)證函數(shù)。
確保與現(xiàn)有插件的兼容性。例如，如果要在插件中實(shí)現(xiàn)的功能已經(jīng)存在于現(xiàn)有插件中，則需要通過調(diào)用它executeFromPlugin或?qū)⑵湓O(shè)置為依賴項(xiàng)。
這些復(fù)雜性可以從不同的角度來解決。首先，架構(gòu)本身可以添加某種形式的接口或方法來抽象復(fù)雜性。需要為插件開發(fā)人員提供文檔，并且可以開發(fā)一個組織現(xiàn)有插件的功能和方法的儀表板，以方便管理依賴項(xiàng)和executeFromPlugin.
Alchemy 團(tuán)隊(duì)正在致力于更新以降低所指出的復(fù)雜性，以響應(yīng)通過 Telegram 和每兩周一次的社區(qū)電話收到的社區(qū)反饋。
ERC-6900 允許從帳戶安裝和刪除插件，類似于安裝和卸載 Android 應(yīng)用程序。這使得用戶能夠根據(jù)自己的需求和偏好個性化他們的錢包并添加或刪除功能，從而創(chuàng)建定制的用戶環(huán)境。它將解決ERC-4337兼容錢包之間的兼容性問題，允許在不同錢包平臺之間自由移動。
此外，ERC-6900提出了一個可以被合約賬戶廣泛接受的通用標(biāo)準(zhǔn)，同時融入了各種元素以促進(jìn)實(shí)施并增強(qiáng)賬戶安全性。
修改后的 Diamond 代理結(jié)構(gòu)，用于安全安裝和刪除插件。
函數(shù)（驗(yàn)證函數(shù)、執(zhí)行函數(shù)、掛鉤）和調(diào)用流程結(jié)構(gòu)可有效、安全地管理帳戶和插件之間的交互。
權(quán)限設(shè)置保證插件的靈活性和安全性。
依賴關(guān)系可防止插件之間功能重疊引起的沖突并幫助代碼優(yōu)化。
通過該標(biāo)準(zhǔn)，預(yù)計以太坊和EVM兼容鏈的錢包生態(tài)系統(tǒng)將得到發(fā)展，用戶體驗(yàn)將得到顯著改善。
ERC-6900 官方文檔
ERC-6900 參考實(shí)現(xiàn) GitHub
ERC-6900 社區(qū)通話
喜來順財經(jīng)
