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