我想在錢包中看到的是

中級12/10/2024, 4:23:35 AM
Vitalik Buterin討論了理想的以太坊錢包,著重於跨層2交易、增強安全性和隱私保護等關鍵功能。他強調錢包應無縫處理多鏈和跨層2轉帳,改善用戶體驗,支持去中心化身份和數據存儲。此外,他還強調了整合隱私功能的必要性,例如用於私人交易的ZK-SNARKs,以及強大的安全性來對抗釣魚等威脅。

跨L2交易的用戶體驗

現在有了一個越來越詳細的路線圖,以改善跨L2用戶體驗,它有一個短期部分和一個長期部分。這裡,我將談談短期部分:這些理念即使在今天也是理論上可實現的。

核心理念是(i)內置跨L2發送,以及(ii)特定於鏈的地址和支付請求。您的錢包應該能夠給您一個地址(遵循的風格這個草案 ERC) 看起來像這樣:

0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth

當有人(或某個應用程序)給您提供這種格式的地址時,您應該能夠將其粘貼到錢包的“發送到”字段中,然後點擊“發送”。錢包應該能自動以任何方式處理該發送:

  • 如果您在目標鏈上已經擁有足夠的所需類型的幣,請直接發送幣
  • 如果您在其他鏈(或多個其他鏈)上擁有所需類型的代幣,請使用像ERC-7683(有效地進行跨鏈 DEX)以發送硬幣
  • 如果您在同一條鏈或其他鏈上擁有不同類型的代幣,請使用去中心化交易所將它們轉換為正確類型的代幣並發送。這應該需要用戶的明確許可:用戶可以看到他們支付了多少以及接收方獲得了多少。

可能的錢包界面樣本,支持跨鏈地址

上述是為了“你複製粘貼一個地址(或ENS,例如。vitalik.eth@optimism.eth)讓某人支付您的使用案例。如果一個dapp正在請求存款(例如,請參閱這個 Polymarket 例子) 然後理想的流程是擴展web3 API,並允許dapp發出特定於鏈的付款請求。然後,您的錢包將能夠以所需的任何方式滿足該請求。為了使用戶體驗良好,還需要標準化一個getAvailableBalance請求,並且錢包需要仔細考慮默認情況下將用戶資產存儲在哪些鏈上,以最大化安全性和轉賬的便利性。

特定於鏈的付款請求也可以放入QR碼中,手機錢包可以掃描。在面對面(或在線)的消費者支付情境中,收款人可以生成一個QR碼或web3 API調用,其中說“我想要在鏈Z上用參考ID或回調W要求X個單位的代幣Y”,錢包可以自由地滿足該請求。另一個選項是索取鏈接協議,用戶的錢包生成包含從他們的鏈上合約索取一定數量資金的授權的QR碼或URL,然後接收方的任務是弄清如何將這些資金轉移到他們自己的錢包中。

另一个相关主题是燃气支付。如果您在L2上接收资产时还没有ETH,并且您需要在该L2上发送交易,则钱包应能够自动使用协议(例如。RIP-7755)要在您持有ETH的鏈上支付gas。如果錢包預期您將來在該L2上進行更多交易,它還應該使用DEX將例如價值幾百萬gas的ETH轉移過去,以便將來的交易可以直接在那裡花費gas(因為這樣更便宜)。

帳戶安全

我理解帳戶安全挑戰的一種方式是,一個好的錢包應該同時在兩個方面表現良好:(i)保護用戶免受錢包開發者被入侵或惡意攻擊,(ii)保護用戶免受自己的錯誤。

左邊的拼寫錯誤“mistakles”是無意的。然而,看到它時我意識到它在這個情境下非常合適,所以我決定保留它。

對此,我偏好的解決方案是超過ten社交恢復和多簽錢包,具有分級存取控制。用戶帳戶有兩層鑰匙:一個主鑰匙和 N 個管理者(例如 N = 5)。主鑰匙能夠進行低價值和非金融操作。需要大多數管理者才能進行(i)高價值操作,例如將帳戶中的全部價值發送出去,或者(ii)更改主鑰匙或任何管理者。如果需要,可以允許主鑰匙使用定時鎖定進行高價值操作。

以上是一個基本設計,可以進行擴充。會話密鑰和權限機制,如 ERC-7715可以在不同應用之間平衡方便性和安全性。更複雜的監護人架構,例如在不同閾值上具有多個時間鎖定持續時間,可以最大限度地提高成功合法帳戶恢復的機會,同時將盜竊風險降到最低。

監護人應該是誰或什麼?

對於一名經驗豐富的加密貨幣使用者來說,他身處於一個經驗豐富的加密貨幣使用者社區之內,一個可行的選擇是你的朋友和家人的密鑰。如果你請求每個人提供你一個新的地址,那麼沒有人需要知道他們是誰 - 實際上,你的監護人甚至不需要知道彼此是誰。他們會在沒有其中一個人向你發出警告的情況下串通的機會微乎其微。然而,對於大多數新用戶來說,這個選擇是不可用的。

第二個選擇是機構監護人:專門提供服務,只有在獲得其他確認要求來自您的交易時才會簽署交易,例如確認碼,或者對於高價值用戶的視頻通話。人們長期以來一直在試圖製作這些。我在2013年介紹了CryptoCorp公司. 但是,到目前為止,這樣的公司並不是非常成功。

第三個選項是多個個人設備(例如手機、桌面電腦、硬件錢包)。這樣可以運作,但對於沒有經驗的用戶來說設置和管理起來也很困難。同時,設備在同一地點丟失或被盜的風險也很大。

最近,我們開始看到更多基於密鑰的錢包。密鑰只能在您的設備上備份,使其成為一種個人設備解決方案,或者在雲中備份,使其安全性依賴於複雜 混合密碼安全性、機構和可信硬體假設。實際上,對於普通用戶來說,密鑰是一種寶貴的安全收益,但僅靠它們還不足以保護使用者的終身儲蓄。

幸運的是,有了ZK-SNARKs,我們有了第四個選項:ZK-wrapped centralized ID。這個類型包括zk-emailAnon AadhaarMyna錢包,以及其他許多形式。基本上,您可以將許多形式的(企業或政府)集中式ID轉換為以太坊地址,您只能通過生成ZK-SNARK來證明擁有集中式ID的交易。

有了這個補充,我們現在有各種各樣的選擇,ZK包裝的中心化ID是獨一無二的“菜鳥友好”。

為此,需要使用簡化和集成的UI來實現它:您應該能夠指定您想要”example@gmail.com作為一個監護人,它應該在幕後自動生成相應的 zk-email 以太坊地址。 高級用戶應該能夠在開源的第三方應用程序中輸入他們的電子郵件(連同可能的隱私鹽值,該值將保存在該電子郵件中),並確認生成的地址是否正確。 對於任何其他支持的監護人類型,也應該是如此。

可能的Safe界面模型

請注意,今天,zk-email特別的一個實際挑戰是它取決於DKIM簽統,其使用的密鑰每隔幾個月會輪換一次,而這些密鑰本身並不是由其他任何機構簽署的。這意味著zk-email今天具有某種程度的信任要求,超出了提供者本身;如果zk-email使用TLSNotary在可信硬體內部驗證更新的金鑰,但這並非理想。希望郵件供應商將開始直接簽署他們的 DKIM 金鑰。今天,我建議使用 zk-email 作為一個監護人,但不建議用於大多數監護人:不要在 zk-email 断裂會導致您無法存取資金的設置中存儲資金。

新用戶和應用內錢包

新用戶在其第一次註冊體驗中實際上不會想要輸入大量的監護人。因此,錢包應該為他們提供非常簡單的選項。一個自然的途徑是在其電子郵件地址上使用2-of-3的 zk-email,用戶設備上存儲的密鑰(可以是通行證),以及由提供者持有的備份密鑰。當用戶變得更有經驗或資產增加時,他們應被提示添加更多的監護人。

應用程式中集成的錢包是不可避免的,因為試圖吸引非加密使用者的應用程式不希望讓用戶在同一時間要求他們下載兩個新應用程式(應用程式本身,加上以太坊錢包)而陷入混亂的用戶體驗。然而,許多應用程式錢包的用戶應該能夠將所有錢包連接在一起,這樣他們只需擔心一個“存取控制事項”。這樣做的最簡單方式是一種階層方案,其中有一個快速的“連接”過程,使用戶可以將他們的主要錢包設置為所有應用程式錢包的監護人。Farcaster客戶端Warpcast已經支持這一點:

默認情況下,您的Warpcast帳戶的恢復由Warpcast團隊控制。但是,您可以“自行掌握”您的Farcaster帳戶,並將恢復更改為您自己的地址。

保護用戶免受詐騙和其他外部威脅

除了帳戶安全外,如今的錢包在辨識假地址、釣魚、詐騙和其他外部威脅方面做了很多工作,並試圖保護用戶免受此類威脅。同時,許多對抗措施仍然相當原始:例如,無論您發送100美元還是100,000美元,都需要點擊通過來將ETH或其他代幣發送到任何新地址。在這裡,沒有單一的神奇解決方案;這是一系列對不同類別的威脅進行緩慢持續的修復和改進。然而,在這裡繼續努力改進是非常有價值的。

隱私

現在是時候開始更加認真地對待以太坊上的隱私。ZK-SNARK 技術現在非常先進,可以減輕監管風險,而不依賴後門等隱私技術。隱私池, 正變得更加成熟,次要基礎設施如Waku並且ERC-4337 mempools正在慢慢變得更加穩定。然而,直到現在,在Ethereum上進行私人轉帳都需要用戶明確地下載和使用“隱私錢包”,如鐵路(或Umbra for 隱形地址這增加了很大的不便,減少了願意進行私人轉帳的人數。解決方案是將私人轉帳直接整合到錢包中。

一個簡單的實現方式如下。錢包可以將用戶的一部分資產存儲為“私人餘額”在隱私池中。當用戶進行轉帳時,將自動首先從隱私池中提取。如果用戶需要接收資金,錢包可以自動生成隱藏地址。

此外,錢包可以自動為用戶參與的每個應用程序(例如,defi協議)生成一個新的地址。存款將來自隱私池,提款將直接進入隱私池。這使得用戶在任何一個應用程序中的活動與他們在其他應用程序中的活動無法關聯。

這種技術的一個優勢是,它不僅是一種自然的隱私保護資產轉移途徑,還是一種隱私保護身份的方法。身份已經在鏈上發生: 使用人證閘控(例如 Gitcoin Grants)的任何應用程式,任何代幣閘控的聊天,以太坊跟隨協議,以及更多都是鏈上身份。我們希望這個生態系統也能保護隱私。這意味著用戶在鏈上的活動不應該被集中在一個地方:每個項目應該被單獨存儲,用戶的錢包應該是唯一能夠同時查看所有您的證明的“全局視圖”的東西。本地多帳戶每用戶生態系統有助於實現這一目標,同樣,在鏈下證明協議也有助於達成此目標,例如 EASZupass.

這代表了以太坊在中期未來隱私方面的務實願景。它可以在今天實施,儘管可以在 L1 和 L2 引入功能,使保護隱私的轉帳更有效和可靠。一些隱私倡導者認為,唯一可接受的事情是對所有內容進行全面加密:加密整個 EVM。我會認為,這可能是理想的長期結果,但需要更基本的編程模型重新思考,目前還沒有準備好並在以太坊全面部署的成熟水平。我們需要默認隱私以獲得足夠大的匿名集。然而,首先專注於使帳戶之間的轉帳和身份以及與身份相關的用例如證明私有化是一個務實的第一步,更容易實施,錢包今天可以開始使用。

以太坊錢包也需要成為數據錢包

任何有效的隱私解決方案,無論是用於支付、身份或其他用例,都會產生用戶需要存儲離線數據的需求。這在Tornado Cash中是顯而易見的,它要求用戶保存表示0.1-100 ETH存款的每個單獨的“筆記”。更現代的隱私協議有時會將數據加密保存在鏈上,並使用單個私鑰解密它。這是有風險的,因為如果密鑰泄漏,或者如果量子計算機變得可行,則所有數據都將變為公開。像EAS和Zupass這樣的離線證明更需要離線數據存儲的需求更加明顯。

錢包需要成為不僅僅是存儲鏈上訪問權限的軟件,還需要成為存儲您的私人數據的軟件。這是非加密世界越來越認可的一點,例如,參見Tim Berners-Lee的。個人數據存儲的最新工作我們需要解決的所有問題都圍繞著堅固地保證訪問權限的控制,我們也需要圍繞著堅固地保證數據的可訪問性和非洩露性來解決。也許解決方案可以合併在一起:如果您有N個監護人,請在這些監護人之間使用M-of-N的秘密共享來存儲您的數據。數據本質上更難以保證安全,因為您無法撤銷他人對其的分享,但我們應該提出分散式監護解決方案,盡可能地使其安全。

安全鏈接訪問

今天,錢包信任他們的 RPC 提供者向他們提供有關鏈的任何信息。這在兩個方面都存在漏洞:

  1. RPC提供者可能試圖通過提供虛假信息(例如關於市場價格)來竊取資金
  2. RPC提供者可以提取有關用戶正在與之互動的應用程序和其他帳戶的私人信息

理想情況下,我們希望堵住這兩個漏洞。為了堵住第一個漏洞,我們需要為L1和L2提供標準化的輕客戶端,直接驗證區塊鏈共識。Helios已經對L1做到了這一點,並且一直在進行一些初步工作,以支持一些特定的L2。要正確地覆蓋所有L2,我們需要的是一個標準,通過這個標準,代表L2的配置合約(也用於特定鏈地址)可以聲明一個函數,也許是以某種類似的方式。ERC-3668包含獲取最近狀態根和驗證狀態和收據證明與這些狀態根相對應的邏輯。這樣我們可以擁有通用的輕量級客戶端,允許錢包在L1和L2上安全驗證任何狀態或事件。

為了隱私,今天唯一現實的方法是運行自己的完整節點。然而,現在 L2s 進入場景,運行完整節點變得越來越困難。這裡的輕客戶端相當於私人信息檢索(PIR). PIR涉及一個存儲所有數據副本的服務器,以及一個向服務器發送加密請求的客戶端。服務器對所有數據進行計算,返回客戶端所需的數據,並使用客戶端的密鑰對其進行加密,而不向服務器透露客戶端訪問的數據片段。

為了保持服務器的誠實,個別的數據庫項目本身將是 Merkle 分支,因此客戶端可以使用他們的輕客戶端驗證它們。

PIR在計算上非常昂貴。有幾種方法可以解決這個問題:

  • Brute force: 算法的改进或专用硬件可能使PIR足够快速运行。这些技术可能依赖预处理:服务器可以为每个客户端存储加密和洗牌的数据,客户端可以查询这些数据。以太坊环境中的主要挑战是将这些技术适应快速变化的数据集(如状态)。这降低了实时计算成本,但可能会增加总计算和存储成本。
  • 削弱隱私要求:例如,每次查找只能有 100 萬個“mixin”,因此伺服器將知道用戶端可以訪問的一百萬個可能值,但不會知道任何更精細的粒度
  • 多伺服器PIR:如果您在多個伺服器之間使用1-of-N誠實假設,PIR算法通常會快得多。
  • 匿名而非保密:不是隐藏请求的内容,而是将请求通过混合网络发送,隐藏请求的发送者。然而,这样做必然会增加延迟,进而降低用户体验。

在以太坊的情境中,找到最大化隱私並保持實用性的正確技術組合是一個開放的研究問題,我歡迎密碼學家們嘗試解決這個問題。

理想的 keystore 錢包

除了轉帳和狀態訪問之外,在跨L2情境中需要順利運作的另一個重要工作流程是更改帳戶的驗證配置:無論是更改其鍵(例如恢復),還是對帳戶的整個邏輯進行更深層次的更改。在這裡,有三個解決方案層級,按難度遞增排序:

  1. 重新播放的更新:當用戶更改其配置時,授權此更改的消息將在錢包檢測到用戶擁有資產的每條鏈上重新播放。潛在地,消息格式和驗證規則可以被設計成與鏈無關,因此可以在可能的多個鏈上自動重新播放。
  2. L1 上的鑰匙存儲: 配置信息保存在 L1 上,L2 上的錢包可以通過讀取它L1SLOAD遠端靜電呼叫這樣一來,只需要在L1上更新配置,配置就會自動生效。
  3. L2上的密鑰庫:配置信息存儲在L2上,L2上的錢包通過ZK-SNARK讀取。這與(2)相同,只是密鑰庫更新可能更便宜,但另一方面讀取更昂貴。

解決方案(3)特別強大,因為它與隱私堆疊得很好。在一個正常的“隱私解決方案”中,用戶有一個秘密s,鏈上公佈了一個“葉值”L,用戶證明L = hash(s, 1)和N = hash(s, 2)對於他們控制的某個(從未透露的)秘密。空零化器N被公佈,確保將來同一葉子的花費失敗,而不必透露L。這取決於用戶保持s的安全。一個友好於恢復的隱私解決方案將會說:s是鏈上的一個位置(例如地址和存儲插槽),用戶必須證明一個狀態查詢:L = hash(sload(s), 1)。

Dapp安全性

使用者安全中最薄弱的環節通常是dapp。大多數情況下,用戶通過訪問網站與應用程式交互,該網站從伺服器即時隱式下載使用者介面代碼,然後在瀏覽器中執行。如果伺服器被駭客入侵,或者DNS被駭客入侵,用戶將獲得介面的虛假副本,這可能會誘使用戶做任意的事情。交易類比等錢包功能對降低風險非常有説明,但它們遠非完美。

理想情況下,我們將生態系統轉移到鏈上內容版本控制:用戶將通過其ENS名稱訪問dapp,該名稱將包含介面的IPFS哈希。需要來自多重簽名或DAO的鏈上交易來更新介面。錢包會向用戶顯示他們是否正在與更安全的鏈上介面或安全性較低的web2介面進行交互。錢包還可以向用戶顯示他們是否正在與安全鏈交互(例如階段1+,多次安全審計)。

對於注重隱私的用戶,錢包還可以添加一個偏執模式,該模式要求用戶點擊接受HTTP請求,而不僅僅是web3操作:

偏執模式可能介面的模擬

更高級的方法是超越 HTML + Javascript,並以一種專用語言來撰寫 dapps 的業務邏輯,或許是相對輕量級的 Solidity 或 Vyper 的擴充。然後瀏覽器可以自動為任何所需功能生成 UI。OK合約已經在這樣做了。

另一个方向是加密经济信息防御:dapp开发人员、安全公司、链部署者等可以提供债券,如果dapp被黑客攻击或以一种极具误导性的方式对用户造成损害,将会支付给受影响的用户,由某些链上仲裁DAO确定。钱包可以向用户显示基于债券规模的得分。

長期未來

上述內容均涉及傳統界面的上下文,涉及指點和點擊事物以及輸入文字字段。然而,我們也正處於範式更深層次轉變的邊緣:

  • AI可能使我們從“點擊和輸入”的範式轉向“說出你想做的事情,機器人會自動理解”的範式。
  • 腦機介面,包括“溫和”的方法,如眼睛追踪,以及更直接甚至侵入性的技術(見:今年首位Neuralink患者)
  • 積極防禦的用戶:Brave 瀏覽器主動保護使用者免受廣告、跟蹤器和許多其他不良物件的侵害. 許多瀏覽器、插件和加密錢包都有專門的團隊積極努力保護用戶免受各種安全和隱私威脅。這種類型的「積極守護者」在未來十年將變得更加強大。

这三种趋势将共同引发对界面运作方式的深刻重新思考。通过自然语言输入、眼动追踪或最终更直接的脑机接口,再加上对您的历史知识(可能包括短信,只要所有数据都在本地处理),"钱包"可以清晰直观地了解您想要做什么。然后,人工智能可以将这种直觉转化为具体的"行动计划":一系列完成您想要的目标的链上和链下交互。这将大大减少对第三方用户界面的需求。如果用户与第三方应用程序(或其他用户)进行交互,人工智能应该在用户的利益上以对抗的方式思考,并识别任何威胁,并提出避免它们的行动计划。理想情况下,这些人工智能将形成一个开放的生态系统,由不同团队制作,具有不同的偏见和激励机制。

這些更激進的想法依賴於目前非常不成熟的技術,所以我不會將我的資產放入依賴這些技術的錢包中。然而,類似這樣的東西似乎顯然是未來,所以值得開始更積極地探索這個方向。

免責聲明:

  1. 本文轉載自 [ 維塔利克]. 如果有對此轉載的異議,請聯繫Gate 學習團隊,他們會及時處理。
  2. 免責聲明:本文中表達的觀點和意見僅代表作者的觀點和意見,不構成任何投資建議。
  3. 文章的翻譯是由Gate Learn團隊完成的。未經提及,複製、分發或抄襲翻譯後的文章是被禁止的。

我想在錢包中看到的是

中級12/10/2024, 4:23:35 AM
Vitalik Buterin討論了理想的以太坊錢包,著重於跨層2交易、增強安全性和隱私保護等關鍵功能。他強調錢包應無縫處理多鏈和跨層2轉帳,改善用戶體驗,支持去中心化身份和數據存儲。此外,他還強調了整合隱私功能的必要性,例如用於私人交易的ZK-SNARKs,以及強大的安全性來對抗釣魚等威脅。

跨L2交易的用戶體驗

現在有了一個越來越詳細的路線圖,以改善跨L2用戶體驗,它有一個短期部分和一個長期部分。這裡,我將談談短期部分:這些理念即使在今天也是理論上可實現的。

核心理念是(i)內置跨L2發送,以及(ii)特定於鏈的地址和支付請求。您的錢包應該能夠給您一個地址(遵循的風格這個草案 ERC) 看起來像這樣:

0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth

當有人(或某個應用程序)給您提供這種格式的地址時,您應該能夠將其粘貼到錢包的“發送到”字段中,然後點擊“發送”。錢包應該能自動以任何方式處理該發送:

  • 如果您在目標鏈上已經擁有足夠的所需類型的幣,請直接發送幣
  • 如果您在其他鏈(或多個其他鏈)上擁有所需類型的代幣,請使用像ERC-7683(有效地進行跨鏈 DEX)以發送硬幣
  • 如果您在同一條鏈或其他鏈上擁有不同類型的代幣,請使用去中心化交易所將它們轉換為正確類型的代幣並發送。這應該需要用戶的明確許可:用戶可以看到他們支付了多少以及接收方獲得了多少。

可能的錢包界面樣本,支持跨鏈地址

上述是為了“你複製粘貼一個地址(或ENS,例如。vitalik.eth@optimism.eth)讓某人支付您的使用案例。如果一個dapp正在請求存款(例如,請參閱這個 Polymarket 例子) 然後理想的流程是擴展web3 API,並允許dapp發出特定於鏈的付款請求。然後,您的錢包將能夠以所需的任何方式滿足該請求。為了使用戶體驗良好,還需要標準化一個getAvailableBalance請求,並且錢包需要仔細考慮默認情況下將用戶資產存儲在哪些鏈上,以最大化安全性和轉賬的便利性。

特定於鏈的付款請求也可以放入QR碼中,手機錢包可以掃描。在面對面(或在線)的消費者支付情境中,收款人可以生成一個QR碼或web3 API調用,其中說“我想要在鏈Z上用參考ID或回調W要求X個單位的代幣Y”,錢包可以自由地滿足該請求。另一個選項是索取鏈接協議,用戶的錢包生成包含從他們的鏈上合約索取一定數量資金的授權的QR碼或URL,然後接收方的任務是弄清如何將這些資金轉移到他們自己的錢包中。

另一个相关主题是燃气支付。如果您在L2上接收资产时还没有ETH,并且您需要在该L2上发送交易,则钱包应能够自动使用协议(例如。RIP-7755)要在您持有ETH的鏈上支付gas。如果錢包預期您將來在該L2上進行更多交易,它還應該使用DEX將例如價值幾百萬gas的ETH轉移過去,以便將來的交易可以直接在那裡花費gas(因為這樣更便宜)。

帳戶安全

我理解帳戶安全挑戰的一種方式是,一個好的錢包應該同時在兩個方面表現良好:(i)保護用戶免受錢包開發者被入侵或惡意攻擊,(ii)保護用戶免受自己的錯誤。

左邊的拼寫錯誤“mistakles”是無意的。然而,看到它時我意識到它在這個情境下非常合適,所以我決定保留它。

對此,我偏好的解決方案是超過ten社交恢復和多簽錢包,具有分級存取控制。用戶帳戶有兩層鑰匙:一個主鑰匙和 N 個管理者(例如 N = 5)。主鑰匙能夠進行低價值和非金融操作。需要大多數管理者才能進行(i)高價值操作,例如將帳戶中的全部價值發送出去,或者(ii)更改主鑰匙或任何管理者。如果需要,可以允許主鑰匙使用定時鎖定進行高價值操作。

以上是一個基本設計,可以進行擴充。會話密鑰和權限機制,如 ERC-7715可以在不同應用之間平衡方便性和安全性。更複雜的監護人架構,例如在不同閾值上具有多個時間鎖定持續時間,可以最大限度地提高成功合法帳戶恢復的機會,同時將盜竊風險降到最低。

監護人應該是誰或什麼?

對於一名經驗豐富的加密貨幣使用者來說,他身處於一個經驗豐富的加密貨幣使用者社區之內,一個可行的選擇是你的朋友和家人的密鑰。如果你請求每個人提供你一個新的地址,那麼沒有人需要知道他們是誰 - 實際上,你的監護人甚至不需要知道彼此是誰。他們會在沒有其中一個人向你發出警告的情況下串通的機會微乎其微。然而,對於大多數新用戶來說,這個選擇是不可用的。

第二個選擇是機構監護人:專門提供服務,只有在獲得其他確認要求來自您的交易時才會簽署交易,例如確認碼,或者對於高價值用戶的視頻通話。人們長期以來一直在試圖製作這些。我在2013年介紹了CryptoCorp公司. 但是,到目前為止,這樣的公司並不是非常成功。

第三個選項是多個個人設備(例如手機、桌面電腦、硬件錢包)。這樣可以運作,但對於沒有經驗的用戶來說設置和管理起來也很困難。同時,設備在同一地點丟失或被盜的風險也很大。

最近,我們開始看到更多基於密鑰的錢包。密鑰只能在您的設備上備份,使其成為一種個人設備解決方案,或者在雲中備份,使其安全性依賴於複雜 混合密碼安全性、機構和可信硬體假設。實際上,對於普通用戶來說,密鑰是一種寶貴的安全收益,但僅靠它們還不足以保護使用者的終身儲蓄。

幸運的是,有了ZK-SNARKs,我們有了第四個選項:ZK-wrapped centralized ID。這個類型包括zk-emailAnon AadhaarMyna錢包,以及其他許多形式。基本上,您可以將許多形式的(企業或政府)集中式ID轉換為以太坊地址,您只能通過生成ZK-SNARK來證明擁有集中式ID的交易。

有了這個補充,我們現在有各種各樣的選擇,ZK包裝的中心化ID是獨一無二的“菜鳥友好”。

為此,需要使用簡化和集成的UI來實現它:您應該能夠指定您想要”example@gmail.com作為一個監護人,它應該在幕後自動生成相應的 zk-email 以太坊地址。 高級用戶應該能夠在開源的第三方應用程序中輸入他們的電子郵件(連同可能的隱私鹽值,該值將保存在該電子郵件中),並確認生成的地址是否正確。 對於任何其他支持的監護人類型,也應該是如此。

可能的Safe界面模型

請注意,今天,zk-email特別的一個實際挑戰是它取決於DKIM簽統,其使用的密鑰每隔幾個月會輪換一次,而這些密鑰本身並不是由其他任何機構簽署的。這意味著zk-email今天具有某種程度的信任要求,超出了提供者本身;如果zk-email使用TLSNotary在可信硬體內部驗證更新的金鑰,但這並非理想。希望郵件供應商將開始直接簽署他們的 DKIM 金鑰。今天,我建議使用 zk-email 作為一個監護人,但不建議用於大多數監護人:不要在 zk-email 断裂會導致您無法存取資金的設置中存儲資金。

新用戶和應用內錢包

新用戶在其第一次註冊體驗中實際上不會想要輸入大量的監護人。因此,錢包應該為他們提供非常簡單的選項。一個自然的途徑是在其電子郵件地址上使用2-of-3的 zk-email,用戶設備上存儲的密鑰(可以是通行證),以及由提供者持有的備份密鑰。當用戶變得更有經驗或資產增加時,他們應被提示添加更多的監護人。

應用程式中集成的錢包是不可避免的,因為試圖吸引非加密使用者的應用程式不希望讓用戶在同一時間要求他們下載兩個新應用程式(應用程式本身,加上以太坊錢包)而陷入混亂的用戶體驗。然而,許多應用程式錢包的用戶應該能夠將所有錢包連接在一起,這樣他們只需擔心一個“存取控制事項”。這樣做的最簡單方式是一種階層方案,其中有一個快速的“連接”過程,使用戶可以將他們的主要錢包設置為所有應用程式錢包的監護人。Farcaster客戶端Warpcast已經支持這一點:

默認情況下,您的Warpcast帳戶的恢復由Warpcast團隊控制。但是,您可以“自行掌握”您的Farcaster帳戶,並將恢復更改為您自己的地址。

保護用戶免受詐騙和其他外部威脅

除了帳戶安全外,如今的錢包在辨識假地址、釣魚、詐騙和其他外部威脅方面做了很多工作,並試圖保護用戶免受此類威脅。同時,許多對抗措施仍然相當原始:例如,無論您發送100美元還是100,000美元,都需要點擊通過來將ETH或其他代幣發送到任何新地址。在這裡,沒有單一的神奇解決方案;這是一系列對不同類別的威脅進行緩慢持續的修復和改進。然而,在這裡繼續努力改進是非常有價值的。

隱私

現在是時候開始更加認真地對待以太坊上的隱私。ZK-SNARK 技術現在非常先進,可以減輕監管風險,而不依賴後門等隱私技術。隱私池, 正變得更加成熟,次要基礎設施如Waku並且ERC-4337 mempools正在慢慢變得更加穩定。然而,直到現在,在Ethereum上進行私人轉帳都需要用戶明確地下載和使用“隱私錢包”,如鐵路(或Umbra for 隱形地址這增加了很大的不便,減少了願意進行私人轉帳的人數。解決方案是將私人轉帳直接整合到錢包中。

一個簡單的實現方式如下。錢包可以將用戶的一部分資產存儲為“私人餘額”在隱私池中。當用戶進行轉帳時,將自動首先從隱私池中提取。如果用戶需要接收資金,錢包可以自動生成隱藏地址。

此外,錢包可以自動為用戶參與的每個應用程序(例如,defi協議)生成一個新的地址。存款將來自隱私池,提款將直接進入隱私池。這使得用戶在任何一個應用程序中的活動與他們在其他應用程序中的活動無法關聯。

這種技術的一個優勢是,它不僅是一種自然的隱私保護資產轉移途徑,還是一種隱私保護身份的方法。身份已經在鏈上發生: 使用人證閘控(例如 Gitcoin Grants)的任何應用程式,任何代幣閘控的聊天,以太坊跟隨協議,以及更多都是鏈上身份。我們希望這個生態系統也能保護隱私。這意味著用戶在鏈上的活動不應該被集中在一個地方:每個項目應該被單獨存儲,用戶的錢包應該是唯一能夠同時查看所有您的證明的“全局視圖”的東西。本地多帳戶每用戶生態系統有助於實現這一目標,同樣,在鏈下證明協議也有助於達成此目標,例如 EASZupass.

這代表了以太坊在中期未來隱私方面的務實願景。它可以在今天實施,儘管可以在 L1 和 L2 引入功能,使保護隱私的轉帳更有效和可靠。一些隱私倡導者認為,唯一可接受的事情是對所有內容進行全面加密:加密整個 EVM。我會認為,這可能是理想的長期結果,但需要更基本的編程模型重新思考,目前還沒有準備好並在以太坊全面部署的成熟水平。我們需要默認隱私以獲得足夠大的匿名集。然而,首先專注於使帳戶之間的轉帳和身份以及與身份相關的用例如證明私有化是一個務實的第一步,更容易實施,錢包今天可以開始使用。

以太坊錢包也需要成為數據錢包

任何有效的隱私解決方案,無論是用於支付、身份或其他用例,都會產生用戶需要存儲離線數據的需求。這在Tornado Cash中是顯而易見的,它要求用戶保存表示0.1-100 ETH存款的每個單獨的“筆記”。更現代的隱私協議有時會將數據加密保存在鏈上,並使用單個私鑰解密它。這是有風險的,因為如果密鑰泄漏,或者如果量子計算機變得可行,則所有數據都將變為公開。像EAS和Zupass這樣的離線證明更需要離線數據存儲的需求更加明顯。

錢包需要成為不僅僅是存儲鏈上訪問權限的軟件,還需要成為存儲您的私人數據的軟件。這是非加密世界越來越認可的一點,例如,參見Tim Berners-Lee的。個人數據存儲的最新工作我們需要解決的所有問題都圍繞著堅固地保證訪問權限的控制,我們也需要圍繞著堅固地保證數據的可訪問性和非洩露性來解決。也許解決方案可以合併在一起:如果您有N個監護人,請在這些監護人之間使用M-of-N的秘密共享來存儲您的數據。數據本質上更難以保證安全,因為您無法撤銷他人對其的分享,但我們應該提出分散式監護解決方案,盡可能地使其安全。

安全鏈接訪問

今天,錢包信任他們的 RPC 提供者向他們提供有關鏈的任何信息。這在兩個方面都存在漏洞:

  1. RPC提供者可能試圖通過提供虛假信息(例如關於市場價格)來竊取資金
  2. RPC提供者可以提取有關用戶正在與之互動的應用程序和其他帳戶的私人信息

理想情況下,我們希望堵住這兩個漏洞。為了堵住第一個漏洞,我們需要為L1和L2提供標準化的輕客戶端,直接驗證區塊鏈共識。Helios已經對L1做到了這一點,並且一直在進行一些初步工作,以支持一些特定的L2。要正確地覆蓋所有L2,我們需要的是一個標準,通過這個標準,代表L2的配置合約(也用於特定鏈地址)可以聲明一個函數,也許是以某種類似的方式。ERC-3668包含獲取最近狀態根和驗證狀態和收據證明與這些狀態根相對應的邏輯。這樣我們可以擁有通用的輕量級客戶端,允許錢包在L1和L2上安全驗證任何狀態或事件。

為了隱私,今天唯一現實的方法是運行自己的完整節點。然而,現在 L2s 進入場景,運行完整節點變得越來越困難。這裡的輕客戶端相當於私人信息檢索(PIR). PIR涉及一個存儲所有數據副本的服務器,以及一個向服務器發送加密請求的客戶端。服務器對所有數據進行計算,返回客戶端所需的數據,並使用客戶端的密鑰對其進行加密,而不向服務器透露客戶端訪問的數據片段。

為了保持服務器的誠實,個別的數據庫項目本身將是 Merkle 分支,因此客戶端可以使用他們的輕客戶端驗證它們。

PIR在計算上非常昂貴。有幾種方法可以解決這個問題:

  • Brute force: 算法的改进或专用硬件可能使PIR足够快速运行。这些技术可能依赖预处理:服务器可以为每个客户端存储加密和洗牌的数据,客户端可以查询这些数据。以太坊环境中的主要挑战是将这些技术适应快速变化的数据集(如状态)。这降低了实时计算成本,但可能会增加总计算和存储成本。
  • 削弱隱私要求:例如,每次查找只能有 100 萬個“mixin”,因此伺服器將知道用戶端可以訪問的一百萬個可能值,但不會知道任何更精細的粒度
  • 多伺服器PIR:如果您在多個伺服器之間使用1-of-N誠實假設,PIR算法通常會快得多。
  • 匿名而非保密:不是隐藏请求的内容,而是将请求通过混合网络发送,隐藏请求的发送者。然而,这样做必然会增加延迟,进而降低用户体验。

在以太坊的情境中,找到最大化隱私並保持實用性的正確技術組合是一個開放的研究問題,我歡迎密碼學家們嘗試解決這個問題。

理想的 keystore 錢包

除了轉帳和狀態訪問之外,在跨L2情境中需要順利運作的另一個重要工作流程是更改帳戶的驗證配置:無論是更改其鍵(例如恢復),還是對帳戶的整個邏輯進行更深層次的更改。在這裡,有三個解決方案層級,按難度遞增排序:

  1. 重新播放的更新:當用戶更改其配置時,授權此更改的消息將在錢包檢測到用戶擁有資產的每條鏈上重新播放。潛在地,消息格式和驗證規則可以被設計成與鏈無關,因此可以在可能的多個鏈上自動重新播放。
  2. L1 上的鑰匙存儲: 配置信息保存在 L1 上,L2 上的錢包可以通過讀取它L1SLOAD遠端靜電呼叫這樣一來,只需要在L1上更新配置,配置就會自動生效。
  3. L2上的密鑰庫:配置信息存儲在L2上,L2上的錢包通過ZK-SNARK讀取。這與(2)相同,只是密鑰庫更新可能更便宜,但另一方面讀取更昂貴。

解決方案(3)特別強大,因為它與隱私堆疊得很好。在一個正常的“隱私解決方案”中,用戶有一個秘密s,鏈上公佈了一個“葉值”L,用戶證明L = hash(s, 1)和N = hash(s, 2)對於他們控制的某個(從未透露的)秘密。空零化器N被公佈,確保將來同一葉子的花費失敗,而不必透露L。這取決於用戶保持s的安全。一個友好於恢復的隱私解決方案將會說:s是鏈上的一個位置(例如地址和存儲插槽),用戶必須證明一個狀態查詢:L = hash(sload(s), 1)。

Dapp安全性

使用者安全中最薄弱的環節通常是dapp。大多數情況下,用戶通過訪問網站與應用程式交互,該網站從伺服器即時隱式下載使用者介面代碼,然後在瀏覽器中執行。如果伺服器被駭客入侵,或者DNS被駭客入侵,用戶將獲得介面的虛假副本,這可能會誘使用戶做任意的事情。交易類比等錢包功能對降低風險非常有説明,但它們遠非完美。

理想情況下,我們將生態系統轉移到鏈上內容版本控制:用戶將通過其ENS名稱訪問dapp,該名稱將包含介面的IPFS哈希。需要來自多重簽名或DAO的鏈上交易來更新介面。錢包會向用戶顯示他們是否正在與更安全的鏈上介面或安全性較低的web2介面進行交互。錢包還可以向用戶顯示他們是否正在與安全鏈交互(例如階段1+,多次安全審計)。

對於注重隱私的用戶,錢包還可以添加一個偏執模式,該模式要求用戶點擊接受HTTP請求,而不僅僅是web3操作:

偏執模式可能介面的模擬

更高級的方法是超越 HTML + Javascript,並以一種專用語言來撰寫 dapps 的業務邏輯,或許是相對輕量級的 Solidity 或 Vyper 的擴充。然後瀏覽器可以自動為任何所需功能生成 UI。OK合約已經在這樣做了。

另一个方向是加密经济信息防御:dapp开发人员、安全公司、链部署者等可以提供债券,如果dapp被黑客攻击或以一种极具误导性的方式对用户造成损害,将会支付给受影响的用户,由某些链上仲裁DAO确定。钱包可以向用户显示基于债券规模的得分。

長期未來

上述內容均涉及傳統界面的上下文,涉及指點和點擊事物以及輸入文字字段。然而,我們也正處於範式更深層次轉變的邊緣:

  • AI可能使我們從“點擊和輸入”的範式轉向“說出你想做的事情,機器人會自動理解”的範式。
  • 腦機介面,包括“溫和”的方法,如眼睛追踪,以及更直接甚至侵入性的技術(見:今年首位Neuralink患者)
  • 積極防禦的用戶:Brave 瀏覽器主動保護使用者免受廣告、跟蹤器和許多其他不良物件的侵害. 許多瀏覽器、插件和加密錢包都有專門的團隊積極努力保護用戶免受各種安全和隱私威脅。這種類型的「積極守護者」在未來十年將變得更加強大。

这三种趋势将共同引发对界面运作方式的深刻重新思考。通过自然语言输入、眼动追踪或最终更直接的脑机接口,再加上对您的历史知识(可能包括短信,只要所有数据都在本地处理),"钱包"可以清晰直观地了解您想要做什么。然后,人工智能可以将这种直觉转化为具体的"行动计划":一系列完成您想要的目标的链上和链下交互。这将大大减少对第三方用户界面的需求。如果用户与第三方应用程序(或其他用户)进行交互,人工智能应该在用户的利益上以对抗的方式思考,并识别任何威胁,并提出避免它们的行动计划。理想情况下,这些人工智能将形成一个开放的生态系统,由不同团队制作,具有不同的偏见和激励机制。

這些更激進的想法依賴於目前非常不成熟的技術,所以我不會將我的資產放入依賴這些技術的錢包中。然而,類似這樣的東西似乎顯然是未來,所以值得開始更積極地探索這個方向。

免責聲明:

  1. 本文轉載自 [ 維塔利克]. 如果有對此轉載的異議,請聯繫Gate 學習團隊,他們會及時處理。
  2. 免責聲明:本文中表達的觀點和意見僅代表作者的觀點和意見,不構成任何投資建議。
  3. 文章的翻譯是由Gate Learn團隊完成的。未經提及,複製、分發或抄襲翻譯後的文章是被禁止的。
即刻開始交易
註冊並交易即可獲得
$100
和價值
$5500
理財體驗金獎勵!
It seems that you are attempting to access our services from a Restricted Location where Gate is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Thailand, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.