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

原文標題：《The Three Transactions》

原文作者：Vitalik Buterin

原文編譯：MarsBit

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

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 團隊的回饋、審查和建議。

原文連結

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia