Vitalik 博文：沒有這三個技術改變，以太坊將會失敗

作者 | Vitalik

編譯 | @rickawsb

隨着以太坊從一個年輕的實驗性技術轉變為一個成熟的技術堆棧，能夠為普通用戶帶來开放、全球和無需許可的體驗，這個堆棧需要同時經歷三個重大的技術轉變：

●第一個是 二層擴展轉變 ——所有人都轉向二層擴展解決方案。

●第二個是 錢包安全轉變 ——所有人都轉向智能合約錢包。

●第三個是 隱私轉變 ——確保提供保護隱私的資金轉账方式，並確保正在开發的所有其他工具（社交恢復、身份、聲譽）都保護隱私。

生態系統轉換三角形，你只能從中選擇 3 個

如果沒有實現第一個，以太坊就會失敗，因為每筆交易的成本為 3.75 美元（如果我們有另一次牛市，則為 82.48 美元），並且針對大衆市場的每個產品都不可避免地會忘記區塊鏈並為所有事情採用中心化的解決方法。

如果沒有實現第二個，以太坊就會失敗，因為用戶不愿意存儲他們的資金（和非金融資產），並且每個人都轉向中心化交易所。

如果沒有實現第三個，以太坊就會失敗，因為所有交易（和 POAP 等）都公开供任何人查看，這對許多用戶來說是一種太高的隱私犧牲，並且每個人都轉向至少在某種程度上隱藏你的數據的集中式解決方案。

這三個轉變對上述原因至關重要。但是由於涉及到適當解決這些問題的緊密協調，這些轉變也充滿挑战。需要改進的不僅僅是協議的功能；在某些情況下，我們與以太坊的交互方式也需要發生根本性的改變，這要求應用程序和錢包進行深層次的改變。

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

在二層擴展的世界中，用戶將存在於許多不同的二層網絡上。你是 ExampleDAO 的成員，它存在於 Optimism 上嗎？那么你就在 Optimism 上有一個帳戶！你在 ZkSync 上持有一個穩定幣系統中的 CDP 嗎？那么你就在 ZkSync 上有一個帳戶！你曾經嘗試過在 Kakarot 上運行的某個應用程序嗎？那么你在 Kakarot 上有一個帳戶！用戶只有一個地址的時代將一去不復返。

根據我的 Brave 錢包視圖，我在四個地方擁有以太坊。沒錯，Arbitrum 和 Arbitrum Nova 是不同的。別擔心，隨着時間的推移，情況會變得更加混亂！

智能合約錢包增加了更多復雜性，因為它使得在 L1 和各個 L2 之間擁有相同地址變得更加困難。 如今，大多數用戶使用的是外部擁有的帳戶（EOA），其地址實際上是用於驗證籤名的公鑰的哈希值，因此在 L1 和 L2 之間沒有任何變化。然而，使用智能合約錢包時，保持一個地址變得更加困難。雖然已經做了很多工作，嘗試使地址成為可以在不同網絡之間等效的代碼哈希（最值得注意的是 CREATE2 和 ERC-2470單例工廠），但要完美實現這一點很難。一些 L2 （例如，“第四型 ZK-EVMs”）並不完全等同於 EVM，通常使用 Solidity 或中間級別的匯編語言，從而阻止了哈希的等效性。即使可以實現哈希等效性，錢包通過密鑰更改而改變所有權的可能性會產生其他令人費解的後果。

隱私要求每個用戶擁有更多的地址，甚至可能會改變我們處理的地址類型。 如果隱形地址提案被廣泛使用，那么用戶可能每次交易都會有一個地址。其他隱私方案，甚至包括現有的方案，如 Tornado Cash，以不同的方式改變了資產的存儲方式：許多用戶的資金存儲在同一個智能合約中（因此在同一個地址上）。為了向特定用戶發送資金，用戶將需要依賴隱私方案自己的內部尋址系統。

正如我們所見， 這三個轉變以不同的方式削弱了“一個用戶=一個地址” 的心理模型 ，並且其中一些影響反過來又增加了執行這些轉變的復雜性。兩個特別復雜的問題是：

1、如果你想付款給某人，你將如何獲取付款信息？

2、如果用戶的資產存儲在不同的鏈上的不同位置，他們如何進行密鑰更改和社交恢復？

三個轉變與鏈上支付（和身份）之間的關系

我在 Scroll 上有一些幣，我想用它們买咖啡（如果"I"是指我，這篇文章的作者，那么"咖啡"當然是指"綠茶"）。你是賣給我咖啡的人，但你只能接收 Taiko 上的幣。怎么辦？

基本上有兩個解決方案：

1、接收錢包（可以是商家，也可以是普通人）要非常努力地支持每個 L2，並具有一些自動功能，可以異步合並資金。

2、收款人在地址旁邊提供他們的 L2，然後發送者的錢包通過某個跨 L2 橋接系統自動將資金路由到目標 L2。

當然，這些解決方案可以結合使用：收款人提供他們愿意接受的 L2 列表，然後發送者的錢包找出支付方式，這可能包括直接發送（如果他們很幸運）或通過跨 L2 橋接路徑發送。

但這只是一個關鍵挑战的例子，這三個轉變 引入的簡單操作开始需要比僅僅一個 20字節的地址更多的信息。

幸運的是，智能合約錢包的轉變對尋址系統來說並不是一個巨大的負擔，但在應用程序堆棧的其他部分仍然存在一些技術問題。錢包需要更新，以確保它們在交易中不僅發送 21000 Gas，而且更重要的是，確保接收方的錢包能夠跟蹤不僅來自 EOA 的 ETH 轉账，還有由智能合約代碼發送的 ETH。依賴地址所有權不可變的應用程序（例如，禁止智能合約以執行版稅的 NFT）將不得不尋找其他實現目標的方法。智能合約錢包還將使某些事情變得更容易，尤其是，如果有人只收到非 ETH ERC20代幣，他們將能夠使用 ERC-4337 付款代理來支付該代幣的 Gas 費用。

另一方面，隱私再次提出了一些我們尚未真正解決的重大挑战。最初的 Tornado Cash 沒有引入任何這些問題，因為它不支持內部轉账：用戶只能存入系統並從中提取資金。然而，一旦可以進行內部轉账，用戶將需要使用隱私系統的內部尋址方案。實際上，用戶的“支付信息”將需要包含以下內容：（i）某種“支付公鑰”，即收款方可用於支出的一個密鑰承諾，以及（ii）讓發送方發送加密信息，只有收款方能夠解密以幫助收款方發現付款的方式。

隱形地址協議依賴於 元地址 的概念，它的工作原理如下：元地址的一部分是發送方的盲化版本的花費密鑰，另一部分是發送方的加密密鑰（盡管最小的實現可以將這兩個密鑰設置為相同）。

基於加密和零知識簡潔非交互式證明（ZK-SNARKs）的抽象隱私地址方案的示意概覽

這裏的一個關鍵教訓是， 在一個注重隱私的生態系統中，用戶將同時擁有支付公鑰和加密公鑰，用戶的“支付信息”將不得不包含這兩個密鑰 。除了支付之外，還有其他很好的原因可以擴展到這個方向。例如，如果我們想要基於以太坊的加密電子郵件，用戶將需要公开提供某種加密密鑰。在“EOA 世界”中，我們可以重復使用帳戶密鑰，但在安全的智能合約錢包世界中，我們可能應該對此進行更明確的功能定義。這也有助於使基於以太坊的身份與非以太坊的分布式隱私生態系統更兼容，尤其是 PGP 密鑰。

三個轉變和密鑰恢復

在一個每個用戶擁有多個地址的世界中，實現密鑰更改和社交恢復的默認方法是讓用戶分別在每個地址上運行恢復過程。這可以通過單擊一次來完成：錢包可以包含執行恢復過程的軟件，同時在用戶的所有地址上執行。然而，即使有這樣的用戶體驗簡化，樸素的多地址恢復仍然存在三個問題：

1、 Gas 成本不可行 ：這個問題不言而喻。

2、 反事實地址 ：尚未發布智能合約的地址（實際上，這意味着您尚未從該帳戶發送資金的帳戶）。作為用戶，您可能在每個L2上都有無限多個事實上的地址：包括尚不存在的 L2 上的一個或多個地址，以及從隱形地址方案中產生的另一個無限集合。

3、 隱私 ：如果用戶故意擁有多個地址以避免將它們鏈接到一起，他們肯定不希望通過同時恢復它們來公开地將所有地址鏈接起來！

解決這些問題是困難的。幸運的是，有一個相當優雅的解決方案，性能也還不錯： 一種體系結構將驗證邏輯和資產持有分开 。

每個用戶都擁有一個密鑰存儲合約 ，它存在於一個位置（可以是主網或特定的 L2）。然後用戶在不同的 L2 上擁有地址，每個地址的驗證邏輯都是指向密鑰存儲合約的指針。從這些地址支出需要提供一個證明，該證明進入密鑰存儲合約，顯示當前的（或者更現實的是非常近期的）花費公鑰。

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

● 在 L2 內直接讀取 L1 狀態。 可以修改 L2 以使其能夠直接讀取 L1 狀態。如果密鑰存儲合約在 L1 上，這意味着 L2 內的合約可以無償訪問密鑰存儲合約。

● Merkle 分支。 Merkle 分支可以證明 L1 狀態到 L2，或 L2 狀態到 L1，或者可以將兩者合並以證明一個 L2 的部分狀態到另一個 L2。Merkle 證明的主要弱點是由於證明長度而產生的高 Gas 費用：一個證明可能需要 5KB，盡管由於 Verkle 樹的原因，將來這將減少到<1KB。

● ZK-SNARKs。 可以通過使用 Merkle 分支的 ZK-SNARK 的方法來減少數據成本，而不是使用分支本身。可以構建離鏈聚合技術（例如基於 EIP-4337），以使一個單一的 ZK-SNARK 驗證一個區塊中的所有跨鏈狀態證明。

● KZG 承諾。 無論是 L2 還是構建在其之上的方案，都可以引入順序尋址系統，允許證明該系統內部狀態的證明僅為 48 字節長。與 ZK-SNARKs 一樣，多證明方案可以將所有這些證明合並為每個塊的單個證明。

如果我們想要避免每個交易都生成一個證明，我們可以實現一個更輕的方案，只需要一個跨 L2 證明來恢復。從帳戶支出取決於一個花費密鑰，其對應的公鑰存儲在該帳戶內部，但恢復需要一筆交易，將當前的花費公鑰復制到密鑰存儲中。即使您的舊密鑰丟失，計數事實上的地址中的資金也是安全的：將事實上的地址“激活”以將其轉換為工作合約需要進行跨 L2 證明以復制當前的花費公鑰。Safe 論壇上的這個主題描述了類似體系結構的工作原理。

為了在這樣的方案中添加隱私 ，我們只需要對指針進行加密，並在 ZK-SNARKs 內部進行所有的證明：

通過更多的工作（例如以這項工作為起點），我們還可以剝離 ZK-SNARKs 的大部分復雜性，構建一個更簡化的基於 KZG 的方案。

這些方案可能會變得復雜。好的一面是它們之間存在許多潛在的協同作用。例如，“密鑰存儲合約”的概念也可以解決前一節中提到的“地址”的挑战：如果我們希望用戶擁有持久的地址，不會在用戶更新密鑰時更改，我們可以將隱形元地址、加密密鑰和其他信息放入密鑰存儲合約中，並使用密鑰存儲合約的地址作為用戶的“地址”。

許多輔助基礎設施需要更新

使用 ENS 是昂貴的。今天，在 2023 年 6 月，情況還不算太糟糕：交易費用很高，但與 ENS 域名費用相比仍然可以接受。注冊 zuzalu.eth 花費了大約 27 美元，其中 11 美元是交易費用。但如果市場再次繁榮，費用將飆升。即使 ETH 價格不上漲，Gas 費用回升至 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，訪問某個 subdomain.ecc.eth 將自動涉及查找和驗證一個證明（例如 Merkle 分支），證明該特定子域名存儲在實際存儲該子域名的 L2 中。

實際獲取這些證明涉及訪問存儲在合約中的 URL 列表，盡管這確實感覺像是中心化，但我認為它實際上並不是：這是一種 1 對 N 的信任模型（無效的證明會被 CCIP 合約回調函數中的驗證邏輯捕獲，只要有一個 URL 返回一個有效的證明，就可以）。URL 列表可以包含幾十個 URL。

ENS CCIP 的努力是一個成功的故事，並且應該被視為這樣一種跡象：我們實際上可以實現我們所需的這種根本性改革。 但還需要進行許多應用層改革。以下是一些例子：

●許多dapp依賴用戶提供 離鏈籤名 。對於外部擁有的帳戶（EOAs），這很容易。ERC-1271 提供了一種標准化的方法來實現智能合約錢包的離鏈籤名。然而，許多 dapp 仍然不支持 ERC-1271，它們將需要進行更新。

● 使用“這是 EOA 嗎？”來區分用戶和合約的 dapp（例如，防止轉账或強制版稅的 NFT）將會出現問題。 總的來說，我建議不要試圖在這裏找到純技術解決方案；確定特定加密控制的轉移是否是有益所有權轉移是一個很困難的問題，可能無法在沒有一些離鏈社區驅動機制的情況下解決。最有可能的是，應用將不再依賴於阻止轉移等技術手段，而是更多地依賴於諸如 Harberger 稅之類的技術。

● 錢包如何與花費和加密密鑰交互將需要改進。 目前，錢包經常使用確定性籤名來生成應用程序特定的密鑰：使用 EOA 的私鑰對標准 nonce（例如應用程序名稱的哈希）進行籤名會生成一個確定性值，而無法在沒有私鑰的情況下生成，因此從純技術上講是安全的。然而，這些技術對於錢包來說是“不透明”的，阻止了錢包實施用戶界面級別的安全檢查。在一個更成熟的生態系統中，籤名、加密和相關功能將需要由錢包更明確地處理。

● 輕客戶端（例如 Helios）將需要驗證 L2，而不僅僅是 L1。 今天，輕客戶端主要關注檢查 L1 頭部的有效性（使用輕客戶端同步協議），並驗證以 L1 頭部為根的 L1 狀態和交易的 Merkle 分支。明天，它們還將需要驗證以 L1 中存儲的狀態根為根的 L2 狀態的證明（更先進的版本實際上將查看 L2 的預確認）。

錢包將需要保護資產和數據

今天，錢包的任務是保護資產。一切都存儲在鏈上，錢包需要保護的唯一東西就是當前保護這些資產的私鑰。如果更改密鑰，您可以在第二天將之前的私鑰安全地發布在互聯網上。然而，在 ZK 世界中，情況就不再如此：錢包不僅僅是保護身份驗證憑據，它還保存着您的數據。

我們在 Zuzalu 上看到了這種世界的最初跡象，Zuzalu 使用了基於 ZK-SNARK 的身份系統 Zupass。用戶擁有一個私鑰，用於在系統中進行身份驗證，該私鑰可以用於生成基本證明，例如“證明我是一個 Zuzalu 居民，而不泄露我的具體身份”。但是，Zupass 系統還开始在此之上構建其他應用，最重要的是 stamp（ Zupass 版本的 POAP）。

我的許多Zupassstamp之一，確認我是TeamCat的驕傲成員

stamp 相對於 POAP 的主要特點是隱私性：您在本地保存數據，只有在希望將其提供給其他人時，才會對 stamp （或 stamp 計算中的一些計算）進行 ZK 證明。但這也帶來了一定的風險：如果您丟失了這些信息，就會失去您的 stamp 。

當然，持有數據的問題可以減少到持有單個加密密鑰的問題：某個第三方（甚至是鏈）可以持有對數據的加密副本。這具有方便的優勢，即您採取的操作不會更改加密密鑰，因此不需要與保護您的加密密鑰的系統進行任何交互。但即使如此， 如果您丟失了加密密鑰，您將失去所有內容 。 而且，反過來， 如果有人看到了您的加密密鑰，他們將看到所有加密給該密鑰的內容。

Zupass 的實際解決方案是鼓勵人們將密鑰存儲在多個設備上（例如筆記本電腦和手機），因為他們在同一時間失去所有設備的幾率是微小的。我們可以進一步採用通過祕密共享將密鑰存儲在多個保護者之間的方案。

這種通過 MPC 進行的社交恢復不足以成為錢包的解決方案，因為它意味着不僅當前保護者，而且先前的保護者都可能合謀竊取您的資產，這是一個無法接受的高風險。但是隱私泄漏通常比完全喪失資產的風險較低，一個對隱私需求較高的用例可以始終接受更高的損失風險，即不備份與這些隱私需求相關的密鑰。

為了避免讓用戶陷入一個繁瑣的多重恢復路徑系統中，支持社交恢復的錢包可能需要同時管理資產恢復和加密密鑰恢復。

回到身份問題

這些變化的一個共同线索是“地址”這個概念，即您在鏈上用來代表“您”的加密標識符，將會發生根本性的變化。 關於“如何與我互動”的指令將不再僅僅是一個 ETH 地址；在某種形式上，它們將是多個地址、多個 L2 上的地址、隱形元地址、加密密鑰和其他數據的組合。

實現這一點的一種方法是將 ENS 作為您的身份：您的 ENS 記錄可以包含所有這些信息，如果您發送給某人 bob.eth（或 bob.ecc.eth 等），他們可以查找並查看與您進行支付和互動的所有信息，包括更復雜的跨域和隱私保護方式。

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

● 它將太多的事物與您的名字綁定在一起。 您的名字並不是您本人，您的名字只是您的衆多屬性之一。應該可以更改您的名字而不需要轉移整個身份配置文件並更新許多應用程序中的記錄。

● 您無法擁有可信的假名。 任何區塊鏈的一個關鍵用戶體驗功能是能夠將幣發送給尚未與該鏈進行交互的人。沒有這樣的功能，就會陷入進退兩難的境地：與鏈進行交互需要支付交易費，而支付交易費又需要...已經擁有幣。ETH 地址，包括帶有 CREATE2 的智能合約地址，具備這種功能。ENS 名稱沒有，因為如果兩個 Bob 都在鏈下決定他們是 bob.ecc.eth ，就沒有辦法選擇誰將獲得該名稱。

一種可能的解決方案是在先前在本文中提到的體系結構中將更多內容放入 keystore合約 。keystore 合約可以包含關於您以及如何與您互動的各種信息（並且使用 CCIP，其中一些信息可以在鏈下），用戶將使用其 keystore 合約作為主要標識符。但是他們實際收到的資產將存儲在各種不同的地方。Keystore 合約不與名稱綁定，並且具有友好的反事實性：您可以生成一個地址，該地址可以被證明只能由具有某些固定初始參數的 keystore 合約初始化。

另一類解決方案涉及徹底放棄用戶可見的地址概念，類似於比特幣支付協議。一個想法是更多地依賴發送方和接收方之間的直接通信渠道；例如，發送方可以發送一個認領鏈接（可以是顯式的 URL 或二維碼），接收方可以使用該鏈接以自己希望的方式接受支付。

無論發送方還是接收方先行動，更多地依賴錢包在實時生成最新的付款信息方面的可能性可以減少摩擦。然而，直接溝通的假設在實踐中確實是一個棘手的問題，因此我們可能最終會看到不同技術的組合。

在所有這些設計中，保持分散化並讓用戶能夠輕松訪問其當前資產和為他們發布的消息的最新視圖至關重要。這些視圖應該依賴於开放工具，而不是專有解決方案。努力避免支付基礎架構的更大復雜性變成一個不透明的“抽象之塔”，使开發者很難理解正在發生的事情並將其適應新的環境，這是一項艱巨的任務。盡管存在挑战，但為普通用戶實現可擴展性、錢包安全性和隱私對以太坊的未來至關重要。這不僅關乎技術可行性，還關乎普通用戶的實際可訪問性。我們需要努力迎接這個挑战。