這不僅關乎技術可行性,還關乎是否能夠為普通使用者降低使用門檻。 我們需要挺身而出迎接這一挑戰。

原文:The Three Transitions(vitalik.eth)

作者:Vitalik Buterin

編譯:Sullivan,ZONFF Research

原用標題: Vitalik Buterin:乙太坊未來發展的三個轉變方向「編譯」| ZONFF Research

封面: Photo by Shubham’s Web3 on Unsplash

乙太坊從一項早期的實驗性技術如今轉變為成熟的技術堆疊,為了使其能夠真正為普通用戶帶來更具開放性、全球化和無需許可的使用體驗,後續還需要大致同時經歷三個主要的技術轉變:

01 Layer2(L2)擴展轉變:使用者將轉向 Rollups 技術;

02 錢包安全轉變:使用者將轉向智能合約錢包;

03 隱私轉變:確保資金可以在保障隱私情況下進行轉移,並確保所有其他正在開發的工具(如社交恢復「譯者注:Social Recovery,具體可參考 Why we need wide adoption of social recovery wallets https://vitalik.ca/general/2021/01/11/recovery.html」、身份、聲譽)都是受隱私保護的;

圖片
生態系統發展的三個方向,三者均具有必要性

如果沒有 L2 擴展轉變,乙太坊就會失敗,因為每筆交易的成本為 3.75 美元(如果我們有另一次牛市則可能為 82.48 美元)。 並且每個針對大眾市場的產品都將不可避免地會輕視鏈上轉而採用中心化交易的變通方法,從而降低交易成本。

如果沒有錢包安全轉變,乙太坊就會失敗,因為使用者不願意在鏈上存儲他們的資金(和非金融資產),並且每個人都將轉向中心化交易所。

如果沒有隱私轉變,乙太坊就會失敗,因為所有交易(和 POAP「譯者注:“Proof-Of-Attendance Protocol [出席證明協定]」」等)都可公開供任何人查看,這對許多用戶來說是一種過高的隱私犧牲,並且使用者都將轉向至少在某種程度上保護用戶數據隱私的中心化解決方案。

基于上述原因,这三个技术转变至关重要。但由于要妥善解决这些问题需要密切协调所以也很具有挑战性。需要改进的不仅仅是协议的功能,而是在某些情况下,我们与以太坊交互的方式需要从根本上改变,需要对应用程序和钱包进行深刻的改变。

I.  这三个转变将从根本上重塑用户和地址之间的关系

在未来的 L2 扩展世界中,用户将存在于许多 L2 上。如果你是依赖于 Optimism 的 ExampleDAO 成员,那么你就会有一个 Optimism 帐户。如果你在 ZkSync 上的稳定币系统中持有 CDP,那么你就会有一个 ZkSync 帐户。如果你有尝试过 Kakarot 上的一些应用程序,那么你就会有一个 Kakarot 帐户。一个用户持有多个账户地址将在未来成为常态。

圖片
根據我的 Brave Wallet 觀點,我在四個地方都有 ETH。 Arbitrum 和 Arbitrum Nova 是不同的,隨著時間的推移它會變得更加複雜

智慧合約錢包增加了更多的複雜性,使得在 L1 和各種 L2 中擁有相同位址變得更加困難。  如今,大多數使用者都在使用外部擁有者帳戶(EOA)「譯者注:即我們平時接觸到的,用戶通過私鑰來直接控制的帳戶」,其地址實際上是用於驗證簽名的公鑰哈希值 — 因此 L1 和 L2 之間沒有任何變化。 然而,對於智能合約錢包,保留相同位址變得更加困難。 儘管已經做了很多工作來嘗試使位址成為可以跨網路等效的哈希代碼,最著名的是 CREATE2 和 ERC-2470 單例工廠,但很難使這項工作完美無缺。 一些 L2s(例如 “TYPE 4 ZK-EVM”)並不完全是 EVM 相容,通常使用 Solidity 或中間元件代替,使得哈希值無法完全相等。 即使你可以擁有相等的哈希值,密鑰變更導致錢包擁有權變更的可能性也會產生其他反直覺的結果。

對於隱私的需求會促使每個用戶擁有更多位址,甚至可能會改變我們使用的位址類型。  如果隱形位址「譯者注:Stealth Address,具體可參考 An incomplete guide to stealth addresses https://vitalik.ca/general/2023/01/20/stealth.html」提議得到廣泛使用,那麼可能每筆交易都會存在一個位址, 而不是目前的每個使用者只有幾個位址或者每個 L2 一個位址。 其他的隱私方案,甚至是現有的方案例如 Tornado Cash,用通過不同方法改變了資產存儲的方式:許多使用者的資金存儲在同一個智慧合約中(因此在同一個位址)。 要向特定使用者發送資金,使用者將需要依賴隱私方案自身的內部尋址系統。

正如我們所見,這三種轉變中的每一種都以不同的方式削弱了 “一個使用者約等於一個位址” 的心理模型,並且其中一些影響反而使得上述轉變的執行層面變得更加複雜。 其中兩個特殊的複雜點是:

  • 如果你想付錢給某人,有關如何付錢給他們的資訊如何獲得?
  • 如果使用者有很多資產存儲在不同的鏈當中,他們如何進行密鑰更改和社交恢復?

II. 三個轉變與鏈上支付(身份)

假定我在 Scroll 上有代幣,我想花錢買咖啡。 你在賣咖啡給我,但你只能在 Taiko 上接收代幣。 該做什麼?

基本上有兩種解決方案:

  • 接收錢包(可以是商家,也可以是普通個人)非常努力地支援每個 L2,並具有一些可以整合不同種資金的自動化功能;
  • 收款人提供他們的 L2 和他們的地址,寄件人的錢包通過一些跨 L2 橋自動將資金轉移到目的地錢包位址;

當然,這些解決方案可以結合使用:收件者提供他們可以接受的 L2 列表,發件者的錢包在進行付款時既可能可以同鏈直接發送支付,也可能可以跨 L2 橋進行跨鏈支付。

但這裏引發了三個轉變所帶來的更加重要的一個挑戰:向某人付款的簡單操作開始需要比 20 位元組位址更多的資訊。

幸運的是,向智慧合約錢包的轉變不會對尋址系統造成太大負擔,但應用程式堆疊的其他部分仍有一些技術問題需要解決。 錢包將需要升級以確保它們不會隨著交易而「僅發送 21000 gas」費用,並且更為重要的是確保錢包的接收端不僅能夠追蹤來自 EOA 的 ETH 轉帳,而且還能追蹤由智慧合約代碼發送的 ETH 轉帳。 依賴於位址擁有權不可變假設的應用程式(例如,禁止智慧合約以強制收取使用費的 NFT)將不得不尋找其他方法來實現其目標。 智能合約錢包也會讓一些事情變得更容易 — 特別是,如果有人只收到非 ETH ERC20 的代幣,他們將能夠通過 ERC-4337 Paymasters 使用該代幣支付 gas。

另一方面,隐私再次构成了我们尚未真正应对的重大挑战。最初的 Tornado Cash 没有这些问题是因为它不支持内部转账:用户只能存入系统并从系统中取出。但是,一旦可以进行内部转账,用户将需要使用含有隐私系统的内部寻址方案。在实践中,用户的 “支付信息” 需要包含 (i) 某种 “支付公钥”,即对接收者可以用来支付的秘密承诺,以及 (ii) 发送者通过信息加密使得发送的代币只有收款人可以解密,以帮助收款人发现付款信息。

隐形地址协议依赖于元地址(Meta-Addresses)的概念,它的工作方式是:元地址的一部分是发送者支出密钥的隐藏版本,另一部分是发送者的加密密钥(尽管通过很小的程序可以将两个密钥设置为相同)。

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

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

III. 三個轉變和金鑰恢復

在每個使用者有多個位址的世界中實現金鑰更改和社交恢復的預設方法是簡單地讓使用者分別在每個位址上進行密鑰恢復。 上述操作可以一鍵完成:錢包可以通過軟體同時對使用者的所有位址執行恢復程式。 然而,即使有了這樣的用戶體驗簡化,簡單的多地址恢復也存在三個問題:

  • Gas 費成本過高:這個是不言自明的;
  • 反事實位址(Counterfactual Addresses):智慧合約尚未發佈的位址(在實踐中這意味著尚未從中發送資金出去過的帳戶)。 作為使用者,你可能擁有無限數量的反事實位址:每個 L2 上都有一個或多個位址,包括尚不存在的 L2,以及由隱形位址方案產生的另一組無限反事實位址;
  • 隱私:如果使用者故意擁有多個位址並且避免將它們相互鏈接,他們當然不希望在同時恢復上述地址的過程中公開這些地址的關聯關係;

解決這些問題很難。 幸運的是,有一個表現相當不錯的優雅解決方案:將驗證邏輯和資產持有分離的架構。

圖片

每個使用者都有一個密鑰庫合約(Keystore Contracts),它存在於一個位置(可以是主網或特定的 L2)。 然後,使用者在不同的 L2 上擁有位址,其中每個地址的驗證邏輯都是指向密鑰庫合約的 Pointer。 來自這些位址的支出都需要出示當前(或者更貼切地說,最近)的支出公鑰從而進入金鑰庫合約進行證明。

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

  • L2 內部直接對於 L1 的唯讀訪問。 可以修改 L2 以使其能夠直接讀取 L1 狀態。 如果密鑰庫合約在 L1 上,這意味著 L2 內的合約可以「免費」訪問密鑰庫;
  • Merkle 分支(Merkle Branches)。 Merkle 分支可以將 L1 狀態證明到 L2,或將 L2 狀態證明到 L1,或者你可以將兩者結合起來以將一個 L2 的部分狀態證明到另一個 L2。 Merkle 證明的主要弱點是由於證明長度導致的高 gas 成本:一個證明可能需要 5 KB。 不過這點在未來基於 Vercle Tree 可以將成本減少到小於 1 KB;
  • ZK-SNARKs,你可以通過使用 Merkle 分支的 ZK-SNARK 而不是分支本身來降低數據成本。 可以構建鏈下聚合技術(例如,在 EIP-4337 之上)讓一個 ZK-SNARK 驗證一個區塊中的所有跨鏈狀態證明;
  • KZG 承諾(譯者注:Kate-Zaverucha-Goldberg(KZG)polynomial commitment scheme,具體可參考 KZG polynomial commitments https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html)。 L2 或建立在它們之上的方案可以引入順序尋址系統,允許該系統內的狀態證明只有 48 個字節長度。 與 ZK-SNARKs 一樣,多重證明方案(譯者注:Multiproof Scheme,具體可參考 PCS multiproofs using random evaluationhttps://dankradfeist.de/ethereum/2021/06/18/pcs-multiproofs.html)可以將所有這些證明合併為每個塊的單個證明;
圖片

如果我們想避免為每筆交易都製作一個證明,我們可以實施一個更輕的解決方案,只需要一個跨 L2 證明來恢復。 一個帳戶中的支出將依賴於與該帳戶中公鑰相對應的支出密鑰,但恢復將需要一個交互來複製密鑰庫中的當前 Spending_pubkey。 即使你的舊密鑰不安全,反事實位址中的資金也是安全的:“啟動” 反事實位址以將其轉變為工作合約需要進行交叉 L2 證明以複製當前的 Spending_pubkey. Safe 論壇上的這篇文章描述了類似架構的工作原理(譯者注:How can a Safe hold asset on multiple chains? https://forum.safe.global/t/how-can-a-safe-hold-asset-on-multiple-chains/2242)。

為了給此方案增加隱私屬性,我們只需加密這個 Pointer,然後我們在 ZK-SNARKs 內部中進行所有證明工作:

圖片

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

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

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

使用 ENS 很昂貴。 今天,即 2023 年 6 月,情況還算不錯:交易費用很高,但仍可與 ENS 域名費用相媲美。 註冊 zuzalu.eth 花了我大約 27 美元,其中 11 美元是交易費。 但如果我們有另一個牛市,費用將會飆升。 即使沒有 ETH 價格上漲,gas 費用回到 200 gwei 也會將域名註冊的 tx 費用提高到 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 將自動查找和驗證 L2 中實際存儲該特定子域的狀態的證明(例如 Merkle 分支)。

圖片

實際上獲取證明涉及到存儲在合約中的 URLs 清單,這誠然感覺像中心化,但我認為它實際上不是:它是一個 1-of-N 信任模型(無效的證明會被 CCIP 合約回調功能中的驗證邏輯抓住,只要其中一個 URLs 返回有效證明,就可以了),URLs 清單可能包含數十個。

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

  • 許多 Dapps 依賴於使用者提供鏈下簽名。 使用外部擁有帳戶(EOA),這很容易。 ERC-1271 為智慧合約錢包提供了一種標準化的方式來做到這一點。 但是,很多 Dapps 仍然不支援 ERC-1271,他們在未來將會需要的;
  • 通過 “is this an EOA?” 來判斷區分使用者和合約(例如,防止轉帳或收取使用費)的 Dapps 模式會被破壞。 總的來說,我建議不要在這裡尋找純技術解決方案; 弄清楚特定的密碼控制轉帳是否是受益擁有權的轉移是一個難題,如果不通過一些鏈下社區驅動的機制可能無法解決。 最有可能的是,應用程式將不得不減少對防止轉帳的依賴,轉而更多地依賴 Harberger Tax 等技術;
  • 必须改进钱包与支出密钥和加密密钥的交互方式。目前,钱包通常使用确定性签名来生成特定于应用程序的密钥:使用 EOA 的私钥签署标准随机数(例如应用程序名称的哈希值)会生成一个没有私钥无法生成的确定性值,因此在纯技术意义上它是安全的。然而,这些技术对钱包来说是 “不透明的”,阻止了钱包实现用户交互界面的安全检查。在更成熟的生态系统中,签名、加密和相关功能将必须由钱包更明确地设计;
  • 轻客户端(例如 Helios)将必须验证 L2 而不仅仅是 L1。今天,轻客户端专注于验证 L1 区块头的有效性(使用轻客户端同步协议),并验证 L1 状态的 Merkle 分支和储存于 L1 区块头的交易。在未来,他们还需要验证储存于 L1 状态根中的 L2 状态证明(更高级的版本实际上会查看 L2 预确认);

V. 钱包将需要保护资产和数据

今天,钱包也承担着保护资产的任务。由于一切都在链上,钱包唯一需要保护的是当前保护这些资产的私钥。如果你更改了密钥,你可以在第二天安全地在互联网上发布你以前的私钥。然而,在 ZK 世界中,情况将有所改变:钱包不仅保护身份验证凭据,它还保存着你的数据。

我们通过 Zupass 看到了这样一个世界的最初迹象,这是 Zuzalu 使用的基于 ZK-SNARK 的身份系统。用户有一个用于向系统进行身份验证的私钥,可用于制作基本证明,例如 “证明我是 Zuzalu 居民,但无需透露是哪一个”。但 Zupass 系统也开始在其上构建其他应用程序,最著名的是邮票(Zupass 的 POAPs 版本)。

我的许多 Zupass 邮票之一,确认我是 Team Cat 的骄傲成员

与 POAP 相比,Stamp 提供的关键特性是 Stamp 是私有的:你在本地保存数据,如果你希望某人拥有关于你的信息,你只需向某人通过 ZK 证明这个 Stamp(或对 Stamp 的一些计算)。但伴随增加的风险是:如果你丢失了该信息,你就会丢失邮票。

当然,持有数据的问题可以简化为持有单个加密密钥的问题:某些第三方(甚至链)可以持有数据的加密副本。这有一个方便的优点,即你采取的操作不会更改加密密钥,因此不需要与保存你的加密密钥安全的系统进行任何交互。但即便如此,如果你丢失了加密密钥,你将失去一切。另一方面,如果有人看到你的加密密钥,他们就会看到用该密钥加密的所有内容。

Zupass 的實際解決方案是鼓勵人們將密鑰存儲在多個設備(例如筆記型電腦和手機),因為使用者同時無法訪問所有設備的可能性很小。 甚至更進一步,在多個監護人之間通過秘密共享(譯者注:Secret Sharing,具體可參考 Secret Sharing and Erasure Coding https://blog.ethereum.org/2014/08/16/secret-sharing-erasure-coding-guide-aspiring-dropbox-decentralizer)來存儲金鑰。

這種通過 MPC 進行的社交恢復對於錢包來說並不是一個充分的解決方案,因為這意味著不僅是當前的監護人,甚至以前的監護人都可能串通竊取你的資產,這是一個不可接受的高風險。 但是隱私洩露的風險通常低於總資產損失風險,並且對於隱私有極高要求的用戶總是可以通過備份密鑰資訊來避免資產丟失的風險。

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

VI. 回到身份

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

一種方法是讓 ENS 成為你的身份:你的 ENS 記錄也許可以包含上述所有這些資訊,如果你發送給 bob.eth(或 bob.ecc.eth,或 ...)資金,他們可以在較為複雜的跨域和隱私保護的情況下,看到有關如何與你進行轉帳支付和互動的所有資訊。

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

  • 它把太多的東西和你的名字聯繫在一起。 你的名字不是 “你” 本身,它只是你的眾多屬性之一。 用戶應當可以在無需移動整個身份資料並更新許多應用程式中一大堆記錄的情況下,更改其姓名;
  • 你無法擁有無需信任的反事實名稱(Counterfactual Names)。 任何區塊鏈的一個關鍵 UX 功能是能夠將代幣發送給尚未與該鏈交互的人。 如果沒有這樣的功能,就會有一個問題:與鏈交互需要支付交易費用,而未曾交互過的位址也無法有代幣去支付該交易費用。 ETH 位址,包括帶有 CREATE2 的智慧合約位址,都具有此功能。 而 ENS 名稱沒有此功能,因為如果兩個 Bob 都在鏈下決定他們是 bob.ecc.eth,我們無法從中選擇他們哪一個獲得該名稱;

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

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

圖片

不管是發送者還是接收者先行動,更多地依賴錢包直接即時生成最新的支付資訊可以減少摩擦。 能夠長久保持不變的身份標識對於用戶來說很方便(尤其是使用 ENS),但發送者和接收者之間的直接通信假設在實踐技術中比較棘手,因此我們最終可能會看到不同技術的組合。

在所有这些设计中,让事物既去中心化又易于用户理解是最重要的。我们需要确保用户可以轻松访问和了解他们当前的资产情况,以及他们发布和接收了哪些消息。这些交互视图应该依赖于开放工具,而不是某个专有的解决方案。要避免更加复杂的支付基础设施变成一个不透明的 “抽象塔”,否则将会使开发人员很难理解正在发生的事情并使适应。尽管面临挑战,但为普通用户实现可扩展性、钱包安全和隐私对于以太坊的未来至关重要。这不仅关乎技术可行性,还关乎是否能够为普通用户降低使用门槛。我们需要挺身而出迎接这一挑战。

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

原文連結

The Three Transitions:https://vitalik.eth.limo/general/2023/06/09/three_transitions.html

輔助閱讀資料

Why we need wide adoption of social recovery wallets 

https://vitalik.ca/general/2021/01/11/recovery.html

EIP-1014: Skinny CREATE2

https://eips.ethereum.org/EIPS/eip-1014

ERC-2470: Singleton Factory

https://eips.ethereum.org/EIPS/eip-2470

An incomplete guide to stealth addresses

https://vitalik.ca/general/2023/01/20/stealth.html

KZG polynomial commitments

https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html

PCS multiproofs using random evaluation

https://dankradfeist.de/ethereum/2021/06/18/pcs-multiproofs.html

How can a Safe hold asset on multiple chains?

https://forum.safe.global/t/how-can-a-safe-hold-asset-on-multiple-chains/2242

Secret Sharing and Erasure Coding

https://blog.ethereum.org/2014/08/16/secret-sharing-erasure-coding-guide-aspiring-dropbox-decentralizer

the Bitcoin payment protocol

https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki

免責聲明:作為區塊鏈資訊平臺,本站所發佈文章僅代表作者及嘉賓個人觀點,與 Web3Caff 立場無關。 本文內容僅用於資訊分享,均不構成任何投資建議及要約,並請您遵守所在國家或地區的相關法律法規。