Vitalik：深入了解跨L2讀取——跨鏈證明有哪些方案_ARK:以太坊

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

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

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

本文目錄：

目標是什么？

跨鏈證明是什么樣的？

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

Merkle證明

ZKSNARKs

特殊目的的KZG證明

Verkle樹證明

聚合

直接狀態讀取

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

不是L2鏈的錢包

隱私保護

總結

目標是什么？

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

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

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

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

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

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

ZK-EVM Kakarot完成pre-seed輪融資，Vitalik、StarkWare等參投:6月2日消息，zkEVM 開發平臺 Kakarot 完成Pre-Seed 輪融資，StarkWare、LambdaClass 和天使投資人 Vitalik、Nicolas Bacca、Rand Hindi 等參投。

Kakarot zkEVM 是 Cairo 實施的 EVM，利用 STARK 證明來證明交易和區塊，確保透明度和安全性。據介紹，Kakarot zkEVM 發展分為三個階段：1、作為 EVM 存在于 Starknet L2 上；2、和 Starknet 定序器 Madara 合力創建第 3 層 zkEVM；3、Kakarot 和 Madara 組合啟用類型 1 zkEVM。[2023/6/2 11:54:47]

有兩種實現方法：

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

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

缺點：要更改驗證密鑰，你必須在密鑰庫和已初始化的每個錢包中進行鏈上密鑰更改。這可能需要大量的Gas費用。

2、重量級版本：每個交易都需要一個跨鏈證明，證明密鑰當前存在于密鑰庫中。

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

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

跨鏈證明是什么樣的？

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

假設密鑰庫位于Linea，錢包位于Kakarot。完整的錢包密鑰證明包括：

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

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

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

1、我們使用什么樣的證明？

2、L2如何首先了解最近的L1狀態根？相反，L1如何了解L2狀態根？

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

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

有五種主要選擇：

Merkle證明

通用ZK-SNARKs

Vitalik Buterin：FTX事件為加密貨幣提供了教訓:金色財經報道，以太坊聯合創始人Vitalik Buterin在接受采訪時表示，FTX事件是一個\"巨大的悲劇\"，但區塊鏈技術很穩定，以太坊社區中的許多人也將其視為一直相信的事情的驗證，即中心化的任何東西都是可疑的，公開透明的代碼高于個人。此外，VitalikButerin還表示，加密貨幣要充分發揮其潛力還有很長的路要走。（彭博社）[2022/11/21 22:11:15]

特殊目的證明

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

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

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

“聚合”是指在每個區塊內將用戶提供的所有證明聚合成一個大的元證明，將所有證明組合在一起。這對于SNARKs和KZG是可能的，但對于Merklebranches不可能/log的工作量，可能實際上只有15-30%，所以成本可能不值得）。

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

Merkle證明將如何工作？

這個比較簡單：直接按照前一節的圖表進行操作。更準確地說，每個“證明”將包含：

一個Merklebranch，根據L2所知的最新以太坊狀態根，證明持有密鑰庫的L2的狀態根。持有密鑰庫的L2的狀態根存儲在已知地址的已知存儲slot中，因此路徑可以硬編碼。

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

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

更大的問題是成本。Merkle證明很長，而Patricia樹不幸地比必要的長度多約3.9倍字節，而因為以太坊的Patricia樹每個子節點有16個葉子，這些樹的證明為32*15*log16~=125*log2字節）。在大約2.5億個帳戶的狀態下，每個證明的長度為125*28=3500字節，約為56,000gas，加上解碼和驗證哈希的額外成本。

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

我們可以通過查看L1gas成本和L2gas成本之間的比較來計算這意味著什么：

Vitalik發文《收入-邪惡曲線：用另一種方式來思考公共產品資金的優先性》:10月28日消息，Vitalik發文《收入-邪惡曲線：用另一種方式來思考公共產品資金的優先性》，文中嘗試提供一種不同的方法來分析私人和公共之間的“混合”商品：收入-邪惡曲線。這是一種整體“社區”中的“混合經濟”環境與商業市場以及中心化資助者的補貼相結合的假設。對于如何在當今的加密社區、國家和許多其他現實世界環境中為公共產品提供資金有一定啟發。[2022/10/28 11:51:36]

L1當前簡單的發送操作比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,000gas，并占用約400字節的數據。因此，從計算角度來看，ZK-SNARK的成本是當前基本交易成本的19倍，從數據角度來看，ZK-SNARK的成本是基本交易成本的4倍，也是未來基本交易成本的16倍。

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

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

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

我們可以用一個KZG證明來表示一組數據，該證明是從數據派生出的多項式P的證明：具體而言，多項式P滿足P(w)=D?，P(w2)=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，我們創建一個“商多項式”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))。

Vitalik Buterin批評比特幣S2F模型給人帶來錯誤的確定感:6月21日消息，以太坊創始人Vitalik Buterin在推特上批評比特幣S2F模型（Stock-to-flow）給人帶來一種錯誤的確定感，預定的數字會給人增加有害的感覺，盲從者應該受到嘲笑。PlanB回應了Vitalik的批評，稱“人們正在為他們失敗的項目或錯誤的投資尋找替罪羊。”

據悉，荷蘭匿名機構投資者PlanB一直在推廣比特幣S2F模型，該模型因成功預測了幾次比特幣價格而獲得大量關注。許多批評者指出的S2F模型的關鍵問題是片面估計，它只考慮BTC的供應方，而沒有假設需求將繼續增長。（Cointelegraph）[2022/6/21 4:43:16]

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

一個證明只是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個拉格朗日多項式。在鏈上的合約中，存儲所有N個承諾可能太多了，所以可以通過對com(L?)的集合進行KZG承諾來代替，這樣每當有人需要在鏈上更新樹時，只需提供適當的com(L?)及其正確性的證明。

因此，我們有了一個結構，我們可以不斷地向不斷增長的列表末尾添加值，雖然有一定的大小限制。然后，我們將此作為我們管理每個L2上存儲的鍵列表的承諾和鏡像到L1，以及存儲在以太坊L1上的L2鍵承諾列表的承諾的數據結構。

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

完整的證明需要：

持有密鑰庫的L2上的最新com(keylist)

com(keylist)在存儲所有鍵列表承諾的com(mirror_list)中的KZG證明

你在com(keylist)中的密鑰的KZG證明

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

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

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

Waves生態項目Gravity測試框架正在添加幣安智能鏈:10月20日消息，Waves生態項目Gravity測試框架正在添加幣安智能鏈。幣安智能鏈是幣安鏈的平行公鏈，可以通過Ankr創建智能合約和BNB staking。除了以太坊和Waves，幣安智能鏈將成為Gravity網絡新的主要目標公鏈。

在準備這次集成時，Waves生態項目Gravity團隊使用了Waves合作伙伴Ankr提供的一鍵式BSC節點部署解決方案。[2020/10/20]

Verkle樹將如何工作？

Verkle樹基本上涉及將KZG承諾疊加在彼此之上：要存儲2??個值，你可以對22?個值的列表進行KZG承諾，其中每個值本身是對22?個值的KZG承諾。Verkle樹正在強烈考慮用于以太坊狀態樹，因為Verkle樹可以用于保存密鑰值映射而不僅僅是列表。

Verkle樹的樣子

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

實際上，Verkle樹應該被視為類似于Merkle樹，但沒有SNARKing的可行性更高，并且在使用SNARKing時更便宜。

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

聚合

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

這可能意味著：

N個Merkle分支的ZK-SNARK證明

KZG多證明

Verkle多證明

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

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

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

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

直接狀態讀取

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

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

請注意，如果密鑰庫位于L1上，并且L2集成了L1靜態調用功能，那么根本不需要證明！但是，如果L2不集成L1靜態調用，或者如果密鑰庫位于L2上，那么將需要證明。

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，手續費為200gwei，每天將L1狀態根帶入L2一次，那么每個L2每天的成本為$36，或者每個L2每年的成本為$13,148，用于維護系統。如果延遲為一小時，這個成本將增加到每個L2每年$315,569。在最好的情況下，一些急于支付的富有用戶會為更新費用支付，并使系統保持最新狀態，以服務其他用戶。在最糟糕的情況下，某個無私的參與者將不得不自己支付費用。

“預言機”在這里不是一個可接受的解決方案：錢包密鑰管理是非常關鍵的底層功能，因此它應該最多依賴于一些非常簡單、具有密碼學信任的底層基礎設施。

另外，反向：

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

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

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

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

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

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

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

隱私保護

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

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

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

這會引起一些問題：

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

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

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

我們不能使用“輕量級版本”，因為它會泄露隱私：如果由于更新過程導致多個錢包同時更新，時間上的泄露將暗示這些錢包可能相關。因此，我們必須使用“重量級版本”。

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

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

對于KZG，我們可以以非索引泄露KZG證明的工作為起點。然而，盲化證明的聚合是一個需要更多關注的開放問題。

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

總結

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

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

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

L2應該優化以最小化從L2內部讀取L1狀態的延遲。L2直接讀取L1狀態是理想的，并可以節省證明空間。

錢包不僅可以部署在L2上，還可以放置在與以太坊連接較低的系統上。

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

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

Tags：ARKNAR以太坊ARK幣是什么幣NAR價格NAR幣以太坊幣是什么幣

POL幣最新價格