Vitalik Buterin：以太坊的三次技術過渡

原文作者：以太坊創始人Vitalik Buterin

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

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

• L2 擴展過渡——每個人都轉向rollups
• 錢包安全過渡——每個人都轉向智能合約錢包
• 隱私過渡——確保隱私保護資金轉移可用，並確保所有其他正在開發的小工具（社會恢復、身份、聲譽）都是隱私保護的

生態系統過渡三角。

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

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

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

由於上述原因，這三個轉變至關重要。但它們也具有挑戰性，因為要妥善解決這些問題需要密切協調。需要改進的不僅僅是協議的功能； 在某些情況下，我們與以太坊交互的方式需要從根本上改變，需要對應用程序和錢包進行深刻的改變。

這三個過渡將從根本上重塑用戶和地址之間的關係

在L2 擴展世界中，用戶將存在於許多L2 上。您是依賴Optimism 的ExampleDAO 的成員嗎？那麼您就有了一個Optimism 的帳戶！您是否在ZkSync 上的穩定幣系統中持有CDP？那麼你在ZkSync 上就有了一個帳戶！你有沒有試過kakarot 上的一些應用程序？那麼您在Kakarot 上就有了一個帳戶！一個用戶只有一個地址的日子將一去不復返了。

*根據我的Brave Wallet 觀點，我在四個地方都有ETH。是的，Arbitrum 和Arbitrum Nova 是不同的。別擔心，隨著時間的推移它會變得更加混亂！ *

智能合約錢包增加了複雜性，使在L1 和各種L2 中擁有相同地址變得更加困難。如今，大多數用戶都在使用外部擁有的賬戶，其地址實際上是用於驗證簽名的公鑰的哈希值——因此L1 和L2 之間沒有任何變化。然而，對於智能合約錢包，保留一個地址變得更加困難。儘管已經做了很多工作來嘗試使地址成為可以跨網絡等效的代碼哈希，最著名的是CREATE2 和ERC-2470 單例工廠，但很難使這項工作完美無缺。一些L2（例如“類型4 ZK-EVM”）並不完全等同於EVM，通常使用Solidity 或中間程序集來代替，以防止哈希等效。即使你可以擁有哈希等效，錢包通過密鑰更改改變所有權的可能性也會產生其他不直觀的後果。

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

正如我們所見，這三種過渡中的每一種都以不同的方式削弱了“一個用戶~=一個地址”的心理模型，其中一些影響反饋到執行轉變的複雜性中。兩個特殊的複雜點是：

如果您想付錢給某人，您將如何獲得有關如何付錢給他們的信息？

如果用戶有很多資產跨鏈存儲在不同的地方，他們如何進行密鑰更改和社交恢復？

三個過渡和鏈上支付（和身份）

我在Scroll上有幣，我想花錢買咖啡（如果“我”是字面意思，指的是本文作者我，那麼“咖啡”當然是“綠茶”的轉喻）。你在賣咖啡給我，但你只能在Taiko 上接收幣。要做什麼？

基本上有兩種解決方案：

1. 接收錢包（可以是商家，也可以是普通個人）非常努力地支持每個L2，並具有一些用於異步整合資金的自動化功能。
2. 收款人提供他們的L2 和他們的地址，發件人的錢包通過一些跨L2 橋接系統自動將資金路由到目的地L2。

當然，這些解決方案可以結合使用：收件人提供他們願意接受的L2 列表，發件人的錢包計算出付款，如果他們幸運的話，這可能涉及直接發送，或者跨L2 橋接路徑。

但這只是這三個過渡帶來的關鍵挑戰的一個例子：像向某人付款這樣的簡單操作開始需要更多的信息，而不僅僅是一個20 字節的地址。

幸運的是，向智能合約錢包的過渡不會對尋址系統造成太大負擔，但應用程序堆棧的其他部分仍有一些技術問題需要解決。錢包將需要更新以確保它們不會隨著交易僅發送21000 gas，並且確保錢包的付款接收端不僅跟踪來自EOA 的ETH 轉賬，而且還跟踪ETH 更為重要由智能合約代碼發送。依賴於地址所有權不可變假設的應用程序（例如，禁止智能合約以強制使用費的NFT）將不得不尋找其他方法來實現其目標。智能合約錢包也會讓一些事情變得更容易——值得注意的是，如果某人只收到非ETH ERC20 代幣，他們將能夠使用ERC-4337 paymasters 使用該代幣支付gas。

另一方面，隱私再次構成了我們尚未真正應對的重大挑戰。最初的Tornado Cash 沒有引入任何這些問題，因為它不支持內部轉賬：用戶只能存入系統並從系統中取出。但是，一旦可以進行內部傳輸，用戶將需要使用隱私系統的內部尋址方案。在實踐中，用戶的“支付信息”需要包含（i）某種“消費公鑰”，即對接收者可以用來消費的秘密的承諾，以及（ii）發送者發送加密貨幣的某種方式只有收款人可以解密的信息，以幫助收款人發現付款。

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

基於加密和ZK-SNARK 的抽象隱身地址方案的示意圖。

這裡的一個關鍵教訓是，在隱私友好的生態系統中，用戶將同時擁有消費公鑰和加密公鑰，並且用戶的“支付信息”必須包括這兩個密鑰。除了支付之外，還有充分的理由朝這個方向擴張。例如，如果我們想要基於以太坊的加密電子郵件，用戶將需要公開提供某種加密密鑰。在“EOA 世界”中，我們可以為此重複使用帳戶密鑰，但在安全的智能合約錢包世界中，我們可能應該為此提供更明確的功能。這也有助於使基於以太坊的身份與非以太坊去中心化隱私生態系統更加兼容，尤其是PGP 密鑰。

三個過渡和密鑰恢復

在每個用戶有多個地址的世界中實現關鍵更改和社會恢復的默認方法是簡單地讓用戶分別在每個地址上運行恢復過程。這可以一鍵完成：錢包可以包含軟件，可以同時對用戶的所有地址執行恢復程序。然而，即使有了這樣的用戶體驗簡化，簡單的多地址恢復也存在三個問題：

1. Gas 成本不切實際：這個是不言自明的。
2. 反事實地址：智能合約尚未發布的地址（實際上，這意味著您尚未從中發送資金的帳戶）。作為用戶，您可能擁有無限數量的反事實地址：每個L2 上都有一個或多個地址，包括尚不存在的L2，以及由隱形地址方案產生的另一組無限反事實地址。
3. 隱私：如果用戶有意擁有多個地址以避免將它們相互鏈接，他們當然不希望通過同時或大約同時恢復它們來公開鏈接所有地址！

解決這些問題很難。幸運的是，有一個性能相當不錯的優雅解決方案：將驗證邏輯和資產持有分開的架構。

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

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

• L2裡面直接只讀L1訪問。可以修改L2 以使其能夠直接讀取L1 狀態。如果密鑰庫合約在L1 上，這意味著L2 內的合約可以“免費”訪問密鑰庫
• 默克爾分支。 Merkle 分支可以將L1 狀態證明到L2，或將L2 狀態證明到L1，或者您可以將兩者結合起來以將一個L2 的部分狀態證明到另一個L2。 Merkle 證明的主要弱點是由於證明長度導致的高gas 成本：一個證明可能需要5 kB，但由於Verkle 樹，這將在未來減少到< 1 kB。
• ZK-SNARKs。您可以通過使用Merkle 分支的ZK-SNARK 而不是分支本身來降低數據成本。可以構建鏈下聚合技術（例如，在EIP-4337 之上）讓一個ZK-SNARK 驗證一個區塊中的所有跨鏈狀態證明。
• KZG 承諾。 L2 或建立在它們之上的方案可以引入順序尋址系統，允許該系統內的狀態證明只有48 字節長。與ZK-SNARKs 一樣，多重證明方案可以將所有這些證明合併為每個塊的單個證明。

如果我們想避免為每筆交易製作一個證明，我們可以實施一個更輕的方案，只需要一個跨L2 證明來恢復。從一個帳戶中支出將取決於一個支出密鑰，其相應的公鑰存儲在該帳戶中，但恢復將需要一個事務來複製密鑰庫中的當前支出公鑰。即使您的舊密鑰不安全，反事實地址中的資金也是安全的：“激活”反事實地址以將其轉變為工作合約需要進行交叉L2 證明以復制當前的spending_pubkey。 Safe 論壇上的這個帖子描述了類似架構的工作原理。

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

隨著更多的工作（例如，以這項工作為起點），我們還可以去除ZK-SNARK 的大部分複雜性，並製作一個更簡單的基於KZG 的方案。

這些方案可能會變得複雜。從好的方面來說，它們之間有許多潛在的協同作用。例如，“keystore contracts”的概念也可以解決上一節中提到的“地址”挑戰：如果我們希望用戶擁有永久地址，不會在用戶每次更新密鑰時都改變，我們可以將隱蔽的元地址、加密密鑰等信息放入密鑰庫合約中，並將密鑰庫合約的地址作為用戶的“地址”。

許多二級基礎設施需要升級

使用ENS 很昂貴。今天，即2023 年6 月，情況還算不錯：交易費用很高，但仍可與ENS 域名費用相媲美。註冊zuzalu.eth 花了我大約27 美元，其中11 美元是交易費。但如果我們有另一個牛市，費用將會飆升。即使沒有ETH 價格上漲，gas 費用回到200 gwei 也會將域名註冊的tx 費用提高到104 美元。因此，如果我們希望人們實際使用ENS，特別是對於用戶要求幾乎免費註冊的去中心化社交媒體等用例（並且ENS 域費用不是問題，因為這些平台為其用戶提供子域），我們需要ENS 在L2 上工作。

幸運的是，ENS 團隊站出來了，ENS on L2 正在發生！ ERC-3668（又名“CCIP 標準”）與ENSIP-10 一起，提供了一種讓任何L2 上的ENS 子域自動可驗證的方法。 CCIP 標準要求建立一個智能合約，描述一種驗證L2 數據證明的方法，並且可以將域（例如Optinames 使用ecc.eth）置於此類合約的控制之下。一旦CCIP 合約控制了L1 上的ecc.eth，訪問某些subdomain.ecc.eth 將自動涉及查找和驗證L2 中實際存儲該特定子域的狀態證明（例如Merkle 分支）。

實際上獲取證明涉及到存儲在合約中的URL 列表，這誠然感覺像中心化，但我認為它實際上不是：它是一個1-of-N 信任模型（無效的證明被驗證邏輯捕獲在CCIP 合約的回調函數中，只要其中一個URL 返回有效證明，就可以了）。 URL 列表可能包含數十個。

ENS CCIP 的努力是一個成功的故事，它應該被視為一個標誌，表明我們需要的那種激進改革實際上是可能的。但是還有很多應用層改革需要完成。幾個例子：

• 許多dapp 依賴於用戶提供鏈下簽名。使用外部擁有賬戶(EOA)，這很容易。 ERC-1271 為智能合約錢包提供了一種標準化的方式來做到這一點。但是，很多dapp 仍然不支持ERC-1271； 他們將需要。
• 使用“這是EOA 嗎？”的Dapps 區分用戶和合同（例如，防止轉讓或強制使用費）將會破裂。總的來說，我建議不要在這裡尋找純技術解決方案； 弄清楚特定的密碼控制轉移是否是受益所有權的轉移是一個難題，如果不解決一些鏈下社區驅動的機制，可能無法解決。最有可能的是，應用程序將不得不減少對防止轉移的依賴，而更多地依賴哈伯格稅等技術。
• 必須改進錢包與支出和加密密鑰的交互方式。目前，錢包通常使用確定性簽名來生成特定於應用程序的密鑰：使用EOA 的私鑰簽署標準隨機數（例如應用程序名稱的哈希值）會生成一個沒有私鑰無法生成的確定性值，因此它是安全的在純技術意義上。然而，這些技術對錢包來說是“不透明的”，阻止了錢包實現用戶界面級別的安全檢查。在更成熟的生態系統中，簽名、加密和相關功能將必須由錢包更明確地處理。
• 輕客戶端（例如Helios）將必須驗證L2 而不僅僅是L1。今天，輕客戶端專注於檢查L1 header 的有效性（使用輕客戶端同步協議），並驗證L1 狀態的Merkle 分支和植根於L1 header的交易。明天，他們還需要驗證L2 狀態的證明，該證明植根於L1 中存儲的狀態根（更高級的版本實際上會查看L2 預確認）。

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

今天，錢包從事保護資產的業務。一切都在鏈上，錢包唯一需要保護的是當前保護這些資產的私鑰。如果您更改密鑰，您可以在第二天安全地在互聯網上發布您以前的私鑰。然而，在ZK 世界中，這不再是事實：錢包不僅保護身份驗證憑證，它還保存著你的數據。

我們通過Zupass 看到了這樣一個世界的最初跡象，Zupass 是Zuzalu 使用的基於ZK-SNARK 的身份系統。用戶有一個用於向系統進行身份驗證的私鑰，可以用來製作基本證明，例如“證明我是Zuzalu 居民，但無需透露是哪一個”。但Zupass 系統也開始在其上構建其他應用程序，最著名的是郵票(stamp）（Zupass 的POAP 版本）。

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

與POAP 相比，stamp 提供的關鍵特性是stamp 是私有的：您在本地保存數據，如果您希望某人擁有關於您的信息，您只需向某人證明一個stamp（或對stamp 的一些計算）。但這會增加風險：如果您丟失了該信息，您就會丟失郵票。

當然，持有數據的問題可以簡化為持有單個加密密鑰的問題：某些第三方（甚至鏈）可以持有數據的加密副本。這有一個方便的優點，即您採取的操作不會更改加密密鑰，因此不需要與保存您的加密密鑰安全的系統進行任何交互。但即便如此，如果您丟失了加密密鑰，您將失去一切。另一方面，如果有人看到您的加密密鑰，他們就會看到用該密鑰加密的所有內容。

Zupass 的實際解決方案是鼓勵人們將密鑰存儲在多個設備（例如筆記本電腦和手機）上，因為他們同時無法訪問所有設備的可能性很小。我們可以更進一步，使用秘密共享來存儲密鑰，在多個監護人之間分配。

這種通過MPC 進行的社會恢復對於錢包來說並不是一個充分的解決方案，因為這意味著不僅當前的監護人而且以前的監護人都可能串通竊取你的資產，這是一個不可接受的高風險。但是隱私洩露的風險通常低於總資產損失風險，並且具有高隱私要求用例的人總是可以通過不備份與這些隱私要求高的操作相關的密鑰來接受更高的丟失風險。

為了避免用戶被多條恢復路徑的拜占庭系統淹沒，支持社交恢復的錢包可能需要同時管理資產恢復和加密密鑰恢復。

回到身份

這些變化的共同點之一是“地址”的概念，即您用來在鏈上代表“您”的加密標識符，必須從根本上改變。 “如何與我互動的說明”將不再只是一個ETH 地址； 它們必須以某種形式是多個L2 上的多個地址、隱形元地址、加密密鑰和其他數據的某種組合。

一種方法是讓ENS 成為你的身份：你的ENS 記錄可以只包含所有這些信息，如果你發送某人bob.eth（或bob.ecc.eth，或......），他們可以查找並查看有關如何付款和與您互動的所有信息，包括更複雜的跨域和隱私保護方式。

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

• 它把太多的東西和你的域名聯繫在一起。你的域名不是你，你的域名是你的許多屬性之一。應該可以更改您的域名，而無需移動您的整個身份資料並更新許多應用程序中的一大堆記錄。
• 你不能有不受信任的反事實玉米。任何區塊鏈的一個關鍵UX 功能是能夠將幣發送給尚未與鏈交互的人。如果沒有這樣的功能，就會有一個catch- 22：與鏈交互需要支付交易費用，這需要……已經有幣。 ETH 地址，包括帶有CREATE2 的智能合約地址，都具有此功能。 ENS 域名不會，因為如果兩個Bob 都決定在鏈下他們是bob.ecc.eth，無法選擇其中哪一個獲得域名。

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

另一類解決方案與比特幣支付協議類似，完全放棄面向用戶地址的概念。一種想法是更多地依賴發件人和收件人之間的直接溝通渠道； 例如，發件人可以發送一個索賠鏈接（作為明確的URL 或QR 碼），收件人可以使用該鏈接按照他們的意願接受付款。

不管是發送者還是接收者先行動，更多地依賴錢包直接實時生成最新的支付信息可以減少摩擦。也就是說，持久標識符很方便（尤其是使用ENS），而發送者和接收者之間直接通信的假設在實踐中是一個非常棘手的假設，因此我們最終可能會看到不同技術的組合。

在所有這些設計中，讓事物既分散又易於用戶理解是最重要的。我們需要確保用戶可以輕鬆訪問最新視圖，了解他們當前的資產是什麼，以及為他們發布了哪些消息。這些觀點應該依賴於開放工具，而不是專有解決方案。要避免更加複雜的支付基礎設施變成一個不透明的“抽象塔”，開發人員很難理解正在發生的事情並使其適應新的環境，這需要付出艱苦的努力。儘管面臨挑戰，但為普通用戶實現可擴展性、錢包安全和隱私對於以太坊的未來至關重要。這不僅關乎技術可行性，還關乎普通用戶的實際可訪問性。我們需要挺身而出迎接這一挑戰。