V神：深入了解錢包和其他用例的跨 L2 讀取

作者：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） + （b-a） * 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 上使用密鑰庫。
保護隱私將需要額外的工作，並使某些選擇更加困難。但是，無論如何，我們可能應該轉向隱私保護解決方案，至少確保我們提出的任何內容都與保護隱私兼容。