Safe的共同創辦人Lukas、Alchemy的工程主管Noam、Rhinestone的共同創辦人Kurt和Konrad以及HashKey Capital的投資人Arnav表示感謝。智慧合約帳戶（SCA）的發展勢頭強勁，得到了包括Vitalik在內的眾多核心創業者的支持，但其採用面臨一些消防挑戰。帳戶抽象化（AA）的優勢在於使用程式碼自訂功能，但其非互通性帶來了一些整合和供應商鎖定的問題。為了充分發揮SCA的潛力，需要Layer 2解決方案提供額外的協議層支援、增強的bundler基礎和點對點內存礦池設施、增加成本效益和安裝SCA簽名機制、跨鏈SCA同步和管理機制，以及開發用戶介面的介面。未來，目前的挑戰階段性解決方案，將會有更多的人採用SCA。
感謝Safe 的共同創辦人Lukas、 Alchemy 的工程主管Noam、Rhinestone 的共同創辦人Kurt 和Konrad 以及HashKey Capital 的投資人Arnav。
編者按：智慧合約帳戶（SCA）的發展勢頭強勁，得到了包括Vitalik 在內的眾多核心創業家的支持，然而SCA 的採用即將面臨消防挑戰。帳戶抽象化（AA）的優勢在於使用程式碼自訂功能，但其非互通性帶來了整合和供應商鎖定的問題。預設帳戶抽象化旨在創建一個自訂結構，以開發具有多種功能、安全且無縫整合的錢包。
SevenX Ventures 投資人Rui 指出了採用SCA 面臨的五大挑戰，即熊市影響、遷移增量、簽名問題、高昂的Gas 成本和工程問題，客觀的工程問題更做了進一步的討論。此外，在對智慧智慧約定帳戶的架構進行分析後，自訂SCA僅採用問題的一部分。
為了充分發揮SCA的潛力，需要Layer 2解決方案提供額外的協議層支持，增強的bundler基礎和點對點內存礦池設施、增加成本效益和安裝SCA簽名機制、跨鏈SCA同步和管理機制，以及開發用戶介面的介面等。
在未來，目前的挑戰階段性解決方案，將會有更多的人採用SCA，那麼接下來又會發生什麼事？ Rui 為此也提出了一些有趣的問題。 BlockBeats 將編譯如下：
從外部擁有帳戶（EOA）向智慧合約帳戶（SCA）的轉變聲勢強勁，並已經得到了包括Vitalik 等眾多核心創業者的支持。儘管如此，SCA 的採用卻不像EOA 那麼廣泛。這其中的主要問題包括熊市帶來的影響、eoa到sca的遷移入口、簽名問題、Gas成本以及極為關鍵的開發問題。
帳戶抽象化（AA）最顯著的優勢是能夠使用程式碼自訂功能。然而，AA 功能的非互通性帶來了主要挑戰，這種去中心化性會阻礙AA 集成，並加強了供應商的鎖定。除此之外除此之外，在可升級與可組合約時安全性也是重要的挑戰。
客製化帳戶抽象化的出現是AA發展趨勢中的一個細分領域，這種創新的方法可以將智慧帳戶與自訂功能分開。其目標是創建一個客製化結構，來開發具有多樣化功能、安全、無憂的功能。未來，客製化帳戶抽象化可以實現一個自由的智慧合約帳戶「應用程式商店」，使錢包和dApp 的重點在於提高用戶體驗，而不必在構建功能上耗費過多精力。
簡述帳戶摘要（AA）
在人們接觸區塊鏈的過程中，傳統的EOA 帶來了許多挑戰，如助記詞、Gas 費用、跨鏈操作和多重交易等。
帳戶抽象利用智慧合約帳戶，允許即時驗證（驗證）和執行（執行）。這意味著用戶將能夠批量批准一系列交易，而不再需要對每筆交易簽名和廣播。帳戶抽像都還可以實現更多功能，例如提高用戶體驗（如Gas抽象和會話金鑰）、降低成本（如大量交易）和提高安全性（如社交恢復、通話簽名）。目前，有兩種實現帳戶抽象化的方式：
協議層：一些協議本身提供了本地帳戶抽象支持，ZKSync 交易使用單一內存礦池和交易流程來支持AA；無論是來自EOA 還是SCA 都遵循相同的流程，而Starknet 已經移除了EOA，所有帳戶都是SCA，而且他們有像Argent這樣的本地智慧合約錢包。約定層：對於以太坊及類似的L2，ERC 4337引進了一個單獨的記憶體礦池，以在不改變共識層的情況下支援AA。像是Stackup、Alchemy、Etherspot、 Biconomy、Candide和Plimico正在建造捆綁器基礎設施，而像Safe、Zerodev、Etherspot 和Biconomy 正在建造捆綁器和SDK。採用SCA面臨的困境
自2015年以來，帳戶抽象（AA）的話題一直被討論，並在今年由ERC 4337進一步將其推進人們的視線中。然而，已部署的智慧合約帳戶數量仍然不如EOA。
讓我們深入研究這個困境：
1. 熊市的影響
儘管AA 擁有類似的無縫登入和Gas Abstract 等優勢，但在最近的熊市，所有用戶都是已受教育的EOA 用戶，而沒有太多新用戶，因此dApp 和錢包並沒有動力去採用SCA。 ，一些領先的dApp 在逐步採用AA，例如Cyberconnect 通過引入他們的AA 系統和無Gas 解決方案，僅僅一個月就帶動了約36 萬次UserOps（AA 交易）。
2. 遷徙
對於已經增持了用戶和資產的錢包和應用程式來說，安全、便捷地遷移資產仍然是一個挑戰。不過，像EIP-7377 這樣的方案可以讓EOA 發起一次性遷移交易。
3.簽名問題
智能合約本身無法簽署訊息，它不像EOA 那樣的私鑰。類似ERC 1271 的嘗試使之成為可能，但訊息簽名在第一筆交易之前因為失效的，這又用於使用反配置事實的錢包提出了挑戰。由Ambire 提出的ERC-6492 是ERC-1271 相容的繼任者，也許能夠解決先前的問題。
4. 天然氣成本
與標準EOA 相比，部署、模擬和執行SCA 之一會產生更高的成本，這也成為了採用障礙的一些。不過，目前已經進行了測試，例如將帳戶建立與使用者操作分開、刪除與某些帳戶相關的「SALT」等。
5. 工程問題
ERC-4337團隊已經建立了eth-infinitism repo，為開發人員提供了基礎實作。然而，隨著開發者針對不同的分支進行更協調和具體的功能時，整合和解碼會面臨更多挑戰。本文中，我們將深入探討工程問題。
透過客製化智能合約帳戶來解決工程問題
工程問題可進一步闡述為廢棄物化、安全性和可升級性三個面向。
顆粒化現在可以透過多種方式實現功能，是透過特定的SCA還是透過獨立的插件系統。每個平台和服務商都遵循自己的標準，促使開發者決定支援哪些平台和服務商。這可能會導致潛在的平台（供應商）鎖定或工作。安全性雖然帳戶和功能解耦帶來了靈活的優勢，但也可能使安全問題更加嚴重。因為所有功能可能會同時審核，而缺乏獨立評估可能會增加帳戶漏洞的風險。可升級性隨著帳戶的發展，保持新增、取代或刪除功能的能力非常重要，重新安裝現有功能的每次更新都會引入複雜性。
為了解決這些問題，我們需要可升級的合約以確保安全的高效升級、可重複使用的核心以提高整體開發效率、以及標準化的介面來確保合約帳戶能夠在不同的介面之間平穩過渡。
這些術語匯聚成一個共同的概念：建立自訂帳戶抽象架構（預設AA）。
等級帳戶抽像是廣泛的AA發展中的一個細分領域，它設想將智慧帳戶客製化，以客製化方式為用戶提供服務，淨化開發者能夠在最小化下無縫增強功能。
然而，在任何行業中建立和推廣新的標準都是一個巨大的挑戰。在大家都接受相同的標準之前，初始階段可能會出現許多不同的解決方案。令人印象深刻的是那些致力於完善和推廣的標準推廣帳戶抽象的人們，無論是4337 SDK、錢包、基礎設施團隊還是協議層設計師，他們都在共同努力加快這一進程。
具體結構：主帳戶和模組
帳戶如何呼叫模組實作功能
委託呼叫（Delegate call）和代理合約（proxy Contract）
外部呼叫和委託調用：
關於委託調用
「委託呼叫」與「呼叫」類似，但它不是在目標合約的上下文中執行，而是在呼叫合約的當前狀態的上下文中執行它。這意味著目標合約雖然執行的任何狀態變更都會變更呼叫合約的儲存。
代理契約和委託調用
要實現可組合、可升級的結構，需要引入一個基礎概念「代理合約」。
代理合約：普通合約儲存其邏輯和狀態，部署後無法更新。而代理合約使用委託呼叫（delegate call）部署到另一個合約。透過引用實現函數，在代理合約的當前狀態下執行。使用案例：雖然代理合約保持不變，但你可以在代理程式後面部署新的實作。代理合約實現了可升級性，且在公共區塊鏈上的部署並維護成本。
安全架構
安全架構
什麼是安全的：
安全是領先的高級智慧帳戶基礎設施，旨在提供經過實戰考驗的安全性和靈活性，它使開發人員能夠創建多樣化的應用程式和錢包。許多團隊正在安全基礎上（或受到安全啟發）建立應用程式。例如，Biconomy 在推出其智慧合約帳戶時，使用初始4337 和1/1 合約簽名來拓展安全。安全見證了超過164, 000 份合約並鎖定了超過307 億美元的價值，無疑問是該領域的傑出者。
安全的結構包括安全帳戶合約、單例合約、模組合約。
安全帳戶合約（代理合約）：主代理合約（Stateful） 安全帳戶是一個代理合約，這是因為委託呼叫是一個單例合約。安全帳戶包含主、閾值和實現位址都設定為代理的標誌，基於這些定義其狀態。單例合約（singleton Contract）：Integration Hub（無狀態） 安全帳戶中的單例合約服務，並定義了不同的模組合約集成，包括Plugin 、Hook、Function Handler 和Signature Validator。合約模組（modules）：自訂邏輯和功能合約模組功能強大。插件作為自訂類型可以定義不同的功能，例如支付流、復原機制和會話金鑰，並且可以透過取得鏈外資料作為Web2 和Web3 之間的橋樑。其他模組如作為安全防護的橋樑Hook 和Function Handler 可回應任何指令。
採用安全後帶來的改變：
可升級約定：每當引入新的插件時都需要配置新的單例。使用者保留將安全性升級到所需單例版本的自主權。可組合、可重複使用的模組：插件的客製化特性使開發人員能夠獨立開發功能。他們可以根據自己的例子形成自由選擇和組合這些插件，從而高度可自訂的方法。
ERC-2535 鑽石代理
關於ERC 2535、鑽石代理商：
ERC 2535標準化的鑽石模型，是一種分級智慧合約系統，可以在部署後升級/擴展，幾乎沒有大小限制。目前，許多團隊如Zerodev的Kernel、Soul錢包的實驗都獲得了鑽石結構的啟示。
什麼是鑽石結構：
Diamond合約：主要代理合約（有狀態）Diamond是一種代理合約，它使用委託呼叫方法從其實作中呼叫函數。 Facet 合約：自訂邏輯和功能（無狀態）模組或呼叫的Facet 是一種無狀態合約，可以將其功能部署到一個或多個Diamond。它們是獨立的、獨立的合約，可以共享內部函數、函式庫和狀態變數。
採用鑽石後帶來的改變：
可升級契約：Diamond 提供了一種系統化的方法來隔離不同的插件將它們連接在一起，在它們之間共享數據，還可以使用DiamondCut 功能直接添加/替換/刪除任何插件。 ，可以添加限製到Diamond 的插件數量將沒有。規範且可重複使用的插件：已部署的插件可以被任意數量的Diamond 使用，從而大大降低部署成本。
安全智慧帳戶與鑽石方式的差異：
安全和鑽石架構之間存在著許多相似之處，兩者都依賴其核心的代理合約並引用邏輯合約來實現可升級性和標準化。
兩者的主要差異在於邏輯契約的處理。具體來說：
靈活：在啟用新插件的情況下，Safe 需要重新配置其單例契約（Singleton）以實現其代理中的變更。相較之下，Diamond 直接透過其代理契約中的DiamondCut 函數來實現這一點。這種方法上的差異意味著安全性保留了更高程度的控制，而鑽石則引入了增強的靈活性和靈活性。安全性：目前在多種結構中使用的，可以允許外部程式碼聚合主合約的儲存。在安全架構中，委託呼叫指向單一符號合約，而Diamond則在多個模組合約-插件中使用委託呼叫。因此，惡意插件可能會覆蓋其他插件，從而引入儲存衝突的風險，損害代理的致命性。成本：在鑽石方法中，靈活與安全風險同時存在。這增加了成本，每次新增的插件都需要全面審核。關鍵是要確保這些插件不會幹擾去中心化的功能，這一目的具有挑戰性，特別是對於努力維持高安全標準的中小型企業而言。
「安全智慧帳戶方法」和「鑽石方法」是涉及代理和模組的不同結構的範例。如何平衡和靈活安全性至關重要，這兩種方法未來也會不斷演變、相互補充。
順序模組：驗證器（Validator）、執行器（Executor）和掛鉤（Hook）
讓我們透過介紹ERC-6900 來進一步討論，這是Alchemy 團隊提出的、受到Diamond 啟發、專門為ERC-4337 定制的標準。它透過提供通用介面來解決帳戶智慧定制的挑戰，並協調插件和錢包開發人員之間的工作。
說到AA的交易流程，主要有三個流程：驗證、執行、掛鉤。正如我們前面所討論的，這些步驟都可以透過使用代理帳戶呼叫模組來管理。雖然不同的項目可能使用不同的名稱，但掌握一下相似的脈絡很重要。
不同設計中的函數名稱
驗證（Validator）：確保帳戶呼叫者的真實性和權限。執行（Executor）：執行帳戶允許的任何自訂邏輯。修改掛鉤（Hook）：充當在另一個函數之前或運行之後的模組。它可以狀態或撤銷整個呼叫。
歐洲研究委員會6900
根據不同的邏輯來分離模組關鍵。標準化方法應規定如何撰寫智慧合約帳戶的驗證、執行和掛鉤功能。無論是安全還是ERC-6900，標準化都有助於減少特定於某些實施或生態系統獨特的開發工作需求，並防止供應商鎖定。
模組發現和安全
如何以開放的方式創建和模組：一個正在推進的解決方案涉及創建一個允許用戶發現可驗證模組的區域，可以將其稱為「驗證」。此園藝的功能類似於「應用程式商店」 ，旨在培育一個簡化但蓬勃發展的分級市場。
安全{核心}協議
Safe{Core}協議是一種針對智慧合約帳戶的開源、可互通的協議，旨在增強各種供應商和開發人員的可訪問性，同時透過明確定義的標準和規則來保持更強的安全性。
帳戶：在Safe{Core}協議中，帳戶的概念是靈活的，不受特定實現的約束。這使得不同的帳戶服務能夠參與其中。管理器：管理器充當帳戶、肥料和模組之間的協調員。它也作為許可層負責安全性。註冊中心：註冊中心定義安全屬性並執行ERC 6900等模組標準，旨在創建一個開放的「應用程式商店」環境，以實現可發現性和安全性。模組：模組處理功能並具有各種初始類型，包括插件、掛鉤、簽名驗證器和函數處理程序。只要符合既定標準，開發人員就可以參與其中。
水鑽設計
過程展開如下：
建立架構定義（schema）：架構提供預先定義的資料結構。人們可以對此進行定制，以符合其特定的示例。基於架構建立模組（modules）：註冊為模組的智慧合約取得字節碼並選擇架構ID，資料就會儲存在儲存中。取得模組的證明（證明）：證明者/審核員可以基於架構為模組提供證明。這些證明可包括唯一識別碼（UID）以及用於連結的其他證明的引用。它們可以跨鏈傳播和驗證目標鏈是否滿足特定閾值。使用解析器（resolver）實現複雜邏輯：解析器（選擇性設定）開始發揮作用。它們可以在模組創建、證明建立和撤銷期間被呼叫。這些解析器允許開發人員整合複雜且多樣化的邏輯，同時維護證明結構。使用者介面的查詢存取（query）：查詢為使用者提供了一種從介面存取安全資訊的方法。
雖然該模式還處於早期階段，但它具有以去中心化和協作的方式建立標準的潛力。蘿蔔使開發人員能夠註冊他們的模組，審計員能夠驗證其安全性，錢包能夠進行集成，清理用戶能夠輕鬆找到模組並驗證其證明資訊。未來的幾個用途可能是：
證明者（attestor）：像Safe這樣值得信賴的實體可以與Rhinestone合作，共同作為內部模組的證明者。同時，獨立證明者也可以加入。模組人員（模組開發人員）：隨著開發開放市場的形成，模組開發人員有可能透過配額將他們的工作貨幣化。使用者：透過使用者介面的介面（如錢包或dApp）進行參與，使用者可以檢查模組資訊將信任委託給不同的證明者。
「模組」的概念為插件和模組開發人員開闢了獲利途徑。它可以進一步為“模組市場”鋪平道路。某些方面可能會受到安全團隊監督，而其他方面可能會拓展中心化市場，邀請所有者做出貢獻並提供透明的審計記錄。整合這一點可以避免供應商鎖定，並透過添加能夠吸引更廣泛的受眾，增強用戶體驗來支持EVM 的擴展。
雖然這些方法能夠確保單一模組的安全，但在更廣泛的安全性方面，智慧契約帳戶並不是萬無一失的。它們與合規模塊結合並證明沒有儲存衝突可能是一個挑戰，這凸顯了錢包或AA基礎設施在解決此類問題方面的重要性。
總結
透過利用大規模智慧合約帳戶堆疊，錢包和dApp 可以從技術的複雜性中解放出來。同時，外部模組開發人員有機會提供個人化的專業服務。然而，需要解決的挑戰包括靈活和安全性之間取得平衡，推動標準化，以及實施標準化接口，使用戶能夠輕鬆升級和修改其智慧帳戶。
另外，分層智能合約帳戶（SCA）只是採用問題的一部分。為了充分發揮SCA的潛力，需要第2層解決方案提供額外的協議層支持，例如擴展的捆綁器基礎和點對點內存礦池設施、更多成本實現和對接以及SCA簽名機制、跨鏈SCA同步和管理機制，開發用戶友善的介面。
未來，將會有更多的人採用SCA，但也會引發一些有趣的問題：一旦SCA訂單流整合有足夠的利益可圖，傳統的礦工可提取價值（MEV）機制將如何進入該領域構建捆綁器並獲取價值？當基礎設施成熟後，帳戶抽象化（AA）如何作為「基於理智」交易的基礎層？讓我們拭目以待。
資訊來源：0x資訊編譯自網際網路。版權歸作者SevenX Ventures投資者和研究員@Rui所有，未經許可，不得轉載