原文作者：以太坊創始人 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 上接收幣。 要做什么？

基本上有兩種解決方案：

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

收款人提供他們的 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 密鑰。

三個過渡和密鑰恢復

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

Gas 成本不切實際：這個是不言自明的。

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

隱私：如果用戶有意擁有多個地址以避免將它們相互鏈接，他們當然不希望通過同時或大約同時恢復它們來公開鏈接所有地址！

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

每個用戶都有一個密鑰庫合約，它存在于一個位置（可以是主網或特定的 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），而發送者和接收者之間直接通信的假設在實踐中是一個非常棘手的假設，因此我們最終可能會看到不同技術的組合。

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