作者：Vitalik Buterin 編譯：白話區塊鏈
在之前那篇關於三個轉變的文章中，我概述了一些關鍵原因，為什麼開始明確考慮L1 + 跨L2 支持、錢包安全和隱私作為生態系統堆棧的必要基本功能是有價值的，而不是將這些東西構建為可以由單個錢包單獨設計的插件。
這篇文章將更直接地關註一個特定子問題的技術方面，比如：如何更容易地從L2讀取L1，從L1讀取L2，或者從另一個L2讀取L2。解決這個問題對於實現資產/密鑰庫分離架構至關重要，但它在其他領域也有有價值的用例，最顯著的是優化可靠的跨L2 調用鏈，包括在L1 和L2 之間移動資產等用例。
本文目錄
目標是什麼？
跨鏈證明是什麼樣的？
我們可以使用什麼樣的證明方案？
Merkle證明
ZK SNARKs
專用KZG證明
Verkle樹證明
聚合
直接狀態讀取
L2如何學習最近的以太坊狀態根？
非L2s鏈上的錢包
保護隱私
總結
1.目標是什麼？
一旦L2 成為主流，用戶將擁有跨多個L2 的資產，可能還有L1。一旦智能合約錢包（多重簽名，社交恢復或其他）成為主流，訪問某些帳戶所需的密鑰將隨著時間的推移而改變，舊密鑰將不再需要有效。一旦這兩件事都發生，用戶將需要一種方法來更改有權訪問位於許多不同地方的許多帳戶的密鑰，而無需進行極大量的交易。
特別是，我們需要一種方法來處理反事實地址：尚未以任何方式在鏈上“註冊”的地址，但仍需要接收並安全地持有資金。我們都依賴於反事實地址：當您第一次使用以太坊時，您可以生成一個ETH地址，有人可以使用該地址向您付款，而無需在鏈上“註冊”該地址（這需要支付txfee，因此已經持有一些ETH）。
對於EOA，所有地址都以反事實地址開頭。使用智能合約錢包，反事實地址仍然是可能的，這在很大程度上要歸功於CREATE2，它允許您擁有一個只能由具有與特定哈希匹配的代碼的智能合約填充的ETH 地址。
EIP-1014 （CREATE2） 地址計算算法
然而，智能合約錢包帶來了新的挑戰：訪問密鑰更改的可能性。該地址是initcode 的哈希值，只能包含錢包的初始驗證密鑰。當前的驗證密鑰將存儲在錢包的存儲中，但該存儲記錄不會神奇地傳播到其他L2。
如果用戶在許多L2 上有許多地址，包括他們所在的L2 不知道的地址（因為它們是反事實的），那麼似乎只有一種方法允許用戶更改他們的密鑰：資產/密鑰庫分離架構。每個用戶都有（i）一個“密鑰庫合約”（在L1或一個特定的L2上），它存儲所有錢包的驗證密鑰以及更改密鑰的規則，以及（ii）L1和許多L2上的“錢包合約”，它們讀取跨鏈以獲取驗證密鑰。
有兩種方法可以實現這一點：
輕量版（只檢查更新密鑰）：每個錢包在本地存儲驗證密鑰，並包含一個函數，可以調用該函數來檢查密鑰庫當前狀態的跨鏈證明，並更新其本地存儲的驗證密鑰以匹配。當錢包首次在特定L2 上使用時，必須調用該函數以從密鑰庫獲取當前驗證密鑰。
-優點：謹慎使用跨鏈證明，所以如果跨鏈證明很昂貴也沒關係。所有資金只能使用當前密鑰使用，因此它仍然是安全的。
-缺點：要更改驗證密鑰，您必須在密鑰庫和每個已初始化的錢包中（儘管不是反事實的錢包）中進行鏈上密鑰更改。這可能會花費很多汽油。
重量版（檢查每個tx）：每筆交易都需要一個跨鏈證明，顯示密鑰庫中當前密鑰。
-優點：系統複雜性較低，密鑰庫更新價格便宜。
-缺點：單個tx 價格昂貴，因此需要更多的工程才能使跨鏈證明便宜得多。也不容易與ERC-4337兼容，ERC-4337目前不支持在驗證期間跨合約讀取可變對象。
2.跨鏈證明是什麼樣的？
為了展示全部複雜性，我們將探討最困難的情況：密鑰庫在一個L2上，錢包在不同的L2上。如果錢包上的密鑰庫位於L1上，則只需要此設計的一半。
假設密鑰庫在Linea 上，錢包在Kakarot 上。錢包密鑰的完整證明包括：
-證明當前Linea 狀態根的證明，給定Kakarot 知道的當前以太坊狀態根
-證明密鑰庫中當前密鑰的證明，給定當前Linea 狀態根
這裡有兩個主要的棘手的實現問題：
-我們使用什麼樣的證據？ （是默克爾證明嗎？別的什麼？
-L2首先如何學習最近的L1（以太坊）狀態根（或者，正如我們將看到的，可能是完整的L1狀態）？或者，L1如何學習L2狀態根？
在這兩種情況下，一側發生的事情與另一側可證明的事情之間的延遲有多長？
3.我們可以使用哪些類型的證明方案？
有五個主要選項：
-Merkle 證明
-通用ZK-SNARKs
-專用證明（例如使用KZG）
-Verkle 證明，它們在基礎設施工作負載和成本上介於KZG 和ZK-SNARKs 之間。
-無需證明，依賴直接狀態讀取
就所需的基礎設施工作和用戶成本而言，我將它們大致排名如下：
“聚合”是指將用戶在每個區塊內提供的所有證明聚合到一個大的元證明中，該元證明將所有證明組合在一起。這對於SNARK 和KZG 是可能的，但對於Merkle 分支則不然（你可以稍微組合一下Merkle 分支，但它只節省你的log（每個塊的txs）/log（密鑰庫的總數），在實踐中可能是15-30%，所以它可能不值得付出代價）。
只有當方案擁有大量用戶時，聚合才變得值得，因此實際上，版本1 實現可以省略聚合，並在版本2 中實現聚合。
4.默克爾證明將如何工作？
這個很簡單：直接按照上一節中的圖表進行操作。更準確地說，每個“證明”（假設證明一個L2到另一個L2的最大難度情況）將包含：
一個Merkle分支，證明持有密鑰庫的L2的狀態根，給定L2知道的以太坊的最新狀態根。密鑰庫持有L2 的狀態根存儲在已知地址的已知存儲槽（L1 上的協定代表L2）中，因此可以通過樹的路徑進行硬編碼。
一個Merkle 分支，用於證明當前驗證密鑰，給定持有密鑰庫的L2 的狀態根。在這裡，驗證密鑰再次存儲在已知地址的已知存儲插槽中，因此可以對路徑進行硬編碼。
不幸的是，以太坊狀態證明很複雜，但存在用於驗證它們的庫，如果您使用這些庫，這種機制實現起來並不太複雜。
更大的問題是成本。 Merkle 證明很長，不幸的是，Patricia 樹比必要的長~3.9 倍（確切地說：持有N 個對象的樹的理想Merkle 證明是32 * log2（N） 字節長，並且因為以太坊的Patricia 樹每個孩子有16 片葉子，這些樹的證明是32 * 15 * log16（N） ~= 125 * log2（N） 字節長）。在一個擁有大約2.5 億（~2²⁸） 帳戶的州，這使得每個證明125 * 28 = 3500 字節，或大約56，000 gas，加上解碼和驗證哈希的額外成本。
兩個證明加在一起最終將花費大約10萬到15萬gas（如果每筆交易使用，則不包括簽名驗證）——遠遠高於目前每筆交易2.1萬個gas 的基本價格。但是，如果在L2上驗證證明，則差異會變得更糟。 L2 內部的計算很便宜，因為計算是在鏈下完成的，並且在節點比L1 少得多的生態系統中完成。另一方面，數據必鬚髮佈到L1。因此，比較不是2.1 萬氣體與1.5 萬氣體;它是2.1 萬L2 gas與10 萬L1 gas。
我們可以通過查看L1 gas 成本和L2 gas 成本之間的比較來計算這意味著什麼：
目前，對於簡單發送，L1 比L2 貴15-25 倍，對於代幣交換來說，L1 貴20-50 倍。簡單發送相對數據量大，但交換的計算量要大得多。因此，掉期是L1計算與L2計算近似成本的更好基準。考慮到所有這些因素，如果我們假設L1 計算成本和L2 計算成本之間存在30 倍的成本比率，這似乎意味著在L2 上放置默克爾證明的成本可能相當於50 個常規事務。
當然，使用二元Merkle樹可以將成本降低~4倍，但即便如此，在大多數情況下，成本還是太高了- 如果我們願意犧牲不再與以太坊當前的六邊形狀態樹兼容，我們不妨尋求更好的選擇。
5.ZK-SNARK證明將如何工作？
從概念上講，ZK-SNARKs 的使用也很容易理解：您只需將上圖中的Merkle 證明替換為證明這些Merkle 證明存在的ZK-SNARK。一個ZK-SNARK 需要~400，000 個GAS 的計算，大約需要400 個字節（相比之下：一個基本事務需要2.1 萬個gas 和100 個字節，將來壓縮後可減少到~25 個字節）。因此，從計算的角度來看，ZK-SNARK的成本是今天基本交易成本的19倍，從數據的角度來看，ZK-SNARK的成本是今天基本交易的4倍，是未來基本交易成本的16倍。
這些數字比默克爾證明有了很大的改進，但它們仍然相當昂貴。有兩種方法可以改進這一點： （i）特殊用途的KZG證明，或（ii）聚合，類似於ERC-4337聚合，但使用更花哨的數學。我們可以同時研究兩者。
6.特殊用途的KZG證明將如何工作？
警告，此部分比其他部分更具數學性。這是因為我們正在超越通用工具，並構建一些更便宜的特殊用途，因此我們必須更多地“在引擎蓋下”。如果您不喜歡深奧的數學，請直接跳到下一部分。
首先，回顧一下KZG承諾是如何運作的：
我們可以表示一組數據 [D_1 …D_n] 使用從數據導出的多項式的KZG 證明：具體來說，多項式P，其中P（w） = D_1，P（w²） = D_2 …P（wⁿ） = D_n. w 這裡是“統一根”，對於某些評估域大小N，wN = 1 的值（這一切都是在有限域中完成的）。
為了“提交”到P，我們創建一個橢圓曲線點com（P） = P₀ * G + P₁ * S₁ + … + Pk * Sk。這裡：
-G 是曲線的生成器點
-Pi 是多項式P 的第i 次係數
-Si 是可信設置中的第i 個點
為了證明P（z） = a，我們創建一個商多項式Q = （P – a） / （X – z），並創建一個承諾com（Q）。只有當P（z） 實際上等於a 時，才有可能創建這樣的多項式。
為了驗證證明，我們通過對證明com（Q） 和多項式承諾com（P） 進行橢圓曲線檢查來檢查方程Q * （X – z） = P – a：我們檢查e（com（Q）， com（X – z）） ？ = e（com（P） – com（a）， com（1））
需要了解的一些關鍵屬性包括：
-證明只是com（Q） 值，即48 個字節
-com（P₁） + com（P₂） = com（P₁ + P₂）
這也意味著您可以將值“編輯”為現有合約。假設我們知道D_i當前是a，我們希望將其設置為b，並且對D 的現有承諾是com（P）。承諾“P，但P（wⁱ） = b，並且沒有其他評估更改”，然後我們設置com（new_P） = com（P） + （ba） * com（Li），其中Li 是“拉格朗日多項式”，在wⁱ 處等於1，在其他wj 點處等於0。
為了有效地執行這些更新，每個客戶端都可以預先計算和存儲對拉格朗日多項式（com（Li）） 的所有N 個承諾。在鏈上合約中，存儲所有N 個承諾可能太多了，所以你可以對com（L_i）（或哈希（com（L_i））值集做出KZG 承諾，所以每當有人需要更新鏈上的樹時，他們可以簡單地向適當的com（L_i） 提供其正確性的證明。
因此，我們有一個結構，我們可以繼續將值添加到不斷增長的列表的末尾，儘管有一定的大小限制（實際上，數億可能是可行的）。然後，我們使用它作為我們的數據結構來管理（i）對每個L2上的密鑰列表的承諾，存儲在該L2上並鏡像到L1，以及（ii）對L2密鑰承諾列表的承諾，存儲在以太坊L1上並鏡像到每個L2。
保持承諾更新可以成為核心L2邏輯的一部分，也可以通過存款和撤回橋接實現，而無需更改L2核心協議。
因此，完整的證明需要：
-密鑰庫持有L2（48字節）上的最新com（key list）
-KZG證明com（key list）是com（mirror_list中的值），對所有鍵列表提交列表的承諾（48字節）
-KZG證明您的key在com（key list）（48字節，加上索引的4個字節）
實際上可以將兩個KZG 證明合併為一個，因此我們得到的總大小只有100 字節。
注意一個微妙之處：因為鍵列表是一個列表，而不是像狀態那樣的鍵/值映射，所以鍵列表必須按順序分配位置。密鑰承諾合約將包含其自己的內部註冊表，將每個密鑰庫映射到一個ID，並且對於每個密鑰，它將存儲哈希（密鑰庫的地址）而不僅僅是密鑰，以便明確地與其他L2 通信特定條目正在談論的密鑰庫。
這種技術的優點是它在L2 上表現非常好。數據是100 字節，比ZK-SNARK 短~4 倍，比默克爾證明短。計算成本主要是一號2配對檢查，或約11.9 萬個gas。在L1上，數據不如計算重要，因此不幸的是KZG比Merkle證明貴一些。
7.Verkle樹將如何工作？
Verkle 樹本質上涉及將KZG 承諾（或IPA 承諾，可以更高效且使用更簡單的加密）堆疊在一起：要存儲2⁴⁸ 值，您可以對2²⁴ 值列表做出KZG 承諾，每個值本身都是KZG 對2²⁴ 值的承諾。 Verkle樹被強烈考慮用於以太坊狀態樹，因為Verkle樹可以用來保存鍵值映射，而不僅僅是列表（基本上，你可以創建一個大小為2²⁵⁶的樹，但開始為空，只有在你實際需要填充它們時才填充樹的特定部分）。
維克爾樹是什麼樣子的。實際上，對於基於IPA 的樹，您可以為每個節點指定256 == 2⁸ 的寬度，對於基於KZG 的樹，您可以為每個節點指定2²⁴ 的寬度。
Verkle樹中的證明比KZG長一些;它們可能有幾百個字節長。它們也很難驗證，特別是如果您嘗試將許多證明聚合為一個。
實際上，Verkle樹應該被認為是像Merkle樹，但如果沒有SNARKing更可行（因為數據成本較低），而SNARKing更便宜（因為較低的證明成本）。
Verkle 樹的最大優點是可以協調數據結構：Verkle 證明可以直接用於L1 或L2 狀態，沒有疊加結構，並且對L1 和L2 使用完全相同的機制。一旦量子計算機成為一個問題，或者一旦證明Merkle分支變得足夠高效，Verkle樹就可以就地替換為具有合適的SNARK友好哈希函數的二元哈希樹。
8.集合體
如果N 個用戶進行N 筆交易（或者更現實地說，N 個ERC-4337 UserOperations）需要證明N 個跨鏈聲明，我們可以通過聚合這些證明來節省大量資金：將這些交易組合成一個區塊或進入區塊的捆綁包的構建者可以創建一個證明，同時證明所有這些主張。
這可能意味著：
-N Merkle 分支的ZK-SNARK 證明
-一個KZG 多重證明
-一個Verkle 多重證明（或多證明的ZK-SNARK）
在所有三種情況下，每個證明只需要幾十萬汽油。構建器需要在每個L2 上為該L2 中的用戶製作其中一個;因此，為了便於構建，整個方案需要有足夠的使用率，以至於在多個主要L2 的同一區塊中通常至少有幾筆交易。
如果使用ZK-SNARKs，主要的邊際成本只是在合同之間傳遞數字的“業務邏輯”，因此每個用戶可能需要幾千個L2氣體。如果使用KZG 多重證明，則證明者需要為該塊內使用的每個密鑰庫持有L2 添加48 個gas，因此每個用戶的方案邊際成本將為每個L2（而不是每個用戶）再增加~800 個L1 gas。但這些成本遠低於不聚合的成本，不聚合的成本不可避免地涉及每個用戶超過10，000個L1氣體和數十萬個L2氣體。對於Verkle 樹，您可以直接使用Verkle 多重證明，為每個用戶添加大約100-200 字節，或者您可以製作Verkle 多重證明的ZK-SNARK，其成本與Merkle 分支的ZK-SNARKs 相似，但證明成本要低得多。
從實現的角度來看，最好讓捆綁者通過ERC-4337賬戶抽象標準聚合跨鏈證明。 ERC-4337已經有一種機制，供構建器以自定義方式聚合用戶操作的各個部分。甚至還有用於BLS 簽名聚合的實現，它可以將L2 上的gas 成本降低1.5 到3 倍，具體取決於包含的其他壓縮形式。
來自BLS 錢包實現帖子的圖表，顯示了早期版本的ERC-4337 中BLS 聚合簽名的工作流程。聚合跨鏈證明的工作流程可能看起來非常相似。
9.直接狀態讀取
最後一種可能性，也只可用於L2 讀取L1（而不是L1 讀取L2），是修改L2，讓它們直接對L1 上的合約進行靜態調用。
這可以通過操作碼或預編譯來完成，它允許調用L1，在那裡你提供目標地址、gas 和calldata，它返回輸出，但由於這些調用是靜態調用，它們實際上無法更改任何L1 狀態。 L2 必須知道L1 已經處理存款，因此沒有什麼根本可以阻止這樣的事情的實施;這主要是一個技術實現挑戰（參見：這個來自樂觀的RFP，以支持對L1的靜態調用）。
請注意，如果密鑰庫位於L1 上，並且L2 集成了L1 靜態調用功能，則根本不需要證明！但是，如果L2 沒有集成L1 靜態調用，或者密鑰庫位於L2 上（一旦L1 變得太貴以至於用戶無法使用哪怕一點點，最終可能必須如此），那麼將需要證明。
10.L2 如何學習最近的以太坊狀態根？
上述所有方案都要求L2 訪問最近的L1 狀態根或整個最近的L1 狀態。幸運的是，所有L2 都已經具有訪問最新L1 狀態的一些功能。這是因為他們需要這樣的功能來處理從L1 到L2 的消息，尤其是存款。
事實上，如果L2 具有存款功能，那麼您可以按原樣使用該L2 將L1 狀態根移動到L2 上的合約中：只需讓L1 上的合約調用BLOCKHASH 操作碼，並將其作為存款消息傳遞給L2。可以在L2 端接收完整的塊標頭，並提取其狀態根。但是，每個L2 最好都有明確的方式來直接訪問完整的最新L1 狀態或最近的L1 狀態根。
優化L2 接收最新L1 狀態根的方式的主要挑戰是同時實現安全性和低延遲：
-如果L2 以懶惰的方式實現“直接讀取L1”功能，只讀取最終的L1 狀態根，那麼延遲通常為15 分鐘，但在不活動洩漏的極端情況下（您必須容忍），延遲可能是幾週。
-L2 絕對可以設計為讀取更新的L1 狀態根，但由於L1 可以恢復（即使具有單插槽終結性，在非活動洩漏期間也會發生恢復），L2 也需要能夠恢復。從軟件工程的角度來看，這在技術上具有挑戰性，但至少樂觀已經具備了這種能力。
-如果您使用存款橋將L1 狀態根引入L2，那麼簡單的經濟可行性可能需要在存款更新之間花費很長時間：如果存款的全部成本為10 萬gas，我們假設ETH 為1800 美元，費用為200 gwei，並且L1 根每天進入L2 一次， 這將花費每天每個L236美元，或每年每個L2維護系統的成本為13148美元。延遲一小時，每年每個L2的費用高達315569美元。在最好的情況下，不斷有不耐煩的富裕用戶支付更新費用，並使系統為其他人保持最新狀態。在最壞的情況下，一些利他主義的演員將不得不自己為此付出代價。
-“預言機”（至少是一些DeFi 人稱之為“預言機”的技術）在這裡不是一個可接受的解決方案：錢包密鑰管理是一個非常安全的關鍵低級功能，因此它最多應該依賴於幾個非常簡單的、無需加密信任的低級基礎設施。
此外，在相反的方向上（L1s 讀數為L2）：
-在樂觀匯總中，由於欺詐證明延遲，州根需要一周才能達到L1。在ZK匯總中，由於驗證時間和經濟限制的結合，現在需要幾個小時，儘管未來的技術將減少這種情況。
-預確認（來自測序儀、證明者等）不是L1 讀數L2 的可接受解決方案。錢包管理是一個非常安全關鍵的低級功能，因此L2 – L1通信的安全級別必須是絕對的：甚至不可能通過接管L2驗證器集來推送錯誤的L1狀態根。 L1 應信任的唯一狀態根是已被L2 在L1 上的狀態根持有合約接受為最終狀態根。
對於許多DeFi 用例來說，其中一些用於無信任跨鏈操作的速度慢得令人無法接受;對於這些情況，您確實需要具有更不完善的安全模型的更快網橋。然而，對於更新錢包密鑰的用例，更長的延遲更容易接受：您不會延遲數小時交易，而是延遲密鑰更改。您只需要將舊密鑰保留更長時間即可。如果您因為密鑰被盜而更改密鑰，那麼您確實有很長一段時間的漏洞，但可以緩解，例如。通過具有凍結功能的錢包。
最終，最好的延遲最小化解決方案是讓L2 以最佳方式實現對L1 狀態根的直接讀取，其中每個L2 塊（或狀態根計算日誌）包含一個指向最新L1 塊的指針，因此如果L1 恢復，L2 也可以恢復。密鑰庫合約應放置在主網上或ZK 匯總的L2 上，以便可以快速提交到L1。
L2 鏈的塊不僅可以依賴於以前的L2 塊，還可以依賴於L1 塊。如果L1 通過此類鏈路恢復，則L2 也會恢復。值得注意的是，這也是早期（Dank之前）版本的分片被設想的工作方式;有關代碼，請參見此處。
11.另一條鏈需要多少與以太坊的連接才能持有密鑰庫植根於以太坊或L2 的錢包？
令人驚訝的是，沒有那麼多。它實際上甚至不需要是匯總：如果它是L3 或驗證，那麼在那裡保存錢包是可以的，只要您在L1 或ZK 匯總上持有密鑰庫。你確實需要的是鏈可以直接訪問以太坊狀態根，以及一個技術和社會承諾，如果以太坊重組，願意重組，如果以太坊硬分叉，則硬分叉。
一個有趣的研究問題是確定一條鏈在多大程度上可以與多個其他鏈建立這種形式的連接（例如。以太坊和Zcash）。天真地這樣做是可能的：如果以太坊或Zcash 重組，你的鏈可以同意重組（如果以太坊或Zcash 硬分叉，則硬分叉），但你的節點運營商和你的社區通常有兩倍的技術和政治依賴性。因此，這種技術可用於連接到其他一些鏈，但成本增加。基於ZK 橋的方案具有吸引人的技術特性，但它們的關鍵弱點是它們對51% 攻擊或硬分叉不具有魯棒性。可能還有更聰明的解決方案。
12.隱私保護
理想情況下，我們也希望保護隱私。如果您有許多錢包由同一密鑰庫管理，那麼我們希望確保：
-目前尚不清楚這些錢包都是相互連接的。
-社交康復監護人不知道他們正在保護的地址是什麼。
這會產生一些問題：
-我們不能直接使用默克爾證明，因為它們不保護隱私。
-如果我們使用KZG 或SNARK，那麼證明需要提供驗證密鑰的盲版本，而不透露驗證密鑰的位置。
-如果我們使用聚合，那麼聚合器不應該學習明文中的位置;相反，聚合器應該接收盲證明，並有辦法聚合這些證明。
-我們不能使用“輕量級版本”（僅使用跨鏈證明來更新密鑰），因為它會造成隱私洩漏：如果許多錢包由於更新過程而同時更新，則時間會洩漏這些錢包可能相關的信息。
因此，我們必須使用“重型版本”（每筆交易的跨鏈證明）。
使用SNARK，解決方案在概念上很簡單：默認情況下，證明是信息隱藏的，聚合器需要生成遞歸SNARK 來證明SNARK。
目前這種方法的主要挑戰是聚合需要聚合器創建一個遞歸SNARK，這目前非常慢。
有了KZG，我們可以在非索引揭示KZG證明上使用這項工作（另見：Caulk論文中這項工作的更正式版本）作為起點。然而，盲證明的聚合是一個需要更多關注的開放問題。
不幸的是，從L2 內部直接讀取L1 並不能保護隱私，儘管實現直接讀取功能仍然非常有用，既可以最大限度地減少延遲，又因為它對其他應用程序的實用性。
13.總結
要擁有跨鏈社交恢復錢包，最現實的工作流程是在一個位置維護密鑰庫的錢包，以及在許多位置維護錢包的錢包，其中錢包讀取密鑰庫（i）更新其驗證密鑰的本地視圖，或（ii）在驗證每筆交易的過程中。
使之成為可能的一個關鍵因素是跨鏈證明。我們需要努力優化這些證明。等待Verkle證明的ZK-SNARKs或定制的KZG解決方案似乎是最佳選擇。
從長遠來看，聚合協議（其中捆綁器生成聚合證明，作為創建用戶提交的所有用戶操作的捆綁包的一部分）對於最小化成本是必要的。這可能應該集成到ERC-4337生態系統中，儘管可能需要對ERC-4337進行更改。
應優化L2，以最大程度地減少從L2 內部讀取L1 狀態（或至少是狀態根）的延遲。 L2s直接讀取L1狀態是理想的，可以節省證明空間。
錢包不僅可以在L2 上;您還可以將錢包放在與以太坊連接級別較低的系統上（L3，甚至是僅在以太坊重組或硬分叉時同意包含以太坊狀態根和重組或硬分叉的獨立鏈）。
但是，密鑰庫應位於L1 或高安全性ZK 匯總L2 上。使用L1 可以節省很多複雜性，但從長遠來看，即使這樣也可能太昂貴，因此需要在L2 上使用密鑰庫。
保護隱私將需要額外的工作，並使某些選擇更加困難。但是，無論如何，我們可能應該轉向隱私保護解決方案，至少確保我們提出的任何內容都與保護隱私兼容。