Vitalik：以太坊的必要轉型—L2擴展、錢包安全和隱私

當以太坊從一項年輕的實驗性技術轉變為一項成熟的技術堆棧，能夠真正為普通用戶帶來開放、全球化和無需許可的體驗時，這個堆棧需要經歷三個主要的技術轉變，大致上同時進行：

L2 擴展轉變 - 所有人都遷移到 rollups

錢包安全性轉變 - 所有人都遷移到智能合約錢包

隱私轉變 - 確保提供隱私保護的資金轉移，並確保正在開發的所有其他工具（社交恢復、身份、聲譽）都能保護隱私

這是生態系統轉型的三角關係。你只能選擇 3 個中的 3 個。

沒有第一個，以太坊就會失敗，因為每筆交易都需要花費 3.75 美元（如果我們有另一輪牛市，那麼價格為 82.48 美元），並且每個面向大眾市場的產品最終都會忘記鏈，並且對一切採取集中化的解決方案。

沒有第二個，以太坊就會失敗，因為用戶不願意儲存他們的資金（和非金融資產），所有人都會轉移到集中式交易所。

沒有第三個，以太坊就會失敗，因為所有交易（和 POAPs 等）都公開給任何人看，這對於許多用戶來說是對隱私的過高犧牲，所有人都會轉移到至少有一些隱藏數據的集中化解決方案。

以上述原因，這三次轉變至關重要。但由於解決這些問題需要強烈的協調性，因此它們也是具有挑戰性的。不僅需要改進協議的功能，有些情況下，我們與以太坊互動的方式需要進行相當基礎的變化，需要應用和錢包進行深入的改變。

這三次轉變將徹底改變用戶和地址之間的關係

在 L2 擴展世界中，用戶將存在於許多 L2 中。你是 ExampleDAO 的成員，它位於 Optimism 上嗎？那麼你在 Optimism 上就有一個帳戶！你在 ZkSync 的穩定幣系統中持有 CDP 嗎？那麼你在 ZkSync 上就有一個帳戶！你曾經嘗試過一些恰好位於 Kakarot 上的應用嗎？那麼你在 Kakarot 上就有一個帳戶！用戶只有一個地址的日子將一去不復返。

我在四個地方有 ETH，根據我的 Brave Wallet 視圖。是的，Arbitrum 和 Arbitrum Nova 是不同的。不用擔心，隨著時間的推移，這會變得更加複雜！

智能合約錢包增加了更多的複雜性，使得在 L1 和各種 L2 上擁有相同地址變得更加困難。如今，大多數用戶正在使用外部擁有的帳戶，其地址實際上就是用於驗證簽名的公鑰的哈希 - 所以在 L1 和 L2 之間沒有任何變化。然而，對於智能合約錢包，保持一個地址變得更加困難。儘管已經做了大量的工作，試圖使地址成為網路間等價的代碼的哈希，尤其是 CREATE 2 和 ERC-2470 單例工廠，但是要完美實現這一點非常困難。一些 L2（例如 "type 4 ZK-EVMs"）並不完全等同於 EVM，通常使用 Solidity 或中間裝配代替，從而阻止了哈希等價。即使你可以擁有哈希等價性，錢包通過密鑰變化改變所有權的可能性也會產生其他的非直觀後果。

隱私需要每個用戶擁有更多的地址，甚至可能改變我們處理的地址類型。如果隱私地址提議得到廣泛使用，每個用戶不再只有幾個地址，或者在每個 L2 上有一個地址，而可能在每個交易中都有一個地址。其他的隱私方案，甚至是現有的方案如 Tornado Cash，會以不同的方式改變資產的儲存方式：許多用戶的資金儲存在同一個智能合約（因此在同一個地址）中。要向特定的用戶發送資金，用戶需要依賴隱私方案自己的內部地址系統。

如我們所見，這三次轉變以不同的方式削弱了「一個用戶 ~= 一個地址」的心理模型，並且其中一些效果反饋到執行轉變的複雜性中。兩個特別的複雜點是：

1. 如果你想付款給某人，你如何獲得付款給他們的資訊？

2. 如果用戶在不同的鏈上不同的地方儲存了許多資產，他們如何進行密鑰更換和社交恢復？

三次轉變與鏈上支付（和身份）有關

我在 Scroll 上有硬幣，我想支付咖啡（如果「我」是字面意思，指的是我這篇文章的作者，那麼「咖啡」當然是「綠茶」的換喻）。你正在賣我咖啡，但你只準備在 Taiko 上接收硬幣。我該怎麼辦？

基本上有兩種解決方案：

1. 接收錢包（可能是商家，也可能只是普通個人）努力支持每個 L2，並具有一些異步整合資金的自動功能。

2. 接收者提供他們的 L2 和他們的地址，發送者的錢包通過某種跨 L2 橋接系統自動將資金路由到目標 L2。

當然，這些解決方案可以組合：接收者提供他們願意接受的 L2 列表，發送者的錢包計算支付，這可能涉及直接發送（如果他們幸運的話），或者通過跨 L2 橋接路徑。

但這只是三次轉變引入的關鍵挑戰的一個例子：像支付某人這樣的簡單行為開始需要比只有一個 20 字節地址的資訊更多。

智能合約錢包的轉變幸運的是對地址系統的負擔不大，但是在應用程序堆棧的其他部分仍然有一些需要解決的技術問題。錢包需要更新，以確保它們不僅僅是在交易中發送 21000 gas，而且更重要的是確保錢包的支付接收端不僅跟蹤從 EOAs 的 ETH 轉移，也跟蹤由智能合約代碼發送的 ETH。依賴於地址所有權不變的假設的應用（例如，禁止智能合約以強製版稅的 NFT）將不得不找到其他方式來實現他們的目標。智能合約錢包也會使一些事情變得更容易 - 特別是，如果有人只接收非 ETH 的 ERC 20 代幣，他們將能夠使用 ERC-4337 付款人來用那個代幣支付 gas 費。

另一方面，隱私再次提出了我們還沒有真正解決的主要挑戰。最初的 Tornado Cash 並沒有引入這些問題，因為它不支持內部轉賬：用戶只能存入系統並提取出來。一旦你可以進行內部轉賬，用戶就需要使用隱私系統的內部地址方案。在實踐中，用戶的「支付資訊」需要包含（i）某種「支出公鑰」，即接收者可以用來花費的秘密的承諾，以及（ii）發送者發送只有接收者可以解密的加密資訊的方式，以幫助接收者發現支付。

隱私地址協議依賴於一個元地址的概念，其工作方式是：元地址的一部分是發送者的支出密鑰的一個盲化版本，另一部分是發送者的加密密鑰（儘管最小的實現可以設置這兩個鍵是相同的）。

這裡的關鍵教訓是，在一個注重隱私的生態系統中，用戶將擁有支出公鑰和加密公鑰，用戶的「支付資訊」將必須包含這兩種密鑰。除了支付以外，還有其他一些好的理由來擴展這個方向。例如，如果我們想要基於以太坊的加密電子郵件，用戶將需要公開提供某種形式的加密密鑰。在「EOA 世界」中，我們可以重新使用帳戶密鑰來實現這個目標，但在一個安全的智能合約錢包世界中，我們可能應該有更明確的功能來實現這個目標。這也將有助於使基於以太坊的身份更兼容於非以太坊的分散隱私生態系統，最突出的例子是 PGP 密鑰。

三個轉型和密鑰恢復

在一個用戶可能有多個地址的世界中，實現密鑰更改和社交恢復的默認方式是讓用戶對每個地址單獨進行恢復程序。這可以一鍵完成：錢包可以包含軟體，以便在所有用戶的地址上同時執行恢復程序。然而，即使有這樣的用戶體驗簡化，天真的多地址恢復也存在三個問題：

燃氣費用的不切實際：這一點不言自明。

反事實地址：尚未發布其智能合約的地址（實際上，這意味著你還沒有從該帳戶發送過資金的帳戶）。作為一個用戶，你有可能無限數量的反事實地址：每個 L2 上都有一個或多個，包括還不存在的 L2，還有一個完全不同的無限反事實地址集合，源自隱秘地址方案。

隱私：如果用戶故意有許多地址以避免將它們鏈接在一起，他們肯定不希望通過在同一時間或差不多的時間恢復它們來公開鏈接所有的地址！

解決這些問題是困難的。幸運的是，有一個相當優雅的解決方案，表現得相當好：一種將驗證邏輯和資產持有分開的架構。

每個用戶都有一個密鑰庫合約，存在於一個位置（可能是主網或特定的 L2）。然後用戶在不同的 L2 上有地址，其中每個地址的驗證邏輯都是指向密鑰庫合約的指針。從這些地址中花費將需要一個進入密鑰庫合約的證明，顯示當前（或更實際的，最近的）支出公鑰。

證明可以通過幾種方式實現：

1. 直接在 L2 中讀取只讀的 L1 訪問權限。可以修改 L2 以給予他們直接讀取 L1 狀態的方法。如果密鑰庫合約在 L1 上，這將意味著 L2 內的合約可以「免費」訪問密鑰庫。

2. 默克爾分支。默克爾分支可以證明 L1 狀態到 L2，或者 L2 狀態到 L1，或者你可以結合這兩者來證明一個 L2 的狀態的部分給另一個 L2。默克爾證明的主要弱點是由於證明長度的高燃氣費用：一個證明可能需要 5 kB，儘管由於 Verkle 樹，這將在未來減少到小於 1 kB。

3. ZK-SNARKs。你可以通過使用默克爾分支的 ZK-SNARK 而不是分支本身來減少數據成本。可以構建鏈下聚合技術（例如，基於 EIP-4337 ），讓一個單一的 ZK-SNARK 驗證所有的跨鏈狀態證明在一個塊中。

4. KZG 承諾。L2 或者在其之上構建的方案，可以引入一個順序尋址系統，允許在這個系統內部的狀態證明只有 48 字節長。像 ZK-SNARKs 一樣，一個多證明方案可以將所有這些證明合併為每個塊的單個證明。

如果我們想避免每次交易都做一個證明，我們可以實現一個更輕量級的方案，只需要恢復時做一個跨 L2 的證明。從一個帳戶中花費將取決於一個支出密鑰，其對應的公鑰儲存在該帳戶中，但恢復將需要一個事務，複製在密鑰庫中的當前支出公鑰。在反事實地址中的資金即使你的舊密鑰不安全也是安全的： 「激活」一個反事實地址，將其轉變為一個工作合約將需要做一個跨 L2 的證明，複製當前的支出公鑰。這個在 Safe 論壇上的主題描述了一個類似的架構可能是如何工作的。

為了給這樣的方案增加隱私，我們只需要加密指針，然後在 ZK-SNARKs 中做所有的證明：

通過更多的工作（例如，以這個工作為起點），我們也可以剝離大部分 ZK-SNARKs 的複雜性，製作一個更簡單的基於 KZG 的方案。

這些方案可能會變得複雜。不過，這些方案之間有許多潛在的協同效應。例如，「密鑰庫合約」的概念也可能是前一節提到的「地址」挑戰的解決方案：如果我們希望用戶擁有持久性地址，這些地址不會在用戶更新密鑰時發生變化，我們可以將隱秘的元地址、加密密鑰和其他資訊放入密鑰庫合約中，並使用密鑰庫合約的地址作為用戶的「地址」。

許多二級基礎設施需要更新

使用 ENS 是昂貴的。今天， 2023 年 6 月，情況還不算太糟：交易費用雖然高，但還是可以與 ENS 域名費用相比較的。註冊 zuzalu.eth 花費我大約 $ 27 ，其中 $ 11 是交易費用。但是如果我們再有一個牛市，費用將會飆升。即使沒有 ETH 價格上漲，燃氣費返回到 200 gwei 將會把域名註冊的交易費提高到 $ 104 。因此，如果我們希望人們真正使用 ENS，特別是像去中心化社交媒體這樣的應用場景，用戶要求幾乎免費註冊（ENS 域名費用不是問題，因為這些平台為他們的用戶提供子域），我們需要 ENS 在 L2 上運行。

幸運的是，ENS 團隊已經開始行動，ENS 在 L2 上實際上正在發生！ERC-3668 （也稱為「CCIP 標準」），與 ENSIP-10 一起，提供了一種在任何 L2 上自動驗證 ENS 子域的方法。CCIP 標準要求設置一個智能合約，描述了驗證 L2 數據證明的方法，域名（例如，Optinames 使用 ecc.eth）可以被放在這樣一個合約的控制下。一旦 CCIP 合約在 L1 上控制 ecc.eth，訪問 some subdomain.ecc.eth 將自動涉及查找和驗證證明（例如，默克爾分支）的 L2 狀態，實際上儲存該特定子域。

實際獲取證明涉及訪問儲存在合約中的一系列 URL，這 admittedly 感覺像是中心化，儘管我會辯稱它實際上並不是：它是一個 1-of-N 信任模型（無效的證明會被 CCIP 合約的回調函數中的驗證邏輯捕獲，只要有一個 URL 返回有效的證明，就沒有問題）。這個 URL 列表可能包含數十個 URL。

ENS CCIP 的工作是一個成功的例子，應該被視為我們所需要的那種激進改革是可能的標誌。但還需要做更多的應用層面的改革。一些例子包括：

許多 dapp 依賴用戶提供鏈下簽名。對於外部擁有的帳戶（EOA），這很簡單。ERC-1271 為智能合約錢包提供了一個標準化的方法來實現這一點。然而，許多 dapp 仍然不支持 ERC-1271 ；他們需要支持。

那些使用「這是 EOA 嗎？」來區分用戶和合約的 Dapp（例如，為了防止轉賬或執行版稅）將會破裂。一般來說，我建議不要試圖找到一個純技術的解決方案；弄清楚特定的加密控制權轉讓是否是有益權益轉讓的問題是一個困難的問題，可能無法在不藉助一些鏈下社區驅動機制的情況下解決。最有可能的是，應用程序將不得不更少地依賴於阻止轉移，更多地依賴於像 Harberger 稅這樣的技術。

錢包如何與支出和加密密鑰互動將需要改進。目前，錢包通常使用確定性簽名來生成應用特定的密鑰：使用 EOA 的私鑰對一個標準隨機數（例如，應用程序名稱的哈希）進行簽名，生成一個不能在沒有私鑰的情況下生成的確定性值，所以從技術上講是安全的。然而，這些技術對於錢包來說是「不透明的」，阻止了錢包實施用戶界面級別的安全檢查。在一個更成熟的生態系統中，簽名、加密和相關功能需要更明確地由錢包處理。

輕客戶端（例如 Helios）將不得不驗證 L2，而不僅僅是 L1。今天，輕客戶端專注於檢查 L1 頭部的有效性（使用輕客戶端同步協議），以及驗證源於 L1 頭部的 L1 狀態和交易的默克爾分支。明天，他們還需要驗證源於 L1 中儲存的狀態根的 L2 狀態的證明（這個更先進的版本實際上會查看 L2 的預確認）。

錢包需要保護資產和數據  

現在，錢包的業務是保護資產。一切都存在鏈上，錢包需要保護的唯一東西就是當前保護這些資產的私鑰。如果你更換了密鑰，你可以在第二天安全地在網路上發布你以前的私鑰。然而，在一個零知識證明的世界裡，情況已經不再是這樣了：錢包不僅僅在保護認證憑證，它還在保護你的數據。

我們在 Zupass 看到了這樣一個世界的第一個跡象，Zupass 是在 Zuzalu 使用的基於 ZK-SNARK 的身份系統。用戶有一個私鑰，他們用它來認證系統，可以用來做基本的證明，比如「證明我是一個 Zuzalu 的居民，但不透露是哪一個」。但是，Zupass 系統也開始有其他應用程序建立在上面，最著名的就是郵票（Zupass 的 POAPs 版本）。

我許多的 Zupass 郵票之一，證明我是 Team Cat 的驕傲成員。

郵票比 POAPs 提供的關鍵特性是，郵票是私有的：你在本地持有數據，只有當你想讓他們擁有你的這些資訊時，你才會向他們證明郵票（或郵票上的一些計算）。但這增加了風險：如果你失去了這些資訊，你就失去了你的郵票。

當然，持有數據的問題可以歸結為持有一個加密密鑰的問題：第三方（甚至是鏈）可以持有數據的加密副本。這有一個方便的優點，即你採取的行動不會改變加密密鑰，因此不需要與保持你的加密密鑰安全的系統進行任何交互。但即使如此，如果你失去了你的加密密鑰，你就失去了一切。反過來，如果有人看到了你的加密密鑰，他們就能看到被那把密鑰加密的所有東西。

Zupass 的事實上的解決方案是鼓勵人們在多個設備上儲存他們的密鑰（例如，筆記本電腦和手機），因為他們同時失去所有設備的機率很小。我們可以更進一步，使用秘密共享來儲存密鑰，將密鑰分割在多個守護者之間。

這種通過 MPC 進行的社交恢復對錢包來說並不是一個足夠的解決方案，因為這意味著不僅當前的守護者，而且之前的守護者可能會串通起來盜走你的資產，這是一個無法接受的高風險。但是，泄露隱私通常比完全失去資產的風險要小，如果某人需要高度保護隱私的用例，他可以通過不備份那些需要保護隱私行動的關聯密鑰，來接受更高的損失風險。

為了避免用一個複雜的多種恢復路徑系統壓垮用戶，支持社交恢復的錢包可能需要同時管理資產恢復和加密密鑰恢復。

回到身份問題

這些變化的一個共同主題是，你在鏈上使用的代表「你」的加密標識符的「地址」概念必須進行徹底的改變。「如何與我交互的指示」不再僅僅是一個 ETH 地址；他們必須以某種形式，包含在多個 L2 上的多個地址，隱秘的元地址，加密密鑰和其他數據的某種組合。

實現這一點的一種方法是讓 ENS 成為你的身份：你的 ENS 記錄可以包含所有這些資訊，如果你向某人發送 bob.eth（或 bob.ecc.eth，或...），他們可以查找並了解如何支付和與你互動的所有事情，包括在更複雜的跨領域和保護隱私的方式中。

但是，這種以 ENS 為中心的方法有兩個弱點：

它將太多的事情與你的名字綁定。你的名字不是你，你的名字只是你的許多屬性之一。你應該可以改變你的名字，而不需要行動你的整個身份配置文件並在許多應用中更新一大堆記錄。

你不能有無信任的反事實名字。任何區塊鏈的一個關鍵 UX 特性是能夠向還沒有與鏈交互過的人發送幣。如果沒有這樣的功能，就會有一個雞蛋和母雞的問題：與鏈交互需要支付交易費用，而支付費用需要...已經擁有幣。ETH 地址，包括帶有 CREATE 2 的智能合約地址，都有這個特性。ENS 名稱沒有，因為如果兩個 Bob 都在鏈下決定他們是 bob.ecc.eth，沒有辦法選擇哪一個得到這個名字。

一種可能的解決方案是將更多的東西放入這篇文章前面架構中提到的密鑰庫合約中。密鑰庫合約可以包含關於你和如何與你互動的各種資訊（通過 CCIP，其中一些資訊可以在鏈下），用戶可以將他們的密鑰庫合約作為主要的標識符。但他們接收的實際資產將被儲存在各種不同的地方。密鑰庫合約不與名稱綁定，它們是反事實友好的：你可以生成一個只能由擁有某些固定初始參數的密鑰庫合約初始化的地址。

另一個解決方案類別與放棄用戶面向地址的概念有關，這與比特幣支付協議的精神相似。一種想法是更多地依賴於發件人和收件人之間的直接通信渠道；例如，發件人可以發送一個索取鏈接（作為明確的 URL 或 QR 碼），收件人可以使用該鏈接以他們希望的方式接受支付。

無論是發件人還是收件人首先採取行動，更多地依賴錢包直接實時生成最新的付款資訊都可以減少摩擦。話雖如此，持久的標識符是方便的（尤其是與 ENS 一起），並且在實踐中，發件人和收件人之間存在直接通信的假設是一個非常棘手的問題，所以我們可能會看到不同技術的組合。

在所有這些設計中，保持事物既去中心化又對用戶易於理解至關重要。我們需要確保用戶能夠輕鬆地訪問他們當前資產的最新視圖，以及已發布的面向他們的資訊。這些視圖應該依賴開放的工具，而不是專有解決方案。避免更複雜的支付基礎設施變成一個開發人員難以理解正在發生的事情並將其適應到新環境的不透明的「抽象塔」將需要努力工作。儘管面臨挑戰，但是實現以太坊的可擴展性、錢包安全性和普通用戶的隱私至關重要。這不僅僅是關於技術可行性，而是關於普通用戶的實際可訪問性。我們需要迎接這個挑戰。

特別感謝 Dan Finlay、Karl Floersch、David Hoffman 以及 Scroll 和 SoulWallet 團隊的反饋、審查和建議。

原文連結