特別感謝 Dan Finlay、Karl Floersch、David Hoffman 以及 Scroll 和 SoulWallet 團隊的反饋、審查和建議。
隨著以太坊從年輕的實驗技術成長爲成熟的技術堆棧,以便爲普通用戶提供一個開放、全球化且無需許可的體驗,我們需要衕時推進三個關鍵的技術轉型:
這三個轉型構成了生態繫統轉型的三角形,必鬚全麵實施,不可偏廢。
缺乏第一項轉型,以太坊將因交易成本高昂(每筆交易成本爲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(例如“第四類型的ZK-EVMs”)併非完全等衕於EVM,它們通常使用Solidity或中間級彙編語言,這阻礙了哈希值的等效性。即使能夠實現哈希值的等效性,錢包所有權通過密鑰變更而髮生改變也會帶來一些非直觀的結果。 隱私保護要求用戶擁有更多的地址,甚至可能改變我們所處理的地址類型。如果隱形地址方案得到廣泛應用,用戶可能不再是隻有少數幾個地址,或者每個L2一個地址,而是每一筆交易都使用一個獨立的地址。其他的隱私保護方案,包括已經存在的如Tornado Cash,也以不衕的方式變更了資産的存儲方式:許多用戶的資金被存放在衕一個智能合約中(因此地址相衕)。爲了曏特定用戶髮送資金,用戶需要依靠隱私方案的內部地址繫統。 如我們所見,這三種變革以不衕的方式削弱了“一個用戶等衕於一個地址”的傳統思維模式,其中一些效果還增加了實施這些變革的覆雜性。特別需要註意的兩個覆雜性問題包括:
我在 Scroll 平颱上持有數字貨幣,想用它購買咖啡(如果“我”指文章作者本人,則“咖啡”實際上是指“緑茶”)。你是賣家,但隻能接受在 Taiko 上的支付。該如何是好?
基本上有兩種解決方案:
當然,這兩種方案可以結合使用:接收方列出他們接受的 L2 網絡,髮送方的錢包根據這些信息確定支付方式,可能是直接髮送(運氣好的話),或者通過跨 L2 網絡橋接。
但這隻是麵對三個轉變時遇到的關鍵挑戰之一:像支付這樣簡單的操作開始需要比一個 20 字節的地址更多的信息。
幸運的是,曏智能合約錢包的過渡併不會給地址繫統帶來太大負擔,但應用層的其他部分仍存在一些技術問題需要解決。錢包需要更新,以確保它們不僅僅是在交易時髮送 21000 gas,併且需要確保錢包能夠追蹤不僅是來自外部擁有賬戶(EOA)的 ETH 轉賬,還有智能合約代碼髮起的 ETH 轉賬。那些假設地址所有權不變的應用(例如,爲了強製執行版權而禁止智能合約的 NFT)需要尋找其他實現目標的方式。智能合約錢包也將簡化一些流程 - 特別是,如果某人僅接收到非 ETH 的 ERC20 代幣,他們可以使用 ERC-4337 支付大師使用該代幣支付交易費用。
另一方麵,隱私保護再次成爲我們尚未徹底解決的重大挑戰。Tornado Cash 的原始版本併未引入這些問題,因爲它不支持內部轉賬:用戶隻能存入和提取。但一旦允許內部轉賬,用戶就需要使用隱私繫統的內部地址方案。實際上,用戶的“支付信息”應包含(i)一種“支付公鑰”,接收方可以利用這個承諾來進行支付,以及(ii)髮送方髮送的隻有接收方能解密的加密信息,幫助接收方識別支付。
隱形地址協議基於元地址概念,其工作機製是:元地址的一部分是髮送方支付密鑰的盲化版本,另一部分是髮送方的加密密鑰(雖然最簡實現可以將這兩個密鑰設置爲衕一個)。
基於加密和 ZK-SNARK隱形地址方案的示意圖。
基於加密和零知識證明(ZK-SNARKs)的隱形地址方案概覽顯示,隱私友好生態繫統中的用戶需要衕時擁有支付公鑰和加密公鑰,併且用戶的支付信息必鬚包括這兩種密鑰。除了支付外,擴展這一方曏還有其他好處。例如,若我們希望實現基於以太坊的加密電子郵件,用戶需要公開某種加密密鑰。在傳統的賬戶體繫中,我們可能重新使用賬戶密鑰,但在安全的智能合約錢包體繫中,我們可能需要更明確的功能。這也有助於使基於以太坊的身份解決方案與非以太坊去中心化隱私生態繫統(尤其是 PGP 密鑰)更加兼容。
在用戶擁有多個地址的情況下,默認實施密鑰更換和社交恢覆的方式是讓用戶對每個地址分別執行恢覆流程。這個過程可以通過一鍵完成:錢包軟件能夠一次性跨所有用戶地址執行恢覆操作。然而,盡管這種方式簡化了用戶體驗,但簡單的多地址恢覆存在三大問題:
解決這些問題非常睏難。幸運的是,有一個相對優雅的方案能夠相當有效地解決這些問題:一個將驗證邏輯和資産持有分開的架構。
每個用戶都有一個密鑰庫合約,這個合約位於一個特定位置(可以是主網或某個特定的二層網絡L2)。然後,用戶在不衕L2上會有不衕的地址,這些地址的驗證邏輯是指曏密鑰庫合約的引用。從這些地址進行轉賬需要曏密鑰庫合約提交一個證明,證明顯示了當前(或更現實地説,非常近期的)交易公鑰。這種證明可以通過幾種方式實現:
如果我們希望避免對每筆交易都進行單獨證明,可以採用一種僅在恢覆時需要跨 L2 證明的更輕量化方案。賬戶的支出將依賴於一個與賬戶內存儲的公鑰相對應的支出密鑰,而恢覆過程則需要一筆交易來更新密鑰庫中的當前 spending_pubkey。即使舊密鑰不再安全,計畫中地址裡的資金也是安全的,激活一個計畫中地址成爲有效合約需要通過跨 L2 證明更新當前的 spending_pubkey。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,就可以置於此類合約的控製之下。一旦 L1 的 ecc.eth 受 CCIP 合約控製,訪問任何 subdomain.ecc.eth 都將自動觸髮查找併驗證證明的過程(例如,Merkle 分支),以證實 L2 真實存儲了該子域名。
穫取這些證明實際上需要訪問合約中列出的一繫列 URL。盡管這看起來有點像集中化管理,但我認爲實際上併非如此:這屬於 1-of-N 信任模型(CCIP 合約的回調函數中的驗證邏輯會攔截任何無效證明,隻要任一 URL 返回了有效證明,就可以認爲是安全的)。這個 URL 列錶可能包含數十個地址。
ENS CCIP 項目的成功是一個裡程碑,它證明了我們迫切需要的根本性改革是完全可能的。但在應用層麵,還需要進行更多的改革。例如:
當前,錢包的核心職責是確保資産的安全。所有資産均存儲於區塊鏈上,錢包需保護的關鍵是那把守護資産的私鑰。換了密鑰後,你甚至可以在次日把舊私鑰公開網絡。但在零知識證明(ZK)技術麵前,這一切都改變了:錢包的職責不再局限於認證信息的保護,還擴展到了數據的保管。
Zupass,一個在 Zuzalu 使用的基於 ZK-SNARK 技術的身份驗證繫統,預示了這一變革。用戶通過私鑰認證,進行如“證明我是 Zuzalu 居民,但不具體指明是誰”的基礎證明。Zupass 繫統還孕育了更多應用,尤其是其版本的 POAPs——郵票。
比如,我就有一個 Zupass 郵票,證明我是“貓咪隊”的自豪成員。
郵票的獨特之處在於其私密性:數據由用戶本地保存,隻有當用戶希望別人知道自己的某些信息時,才會通過 ZK-證明分享郵票或相關數據。這衕時帶來了新的風險:一旦信息丟失,郵票也隨之不翼而飛。
理論上,數據保護可以歸結爲保護一個加密密鑰:第三方(或連本身)可以保存一份加密的數據副本。這樣做的好處是,用戶的操作不會改變加密密鑰,也就無需與保存密鑰的繫統互動。但問題在於,一旦密鑰丟失,一切也都丟失了。反之,密鑰一旦被他人穫取,那麽所有加密數據都將暴露無遺。
Zupass 的事實解決方案是鼓勵人們在多個設備上(例如筆記本電腦和手機)存儲他們的密鑰,因爲他們衕時失去對所有設備的訪問權的幾率非常小。我們可以更進一步,使用秘密共享技術在多個守護者之間分割存儲密鑰。通過 MPC 進行的這種社交恢覆併不是錢包的足夠解決方案,因爲這意味著不僅當前的守護者,而且以前的守護者也可能串通一氣竊取你的資産,這是一個無法接受的高風險。但是,隱私泄露通常比完全資産損失的風險低,對於有高隱私需求的使用案例的人來説,他們總是可以通過不備份與那些隱私需求行動相關的密鑰來接受更高的損失風險。爲了避免讓用戶麵對一個拜占庭式的多重恢覆路徑繫統感到不堪重負,支持社交恢覆的錢包可能需要衕時管理資産恢覆和加密密鑰恢覆。
這些變化共衕指曏了一個事實:即代錶個人在區塊鏈上身份的“地址”概念,必將經歷根本性的轉變。未來,代錶個人身份的不僅僅是一個以太坊(ETH)地址;而是需要以某種方式,結合多個第二層網絡(L2)的地址、匿名元地址、加密密鑰及其他數據。將以太坊名稱服務(ENS)作爲身份識別的一種方式是可行的:你的ENS記録能包含所有這些信息。當某人曏你的ENS地址(如bob.eth或bob.ecc.eth)髮送時,他們能夠穫取所有必要的支付與互動信息,即使在跨域與隱私保護的更覆雜場景下也是如此。
然而,這種以ENS爲核心的身份認證方法存在兩大問題:
一種潛在的解決策略是,在文章前段提及的體繫架構內,曏密鑰存儲合約中增加更多元素。密鑰存儲合約能夠包含關於你及如何與你互動的各類信息(通過 CCIP,部分信息還可以存儲於鏈下),而用戶則將其密鑰存儲合約作爲主要身份標識。但是,他們實際接收的資産,將被保管在多個不衕的位置。密鑰存儲合約併不與特定名稱綁定,且對反事實操作友好:即你可以創建一個地址,這個地址僅能通過具備某些特定初始參數的密鑰存儲合約來初始化。
另一個解決方案類別涉及徹底放棄麵曏用戶的地址概念,這與比特幣支付協議的理念相符。一個思路是更多依賴於髮送者和接收者之間的直接通信渠道;例如,髮送者可以髮送一個聲明鏈接(無論是以明確的 URL 形式還是二維碼),接收者則可以通過他們希望的任何方式來接收付款。
無論是髮送者還是接收者首先行動,更多地依賴錢包直接實時生成最新的支付信息可以減少摩擦。盡管如此,持久的標識符是方便的(特別是與 ENS 相關),併且在實踐中,髮送者和接收者之間的直接通信的假設是一個非常棘手的問題,因此我們可能會看到不衕技術的結合。
在所有這些設計中,保持事物既去中心化又對用戶易於理解是至關重要的。我們需要確保用戶可以輕鬆訪問他們當前資産的最新視圖以及爲他們髮布的旨在接收的消息。這些視圖應該依賴於開放工具,而不是專有解決方案。避免支付基礎設施的更大覆雜性變成一個對開髮者難以理解併適應新情境的“抽象塔”將需要努力。盡管麵臨挑戰,但爲以太坊的未來實現可擴展性、錢包安全性和普通用戶的隱私是至關重要的。這不僅僅是關於技術可行性,而是關於普通用戶的實際可訪問性。我們需要奮起迎接這一挑戰。
Mời người khác bỏ phiếu
特別感謝 Dan Finlay、Karl Floersch、David Hoffman 以及 Scroll 和 SoulWallet 團隊的反饋、審查和建議。
隨著以太坊從年輕的實驗技術成長爲成熟的技術堆棧,以便爲普通用戶提供一個開放、全球化且無需許可的體驗,我們需要衕時推進三個關鍵的技術轉型:
這三個轉型構成了生態繫統轉型的三角形,必鬚全麵實施,不可偏廢。
缺乏第一項轉型,以太坊將因交易成本高昂(每筆交易成本爲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(例如“第四類型的ZK-EVMs”)併非完全等衕於EVM,它們通常使用Solidity或中間級彙編語言,這阻礙了哈希值的等效性。即使能夠實現哈希值的等效性,錢包所有權通過密鑰變更而髮生改變也會帶來一些非直觀的結果。 隱私保護要求用戶擁有更多的地址,甚至可能改變我們所處理的地址類型。如果隱形地址方案得到廣泛應用,用戶可能不再是隻有少數幾個地址,或者每個L2一個地址,而是每一筆交易都使用一個獨立的地址。其他的隱私保護方案,包括已經存在的如Tornado Cash,也以不衕的方式變更了資産的存儲方式:許多用戶的資金被存放在衕一個智能合約中(因此地址相衕)。爲了曏特定用戶髮送資金,用戶需要依靠隱私方案的內部地址繫統。 如我們所見,這三種變革以不衕的方式削弱了“一個用戶等衕於一個地址”的傳統思維模式,其中一些效果還增加了實施這些變革的覆雜性。特別需要註意的兩個覆雜性問題包括:
我在 Scroll 平颱上持有數字貨幣,想用它購買咖啡(如果“我”指文章作者本人,則“咖啡”實際上是指“緑茶”)。你是賣家,但隻能接受在 Taiko 上的支付。該如何是好?
基本上有兩種解決方案:
當然,這兩種方案可以結合使用:接收方列出他們接受的 L2 網絡,髮送方的錢包根據這些信息確定支付方式,可能是直接髮送(運氣好的話),或者通過跨 L2 網絡橋接。
但這隻是麵對三個轉變時遇到的關鍵挑戰之一:像支付這樣簡單的操作開始需要比一個 20 字節的地址更多的信息。
幸運的是,曏智能合約錢包的過渡併不會給地址繫統帶來太大負擔,但應用層的其他部分仍存在一些技術問題需要解決。錢包需要更新,以確保它們不僅僅是在交易時髮送 21000 gas,併且需要確保錢包能夠追蹤不僅是來自外部擁有賬戶(EOA)的 ETH 轉賬,還有智能合約代碼髮起的 ETH 轉賬。那些假設地址所有權不變的應用(例如,爲了強製執行版權而禁止智能合約的 NFT)需要尋找其他實現目標的方式。智能合約錢包也將簡化一些流程 - 特別是,如果某人僅接收到非 ETH 的 ERC20 代幣,他們可以使用 ERC-4337 支付大師使用該代幣支付交易費用。
另一方麵,隱私保護再次成爲我們尚未徹底解決的重大挑戰。Tornado Cash 的原始版本併未引入這些問題,因爲它不支持內部轉賬:用戶隻能存入和提取。但一旦允許內部轉賬,用戶就需要使用隱私繫統的內部地址方案。實際上,用戶的“支付信息”應包含(i)一種“支付公鑰”,接收方可以利用這個承諾來進行支付,以及(ii)髮送方髮送的隻有接收方能解密的加密信息,幫助接收方識別支付。
隱形地址協議基於元地址概念,其工作機製是:元地址的一部分是髮送方支付密鑰的盲化版本,另一部分是髮送方的加密密鑰(雖然最簡實現可以將這兩個密鑰設置爲衕一個)。
基於加密和 ZK-SNARK隱形地址方案的示意圖。
基於加密和零知識證明(ZK-SNARKs)的隱形地址方案概覽顯示,隱私友好生態繫統中的用戶需要衕時擁有支付公鑰和加密公鑰,併且用戶的支付信息必鬚包括這兩種密鑰。除了支付外,擴展這一方曏還有其他好處。例如,若我們希望實現基於以太坊的加密電子郵件,用戶需要公開某種加密密鑰。在傳統的賬戶體繫中,我們可能重新使用賬戶密鑰,但在安全的智能合約錢包體繫中,我們可能需要更明確的功能。這也有助於使基於以太坊的身份解決方案與非以太坊去中心化隱私生態繫統(尤其是 PGP 密鑰)更加兼容。
在用戶擁有多個地址的情況下,默認實施密鑰更換和社交恢覆的方式是讓用戶對每個地址分別執行恢覆流程。這個過程可以通過一鍵完成:錢包軟件能夠一次性跨所有用戶地址執行恢覆操作。然而,盡管這種方式簡化了用戶體驗,但簡單的多地址恢覆存在三大問題:
解決這些問題非常睏難。幸運的是,有一個相對優雅的方案能夠相當有效地解決這些問題:一個將驗證邏輯和資産持有分開的架構。
每個用戶都有一個密鑰庫合約,這個合約位於一個特定位置(可以是主網或某個特定的二層網絡L2)。然後,用戶在不衕L2上會有不衕的地址,這些地址的驗證邏輯是指曏密鑰庫合約的引用。從這些地址進行轉賬需要曏密鑰庫合約提交一個證明,證明顯示了當前(或更現實地説,非常近期的)交易公鑰。這種證明可以通過幾種方式實現:
如果我們希望避免對每筆交易都進行單獨證明,可以採用一種僅在恢覆時需要跨 L2 證明的更輕量化方案。賬戶的支出將依賴於一個與賬戶內存儲的公鑰相對應的支出密鑰,而恢覆過程則需要一筆交易來更新密鑰庫中的當前 spending_pubkey。即使舊密鑰不再安全,計畫中地址裡的資金也是安全的,激活一個計畫中地址成爲有效合約需要通過跨 L2 證明更新當前的 spending_pubkey。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,就可以置於此類合約的控製之下。一旦 L1 的 ecc.eth 受 CCIP 合約控製,訪問任何 subdomain.ecc.eth 都將自動觸髮查找併驗證證明的過程(例如,Merkle 分支),以證實 L2 真實存儲了該子域名。
穫取這些證明實際上需要訪問合約中列出的一繫列 URL。盡管這看起來有點像集中化管理,但我認爲實際上併非如此:這屬於 1-of-N 信任模型(CCIP 合約的回調函數中的驗證邏輯會攔截任何無效證明,隻要任一 URL 返回了有效證明,就可以認爲是安全的)。這個 URL 列錶可能包含數十個地址。
ENS CCIP 項目的成功是一個裡程碑,它證明了我們迫切需要的根本性改革是完全可能的。但在應用層麵,還需要進行更多的改革。例如:
當前,錢包的核心職責是確保資産的安全。所有資産均存儲於區塊鏈上,錢包需保護的關鍵是那把守護資産的私鑰。換了密鑰後,你甚至可以在次日把舊私鑰公開網絡。但在零知識證明(ZK)技術麵前,這一切都改變了:錢包的職責不再局限於認證信息的保護,還擴展到了數據的保管。
Zupass,一個在 Zuzalu 使用的基於 ZK-SNARK 技術的身份驗證繫統,預示了這一變革。用戶通過私鑰認證,進行如“證明我是 Zuzalu 居民,但不具體指明是誰”的基礎證明。Zupass 繫統還孕育了更多應用,尤其是其版本的 POAPs——郵票。
比如,我就有一個 Zupass 郵票,證明我是“貓咪隊”的自豪成員。
郵票的獨特之處在於其私密性:數據由用戶本地保存,隻有當用戶希望別人知道自己的某些信息時,才會通過 ZK-證明分享郵票或相關數據。這衕時帶來了新的風險:一旦信息丟失,郵票也隨之不翼而飛。
理論上,數據保護可以歸結爲保護一個加密密鑰:第三方(或連本身)可以保存一份加密的數據副本。這樣做的好處是,用戶的操作不會改變加密密鑰,也就無需與保存密鑰的繫統互動。但問題在於,一旦密鑰丟失,一切也都丟失了。反之,密鑰一旦被他人穫取,那麽所有加密數據都將暴露無遺。
Zupass 的事實解決方案是鼓勵人們在多個設備上(例如筆記本電腦和手機)存儲他們的密鑰,因爲他們衕時失去對所有設備的訪問權的幾率非常小。我們可以更進一步,使用秘密共享技術在多個守護者之間分割存儲密鑰。通過 MPC 進行的這種社交恢覆併不是錢包的足夠解決方案,因爲這意味著不僅當前的守護者,而且以前的守護者也可能串通一氣竊取你的資産,這是一個無法接受的高風險。但是,隱私泄露通常比完全資産損失的風險低,對於有高隱私需求的使用案例的人來説,他們總是可以通過不備份與那些隱私需求行動相關的密鑰來接受更高的損失風險。爲了避免讓用戶麵對一個拜占庭式的多重恢覆路徑繫統感到不堪重負,支持社交恢覆的錢包可能需要衕時管理資産恢覆和加密密鑰恢覆。
這些變化共衕指曏了一個事實:即代錶個人在區塊鏈上身份的“地址”概念,必將經歷根本性的轉變。未來,代錶個人身份的不僅僅是一個以太坊(ETH)地址;而是需要以某種方式,結合多個第二層網絡(L2)的地址、匿名元地址、加密密鑰及其他數據。將以太坊名稱服務(ENS)作爲身份識別的一種方式是可行的:你的ENS記録能包含所有這些信息。當某人曏你的ENS地址(如bob.eth或bob.ecc.eth)髮送時,他們能夠穫取所有必要的支付與互動信息,即使在跨域與隱私保護的更覆雜場景下也是如此。
然而,這種以ENS爲核心的身份認證方法存在兩大問題:
一種潛在的解決策略是,在文章前段提及的體繫架構內,曏密鑰存儲合約中增加更多元素。密鑰存儲合約能夠包含關於你及如何與你互動的各類信息(通過 CCIP,部分信息還可以存儲於鏈下),而用戶則將其密鑰存儲合約作爲主要身份標識。但是,他們實際接收的資産,將被保管在多個不衕的位置。密鑰存儲合約併不與特定名稱綁定,且對反事實操作友好:即你可以創建一個地址,這個地址僅能通過具備某些特定初始參數的密鑰存儲合約來初始化。
另一個解決方案類別涉及徹底放棄麵曏用戶的地址概念,這與比特幣支付協議的理念相符。一個思路是更多依賴於髮送者和接收者之間的直接通信渠道;例如,髮送者可以髮送一個聲明鏈接(無論是以明確的 URL 形式還是二維碼),接收者則可以通過他們希望的任何方式來接收付款。
無論是髮送者還是接收者首先行動,更多地依賴錢包直接實時生成最新的支付信息可以減少摩擦。盡管如此,持久的標識符是方便的(特別是與 ENS 相關),併且在實踐中,髮送者和接收者之間的直接通信的假設是一個非常棘手的問題,因此我們可能會看到不衕技術的結合。
在所有這些設計中,保持事物既去中心化又對用戶易於理解是至關重要的。我們需要確保用戶可以輕鬆訪問他們當前資産的最新視圖以及爲他們髮布的旨在接收的消息。這些視圖應該依賴於開放工具,而不是專有解決方案。避免支付基礎設施的更大覆雜性變成一個對開髮者難以理解併適應新情境的“抽象塔”將需要努力。盡管麵臨挑戰,但爲以太坊的未來實現可擴展性、錢包安全性和普通用戶的隱私是至關重要的。這不僅僅是關於技術可行性,而是關於普通用戶的實際可訪問性。我們需要奮起迎接這一挑戰。