dark

Vitalik：深入了解跨L2讀取——跨鏈證明有哪些方案

2023-06-21

作者：Vitalik，以太坊創始人；翻譯：金色財經cryptonaitive

在《以太坊生態系統需要三個技術轉型》一文中，我概述了為什麼明確考慮L1 +跨L2支持、錢包安全性和隱私作為以太坊生態系統堆棧的必要基本功能，而不是作為可以由單獨的錢包單獨設計的附加組件的關鍵原因。

本文將更直接地關註一個特定子問題的技術方面：如何使從L2讀取L1、從L1讀取L2或從一個L2讀取另一個L2變得更容易。解決這個問題對於實施資產/密鑰庫（keystore）分離架構至關重要，但它在其他領域也有著有價值的用途，尤其是優化可靠的L2間調用，包括在L1和L2之間轉移資產等用例。

本文目錄：

  • 目標是什麼？

  • 跨鏈證明是什麼樣的？

  • 我們可以使用哪些證明方案？

    • Merkle證明

    • ZK SNARKs

    • 特殊目的的KZG證明

    • Verkle樹證明

    • 聚合

    • 直接狀態讀取

  • L2如何獲取最新的以太坊狀態根？

  • 不是L2鏈的錢包

  • 隱私保護

  • 總結

目標是什麼？

一旦L2變得更加主流，用戶將在多個L2和可能的L1上擁有資產。一旦智能合約錢包（多簽、社交恢復或其他類型）成為主流，訪問某個賬戶所需的密鑰將會隨著時間而改變，舊的密鑰將不再有效。一旦這兩個情況都發生，用戶將需要一種方法來更改具有權限訪問位於許多不同位置的許多賬戶的密鑰，而不需要進行大量的交易。

特別是，我們需要一種處理“虛擬地址（counterfactual addresses）”的方法：這些地址尚未以任何方式在鏈上“註冊”，但仍需要接收和安全保管資金。我們都依賴於虛擬地址：當你第一次使用以太坊時，你可以生成一個ETH地址，他人可以用來向你支付資金，而無需在鏈上“註冊”該地址（這將需要支付交易費用，因此需要持有一些ETH）。

對於EOAs（外部賬戶），所有地址最初都是虛擬地址。對於智能合約錢包而言，虛擬地址仍然是可能的，主要得益於CREATE2，它允許你擁有一個ETH地址，只有與特定哈希匹配的代碼的智能合約才能填充該地址。

EIP-1014 (CREATE2) 地址計算算法

然而，智能合約錢包引入了一個新的挑戰：訪問密鑰可能會發生變化。地址（作為initcode的哈希）只能包含錢包的初始驗證密鑰。當前的驗證密鑰將存儲在錢包的存儲中，但該存儲記錄不會自動傳播到其他L2。

如果用戶在許多L2上有許多地址，包括（因為它們是虛設的）所在的L2不知道的地址，那麼似乎只有一種方式可以讓用戶更改他們的密鑰：資產/密鑰庫分離架構。每個用戶都有（i）一個“密鑰庫合約”（在L1或特定L2上），用於存儲所有錢包的驗證密鑰以及更改密鑰的規則，和（ii）L1和許多L2上的“錢包合約”，用於進行跨鏈讀取以獲取驗證密鑰。

ScKjjpjR83ThNPkG5Rsr6y2w1W2XE6DU5dYfKVfn.png

有兩種實現方法：

1、輕量級版本（僅檢查以更新密鑰）：每個錢包在本地存儲驗證密鑰，並包含一個函數，可以調用該函數以檢查來自密鑰庫的當前狀態的跨鏈證明，並更新本地存儲的驗證密鑰。當在特定L2上首次使用錢包時，調用該函數以從密鑰庫獲取當前驗證密鑰是必需的。

  • 優點：節約使用跨鏈證明，因此跨鏈證明昂貴也沒有關係。所有資金只能使用當前密鑰，因此仍然安全。

  • 缺點：要更改驗證密鑰，你必須在密鑰庫和已初始化的每個錢包（儘管不包括虛擬地址）中進行鏈上密鑰更改。這可能需要大量的Gas費用。

2、重量級版本（每筆交易都進行檢查）：每個交易都需要一個跨鏈證明，證明密鑰當前存在於密鑰庫中。

  • 優點：系統複雜性較低，更新密鑰庫成本較低。

  • 缺點：每筆交易都很昂貴，因此需要更多的工程來使跨鏈證明的成本可接受。同時，它與ERC-4337不易兼容，因為ERC-4337目前不支持在驗證期間對可變對象進行跨合約讀取。

跨鏈證明是什麼樣的？

為了展示全部的複雜性，我們將探討最困難的情況：密鑰庫位於一個L2，錢包位於另一個L2。如果密鑰庫或錢包中的任何一個位於L1，則只需要這個設計的一半。

JQhHwLkUaRdO6GqoEdEiXMQU8TjVXjcmu5YtLPRv.png假設密鑰庫位於Linea，錢包位於Kakarot。完整的錢包密鑰證明包括：

  • 一個證明，根據Kakarot所知的當前以太坊狀態根，證明當前Linea狀態根

  • 一個證明，根據當前Linea狀態根，證明密鑰庫中的當前密鑰

這裡有兩個主要的實現問題：

1、我們使用什麼樣的證明？ （是Merkle證明嗎？還是其他什麼東西？）

2、L2如何首先了解最近的L1（以太坊）狀態根（或者，如我們將看到的，可能是完整的L1狀態）？相反，L1如何了解L2狀態根？

  • 在兩種情況下，一些事情發生在一側，直到在另一側可以證明這件事，之間會有多長時間的延遲？

我們可以使用哪些證明方案？

有五種主要選擇：

  • Merkle證明

  • 通用ZK-SNARKs

  • 特殊目的證明（例如，使用KZG）

  • Verkle證明，介於KZG和ZK-SNARKs之間，既涉及基礎設施工作量，又涉及成本。

  • 不使用證明，依賴於直接狀態讀取

就所需的基礎設施工作和用戶成本而言，我大致按以下順序對它們進行排列：

AhrxqCX1MAlnzAwzfWzbA495wGfwI94IT5Gruu5E.png

“聚合”是指在每個區塊內將用戶提供的所有證明聚合成一個大的元證明，將所有證明組合在一起。這對於SNARKs和KZG是可能的，但對於Merkle branches不可能（你可以在一定程度上組合Merkle branches，但實際上只能節省log（每個區塊的交易數）/ log（密鑰庫的總數）的工作量，可能實際上只有15-30%，所以成本可能不值得）。

只有在方案有大量用戶時，聚合才變得有價值，因此在版本1的實施中，略過聚合，然後在版本2中實施聚合是可以的。

Merkle證明將如何工作？

這個比較簡單：直接按照前一節的圖表進行操作。更準確地說，每個“證明”（假設在一個L2中證明一個L2的最困難的情況）將包含：

  • 一個Merkle branch，根據L2所知的最新以太坊狀態根，證明持有密鑰庫的L2的狀態根。持有密鑰庫的L2的狀態根存儲在已知地址的已知存儲slot中（在L1上表示L2的合約），因此路徑可以硬編碼。

  • 一個Merkle branch，根據持有密鑰庫的L2的狀態根，證明當前驗證密鑰。在這裡，驗證密鑰再次存儲在已知地址的已知存儲slot中，因此路徑可以硬編碼。

不幸的是，以太坊狀態證明很複雜，但存在用於驗證它們的庫，如果使用這些庫，這種機制實現不太複雜。

更大的問題是成本。 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，加上解碼和驗證哈希的額外成本。

兩個證明加在一起將花費大約100,000到150,000 gas（不包括如果每筆交易使用簽名驗證），比當前每筆交易的基本21,000 gas多得多。但是，如果在L2上驗證證明，差距會更大。 L2內的計算是廉價的，因為計算在鏈外完成，並且在節點數量比L1少得多的生態系統中進行。另一方面，數據必須被發佈到L1。因此，不是比較21,000 gas與150,000 gas；而是21,000個L2 gas與100,000個L1 gas的比較。

我們可以通過查看L1 gas成本和L2 gas成本之間的比較來計算這意味著什麼：

4utlKEDJDYLLo1P2aTjCTS3U1RSSw11lpcLNvpI4.pngL1當前簡單的發送操作比L2貴15-25倍，代幣交換L1比L2貴20-50倍。簡單的發送操作相對於數據而言比較重，但交換操作在計算方面更重。因此，交換操作是用來近似計算L1計算成本與L2計算成本的更好基準。綜合考慮所有這些因素，如果我們假設L1計算成本與L2計算成本之間的成本比為30倍，這似乎意味著在L2上放置一個Merkle證明將相當於大約50筆常規交易。

當然，使用二進制Merkle樹可以將成本減少約4倍，但即使如此，成本在大多數情況下仍然會太高- 如果我們願意不再與以太坊當前的十進制狀態樹兼容，我們可能還可以尋找更好的選擇。

ZK-SNARK證明將如何工作？

在概念上，ZK-SNARK證明挺容易理解，只要將上圖中Merkle證明替換為證明這些Merkle證明存在的ZK-SNARK。一個ZK-SNARK證明的計算成本約為400,000 gas，並佔用約400字節的數據（與基本交易相比，基本交易的計算成本為21,000 gas，數據大小為100字節，在未來可以通過壓縮減少到約25字節）。因此，從計算角度來看，ZK-SNARK的成本是當前基本交易成本的19倍，從數據角度來看，ZK-SNARK的成本是基本交易成本的4倍，也是未來基本交易成本的16倍。

儘管這些數字相比Merkle證明有了顯著改進，但它們仍然相當昂貴。要改進這一點有兩種方法：（一）特殊用途的KZG證明，或者（二）聚合，類似於ERC-4337聚合，但使用更複雜的數學。我們可以研究這兩種方法。

特殊用途的KZG證明如何工作？

首先，回顧一下KZG承諾是如何工作的：

  • 我們可以用一個KZG證明來表示一組數據[D₁…Dₙ]，該證明是從數據派生出的多項式P的證明：具體而言，多項式P滿足P(w) = D₁，P(w²) = D₂…P(wⁿ) = Dₙ。這裡的w是一個“單位根”，滿足wᴺ = 1，其中N是“評估域”的大小（所有操作都在一個有限域上進行）。

  • 要對P進行“承諾”，我們創建一個橢圓曲線點com(P) = P₀ * G + P₁ * S₁ +…+ Pₖ * Sₖ。在這裡：

    • G是曲線的生成點。

    • Pᵢ是多項式P的i次係數。

    • Sᵢ是“可信設置”中的第i個點。

  • 要證明P(z) = a，我們創建一個“商（quotient）多項式”Q = (P – a) / (X – z)，並創建一個對它的承諾com(Q)。只有在P(z)實際等於a時才能創建這樣的多項式。

  • 要驗證一個證明，我們檢查方程式Q * (X – z) = P – a，通過對證明com(Q)和多項式承諾com(P)進行橢圓曲線檢查，我們檢查e(com(Q), com(X – z)) ?= e(com(P) – com(a), com(1))。

一些重要的屬性需要理解：

  • 一個證明只是com(Q)的值，它佔用48字節。

  • com(P₁) + com(P₂) = com(P₁ + P₂)。

  • 這也意味著你可以將一個值“編輯”到現有的承諾中。假設我們知道Dᵢ當前為a，我們想將其設置為b，並且現有的承諾是com(P)。那麼，對“P的承諾，但P(wⁱ) = b，並且其他評估未發生”變化的承諾，我們設置com(new_P) = com(P) + (b – a) * com(Lᵢ)，其中Lᵢ是一個“拉格朗日多項式”，在wⁱ處等於1，在其他wʲ點處等於0。

  • 為了高效地執行這些更新，每個客戶端可以預先計算和存儲所有N個拉格朗日多項式（com(Lᵢ)）。在鏈上的合約中，存儲所有N個承諾可能太多了，所以可以通過對com(Lᵢ)的集合（或哈希(com(Lᵢ))值）進行KZG承諾來代替，這樣每當有人需要在鏈上更新樹時，只需提供適當的com(Lᵢ)及其正確性的證明。

因此，我們有了一個結構，我們可以不斷地向不斷增長的列表末尾添加值，雖然有一定的大小限制（實際上，數億個可能是可行的）。然後，我們將此作為我們管理（i）每個L2上存儲的鍵列表的承諾（com(key list）和鏡像到L1，以及（ii）存儲在以太坊L1上的L2鍵承諾列表的承諾的數據結構。

保持承諾的更新可能成為核心L2邏輯的一部分，或者可以通過存款和提取橋接來在沒有L2核心協議更改的情況下實現。

GZdKJLxkNXIv104jXLz0WLugBCDceaP4b0zjgMbm.png完整的證明需要：

  • 持有密鑰庫的L2上的最新com(key list)（48字節）

  • com(key list)在存儲所有鍵列表承諾的com(mirror_list)中的KZG證明（48字節）

  • 你在com(key list)中的密鑰的KZG證明（48字節，加上索引的4字節）

  • 實際上，可以將兩個KZG證明合併為一個，所以總大小只有100字節。

請注意一個細節：由於鍵密鑰列表是一個列表，而不是像狀態一樣的鍵/值映射，密鑰列表將不得不按順序分配位置。密鑰承諾合約將包含其自己的內部註冊表，將每個密鑰庫映射到一個ID，並且對於每個密鑰，它將存儲hash(key，密鑰庫的地址)而不僅僅是key，以明確地向其他L2傳達關於哪個密鑰庫的條目的信息。

這種技術的優勢在於在L2上性能非常好。數據大小為100字節，比ZK-SNARK小約4倍，比Merkle證明要小得多。計算成本主要是一次大小為2的配對檢查，約為119,000 gas。在L1上，數據不像計算那樣重要，因此不幸的是，KZG比Merkle證明要昂貴一些。

Verkle樹將如何工作？

Verkle樹基本上涉及將KZG承諾（或更高效且使用較簡單密碼學的IPA承諾）疊加在彼此之上：要存儲2⁴⁸個值，你可以對2²⁴個值的列表進行KZG承諾，其中每個值本身是對2²⁴個值的KZG承諾。 Verkle樹正在強烈考慮用於以太坊狀態樹，因為Verkle樹可以用於保存密鑰值映射而不僅僅是列表（基本上，你可以創建一個大小為2²⁵⁶的樹，但初始為空，只有在實際需要填充時才會填充特定部分的樹）。

YoCk3IRJ1FQnId3FfXdXTRfWkGS5BgfNzZ6WAfD9.pngVerkle樹的樣子

Verkle樹的證明比KZG略長；它們可能會有幾百字節長。它們也很難驗證，特別是如果嘗試將許多證明聚合成一個。

實際上，Verkle樹應該被視為類似於Merkle樹，但沒有SNARKing的可行性更高（因為數據成本較低），並且在使用SNARKing時更便宜（因為證明者成本較低）。

Verkle樹的最大優勢在於數據結構的統一性：Verkle證明可以直接在L1或L2狀態上使用，而無需覆蓋結構，並且對於L1和L2使用完全相同的機制。一旦量子計算機成為問題，或者一旦證明Merkle分支變得足夠高效，Verkle樹可以使用適用於SNARK的哈希函數在原地替換為二進制哈希樹。

聚合

如果N個用戶進行N個交易（或更現實地說，N個ERC-4337 UserOperations）需要證明N個跨鏈聲明，我們可以通過聚合這些證明來節省大量的gas：將這些交易組合成進入區塊或打包到區塊中的構建者可以創建一個單一的證明，同時證明所有這些聲明。

這可能意味著：

  • N個Merkle分支的ZK-SNARK證明

  • KZG多證明

  • Verkle多證明（或Verkle多證明的ZK-SNARK）

在這三種情況下，每個證明的成本僅為幾十萬個gas。構建者需要為每個使用該區塊的L2中的用戶製作一個這樣的證明；因此，為了對構建者有用，整個方案需要具有足夠的使用量，以便在多個主要L2上的同一區塊中往往至少有幾個交易。

如果使用ZK-SNARK，主要的邊際成本僅僅是在合約之間傳遞數字的“業務邏輯”，因此每個用戶可能需要幾千個L2 gas。如果使用KZG多證明，證明者需要為每個包含L2的keystore-holding L2添加48個gas，因此每個用戶的方案邊際成本將在此基礎上再增加約800個L1 gas（而不是每個用戶）。但是，這些成本遠遠低於不聚合的成本，後者不可避免地涉及每個用戶超過10,000個L1 gas和數十萬個L2 gas。對於Verkle樹，你可以直接使用Verkle多證明，每個用戶增加約100-200個字節，或者你可以創建Verkle多證明的ZK-SNARK，其成本與Merkle分支的ZK-SNARK類似，但證明成本要低得多。

從實現的角度來看，最好通過ERC-4337帳戶抽象標準讓捆綁器通過自定義方式聚合跨鏈證明。 ERC-4337已經為構建者聚合UserOperations的部分提供了機制。甚至已經有一個用於BLS簽名聚合的實現，這可以將L2上的gas成本降低1.5倍到3倍，具體取決於包括哪些其他形式的壓縮。

owU3EygDeHpUm5A9r9VTVz7tdXmp60Y0Ok2w0apX.png早期版本ERC-4337 BLS聚合簽名工作流

直接狀態讀取

最後一種可能性，僅適用於L2讀取L1（而不是L1讀取L2），這是修改L2，使其能夠直接對L1上的合約進行靜態調用。

這可以通過一種操作碼或預編譯來實現，它允許調用L1中的地址，gas和calldata，並返回輸出，儘管因為這些調用是靜態調用，它們不能實際上改變任何L1狀態。 L2已經意識到L1以處理存款，因此從技術上講，沒有任何阻止實現這種機制的根本原因（參見：Optimism提供支持靜態調用進入L1的RFP）。

請注意，如果密鑰庫位於L1上，並且L2集成了L1靜態調用功能，那麼根本不需要證明！但是，如果L2不集成L1靜態調用，或者如果密鑰庫位於L2上（一旦L1變得對用戶使用甚至稍微使用都太昂貴時可能會發生這種情況），那麼將需要證明。

L2如何獲取最新的以太坊狀態根

為了處理從L1到L2的消息（尤其是存款），所有的L2都需要一些功能來訪問最新的L1狀態。實際上，如果一個L2具有存款功能，那麼你可以使用該L2原樣將L1狀態根移動到L2上：只需讓L1上的合約調用BLOCKHASH操作碼，並將其作為存款消息傳遞到L2。 L2端可以接收到完整的區塊頭，並提取其狀態根。然而，每個L2都最好有一種明確的方式來直接訪問最新的L1全面狀態或最近的L1狀態根。

優化L2接收最新L1狀態根的主要挑戰是同時實現安全性和低延遲：

  • 如果L2以延遲方式實現“直接讀取L1”功能，只讀取已最終確定的L1狀態根，則延遲通常為15分鐘，但在極端情況下，如不活躍洩漏（必須能夠容忍），延遲可能長達幾週。

  • L2確實可以設計成讀取更近期的L1狀態根，但因為L1可能發生回滾（即使是在單槽最終確定性的情況下，也可能在不活躍洩漏期間發生回滾），因此L2也需要能夠回滾。從軟件工程的角度來看，這在技術上是具有挑戰性的，但至少Optimism已經具備了這種能力。

  • 如果使用存款橋將L1狀態根帶入L2，則簡單的經濟可行性可能要求存款更新之間有較長的時間間隔：如果一個存款的全部成本為100,000個gas，並假設以太坊價格為$1800，手續費為200 gwei，每天將L1狀態根帶入L2一次，那麼每個L2每天的成本為$36，或者每個L2每年的成本為$13,148，用於維護系統。如果延遲為一小時，這個成本將增加到每個L2每年$315,569。在最好的情況下，一些急於支付的富有用戶會為更新費用支付，並使系統保持最新狀態，以服務其他用戶。在最糟糕的情況下，某個無私的參與者將不得不自己支付費用。

  • “預言機”（至少在一些DeFi人士眼中被稱為“預言機”）在這裡不是一個可接受的解決方案：錢包密鑰管理是非常關鍵的底層功能，因此它應該最多依賴於一些非常簡單、具有密碼學信任的底層基礎設施。

另外，反向（L1讀取L2）：

  • 在optimistic rollup中，狀態根需要一周的時間才能到達L1，這是由於欺詐證明的延遲。在零zkrollup中，由於證明時間和經濟限制的結合，目前需要幾個小時，但未來的技術將減少這一時間。

  • 在L1讀取L2的情況下，使用“預確認”（來自排序器、認證者等）並不是一種可接受的解決方案。錢包管理是一個非常關鍵的安全性低級功能，因此L2->L1通信的安全級別必須是絕對的：甚至無法通過接管L2驗證者集合來推送錯誤的L1狀態根。 L1應該信任的唯一狀態根是L2在L1上的狀態根持有合約已經接受為最終的狀態根。

有些跨鏈操作的速度對於許多DeFi用例來說太慢了；對於這些情況，我們確實需要更快速的橋接方案，但這些方案的安全性模型可能不夠完善。然而，對於更新錢包密鑰的用例，較長的延遲更可接受：你不是將交易延遲幾個小時，而是將密鑰更改延遲。你只需要將舊密鑰保留更長時間。如果要更改密鑰是因為密鑰被盜，那麼你將面臨相當長的漏洞期，但可以通過一些措施來減輕風險，例如，錢包可以具備凍結功能。

總的來說，最小化延遲的最佳解決方案是L2以最佳方式實現直接從內部讀取L1狀態（或至少狀態根）的能力，其中每個L2區塊（或狀態根計算日誌）包含指向最近的L1區塊的指針，因此如果L1回滾，L2也可以回滾。密鑰庫合約應該放置在主網上或是ZK rollup L2上，這樣可以快速提交給L1。

u9gGyWasabyaQXXodRMZD1C1neF7tKHQ3XemKXSP.png

其他鏈需要與以太坊保持多少連接以維護基於以太坊或L2根的錢包

出人意料地，這個連接並不需要太多。它甚至不需要成為一個正式的L2，如果是一個L3或validium，只要該鏈直接訪問以太坊狀態根，並在以太坊發生回滾時重新組織或硬分叉的技術和社會承諾。

一個有趣的研究問題是確定一個鏈與多個其他鏈（例如以太坊和Zcash）之間在多大程度上具有這種形式的連接。直接而幼稚的方法是可能的，即如果以太坊或Zcash回滾，密的鏈將不得不重組（並在以太坊或Zcash硬分叉時進行硬分叉），但然後你的社區將具有雙重技術和政治依賴性（或者如果將你的鏈與許多其他鏈綁定，依賴性將更多）。基於ZK橋接的方案對51%攻擊或硬分叉不具備魯棒性。可能有更聰明的解決方案。

隱私保護

理想情況下，我們還希望保護隱私。如果你有許多由同一個密鑰庫管理的錢包，那麼我們希望確保：

  • 公眾不知道這些錢包彼此相互關聯。

  • 社交恢復監護人不知道他們正在監護的地址是什麼。

這會引起一些問題：

  • 我們不能直接使用Merkle 證明，因為它們不能保護隱私。

  • 如果我們使用KZG 或SNARKs，那麼證明需要提供驗證密鑰的盲化版本，而不洩露驗證密鑰的位置。

  • 如果我們使用聚合，那麼聚合器不應該以明文形式了解位置；相反，聚合器應該接收盲化證明，並有一種方式來聚合這些證明。

  • 我們不能使用“輕量級版本”（僅使用跨鏈證明更新密鑰），因為它會洩露隱私：如果由於更新過程導致多個錢包同時更新，時間上的洩露將暗示這些錢包可能相關。因此，我們必須使用“重量級版本”（每個交易都使用跨鏈證明）。

對於SNARKs，解決方案在概念上很簡單：證明默認是隱藏信息的，聚合器需要生成遞歸SNARK 來證明這些SNARKs。

oPPxXrxZMKxPRzuumeg4QKpYKVsumDQESW4VmbCB.png這種方法的主要挑戰是聚合需要聚合器創建遞歸SNARK，而這在當前情況下速度相對較慢。

對於KZG，我們可以以非索引洩露KZG 證明的工作為起點（也可參考：Caulk 論文中對該工作的更正式版本）。然而，盲化證明的聚合是一個需要更多關注的開放問題。

不幸的是，直接從L2 內部讀取L1 並不能保護隱私，儘管實現直接讀取功能仍然非常有用，既可以最小化延遲，也可以用於其他應用程序。

總結

  • 要實現跨鏈社交恢復錢包，最現實的工作流程是在一個地方維護一個密鑰庫（keystore），並在許多位置維護多個錢包（wallets），其中錢包要么（i）讀取密鑰庫以更新其本地驗證密鑰視圖，要么（ii）在驗證每個交易時讀取密鑰庫。

  • 實現這一目標的一個關鍵因素是跨鏈證明。我們需要努力優化這些證明。最好的選擇可能是ZK-SNARKs、等待出現的Verkle證明，或者自行構建的KZG解決方案。

  • 長期而言，聚合協議將是必需的，聚合器將作為創建用戶提交的所有UserOperations捆綁包的一部分生成聚合證明，以最小化成本。這可能需要與ERC-4337生態系統整合，儘管可能需要對ERC-4337進行一些修改。

  • L2應該優化以最小化從L2內部讀取L1狀態（或至少狀態根）的延遲。 L2直接讀取L1狀態是理想的，並可以節省證明空間。

  • 錢包不僅可以部署在L2上，還可以放置在與以太坊連接較低的系統上（L3，甚至僅同意包括以太坊狀態根並在以太坊回滾或硬分叉時重新組織或硬分叉的獨立鏈）。

  • 然而，密鑰庫應該放置在L1或高安全性的ZK rollup L2上。放置在L1上可以節省很多複雜性，儘管從長遠來看，即使這也可能太昂貴，因此需要在L2上放置密鑰庫。

  • 保護隱私將需要額外的工作並增加一些困難。然而，我們應該朝向保護隱私的解決方案發展，並確保我們提出的任何解決方案都能與保護隱私保持前向兼容。

Total
0
Shares
Share 0
Tweet 0
Share 0
Related Posts