header-langage
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
掃碼下載APP

V神新文:隱身地址不完整指南

2023-01-24 18:13
閱讀本文需 25 分鐘
总结 AI 總結
看總結 收起
原文標題:《An incomplete guide to stealth addresses》
原文作者:Vitalik Buterin
原文編譯:Karen,Foresight News


當前以太坊生態系統中最大挑戰之一是隱私。預設情況下,進入公共區塊鏈的任何內容都是公開的,這不僅意味著資產和交易活動,還意味著 ENS 域名、POAP、NFT 和靈魂綁定代幣等。使用一系列以太坊應用程式就意味著你的許多活動會公開給其他任何人查看和分析。

 

我們需要改善這種狀況。然而,到目前為止,關於改善隱私的討論主要圍繞著一個特定的用例,即:ETH 和主流 ERC20 代幣的隱私保護轉移。這篇文章將描述一種不同類別工具的機制和用例,可以在許多其他情況下改善以太坊的隱私狀態,也就是「隱身地址」( stealth addresses)概念。


隱身位址系統是什麼?

 

假設 Alice 想要給 Bob 轉移資產,可能是一定數量的加密貨幣(例如 1 ETH、500 RAI),也可能是 NFT。當 Bob 收到資產時,他不想讓其他人知道該筆資產的接收人是他。隱藏已經轉移發生的事實是不可能的,特別是如果轉移的是一個在鏈上僅存在一個副本的 NFT,不過隱藏誰是接收者可能更可行。

 

Alice 和Bob 更想要的應該是這樣一個支付流程系統,即,Bob 向Alice(或支持ENS 域名)發送某種能接收付款的“地址」編碼,僅此資訊就足以讓Alice(或其他任何人)向他發送資產,而且這與目前的支付工作流程幾乎完全相同。

 

要注意的是,這種隱私性與 Tornado Cash 提供的隱私完全不同。 Tornado Cash 可以隱藏ETH 或主要ERC-20 等主流可替代資產的轉帳(經常用於私下發送給自己),但在為鮮為人知的ERC20 轉帳添加隱私方面非常薄弱,並且根本無法為NFT 轉帳添加隱私。



如上提到的使用加密貨幣進行支付的普通工作流程,增加了隱私性,即,沒有人能知道資產接收人是Bob,而且工作流程未發生改變。


隱身位址是可以由 Alice 或 Bob 產生的位址,但只能由 Bob 控制。 Bob 產生一個支出金鑰(spending key)並對此進行保密,然後使用該金鑰產生一個隱藏元位址(stealth meta-address)。他將這個元地址傳遞給 Alice(或在 ENS 上註冊)。 Alice 可以對該元位址執行計算以產生屬於 Bob 的隱身位址。然後 Alice 可以將她想發送的任何資產發送到這個地址,Bob 將完全控制這些資產。在轉移過程中,Alice 在鏈上發布了一些額外的加密資料(一個臨時公鑰),來幫助 Bob 發現這個位址屬於他。

 

另一種看待它的方式是:隱身地址提供與Bob 相同的隱私屬性,為每筆交易產生一個新地址,但不需要Bob 的任何交互。

 

隱身位址方案的完整工作流程如下所示:



1.Bob 產生他的根支出金鑰(m)和隱身元位址(M)。

2.Bob 新增了一條 ENS 記錄來註冊(M)為 bob.eth 的隱身元位址 bob.eth。

3.我們假設 Alice 知道 Bob 的位址是 bob.eth。 Alice 在 ENS 上尋找 Bob 的隱形元件(M)。

4.Alice 產生一個只有她知道的臨時金鑰,而且她只能使用一次(產生這個特定的隱身位址)。

5.Alice 使用演算法,將她的臨時金鑰和 Bob 的元位址結合起來產生一個隱身位址。她現在可以將資產發送到這個地址。

6.Alice 還產生她的臨時公鑰,並將其發佈到臨時公鑰註冊表(這可以在與第一個將資產發送到這個隱身地址的交易相同的交易中完成)。

7.為了讓 Bob 發現屬於他的隱身地址,Bob 需要掃描臨時公鑰註冊表,以查找自其上次掃描以來任何人發布的整個臨時公鑰列表。

8.對於每個臨時公鑰,Bob 嘗試將其與他的根支出密鑰結合起來產生一個隱身地址,並檢查該地址中是否有任何資產。如果有,Bob 計算該地址的支出金鑰並記住它。


這一切都依賴密碼欺騙的兩種用途。首先,我們需要一對演算法來產生共享金鑰(shared secret):一個演算法使用 Alice 暫存金鑰和 Bob 的元位址,另一個演算法使用 Bob 的根支出金鑰和 Alice 的暫存公鑰。這可以透過多種方式完成;Diffie-Hellman 金鑰交換是建立現代密碼學領域的成果之一,它恰好實現了這一點。

 

但隻共享秘密遠遠不夠:如果我們只是從共享秘密產生一個私鑰,那麼 Alice 和 Bob 都可以從這個位址消費。我們還添加了一個密鑰盲化機制:在一對演算法中,其中Bob 可以將共享密鑰與他的根花費密鑰結合起來,而Alice 可以將共享密鑰與Bob 的元地址結合起來,這樣Alice 就可以產生隱身地址,而Bob 可以為該隱身地址產生支出金鑰,所有這些都無需在隱身地址和Bob 的元地址之間建立公共連結(或一個隱身地址與另一個隱身地址之間)。


使用橢圓形曲線密碼學隱藏位址


使用橢圓曲線密碼學隱藏位址原本是由Peter Todd 於2014 年在比特幣背景下引入的。此技術的工作原理如下:

 

· Bob 產生一個金鑰(m),並計算 M = G * m,其中 G 是橢圓曲線的公認產生點。隱身元位址是(M)。

· Alice 產生一個暫存金鑰(r),並發佈暫存公鑰 R = G * r。

· Alice 可以計算出一個共享金鑰 S = M * r,Bob 也可以計算出相同的共享金鑰 S = m * R。

 ·一般來說,在比特幣和以太坊(包括正確設計的 ERC-4337 帳戶)中,地址是包含用於驗證來自該地址的交易的公鑰的哈希。因此,如果你計算公鑰,就可以計算地址。為了計算公鑰,Alice 或Bob 可以計算P = M + G * hash(S) 

· 要計算該位址的私鑰,Bob 可以計算p = m + hash(S)  ; 

 

這滿足了我們上面的所有要求,而且非常簡單。

 

甚至有一個EIP 試圖為以太坊定義一個隱身位址標準,它既支援這種方法,也為使用者提供了開發其他方法的空間(例如,支援Bob 擁有單獨的支出和查看金鑰,或使用不同的密碼學來實現抗量子安全)。現在你可能會想:隱身位址並不是很難,理論知識已經紮實,採用僅是一個實作細節。然而,問題在於,真正有效的實作還需要透過一些重要的實作細節。


隱身地址與支付交易費用


假設有人寄了一個NFT給你。如果你想要確保隱私,他們會將其發送到您控制的隱身地址。掃描鏈上的臨時公鑰後,你的錢包會自動發現該位址。你現在可以自由證明 NFT 的所有權或將其轉讓給其他人。但有一個問題是,該帳戶中的 ETH 餘額為 0,因此也無法支付交易費用。即使是ERC-4337 代幣付款者也不會奏效,因為它們只適用於可替代的ERC20 代幣。而且你不能從你的主錢包向它發送 ETH,因為那樣你就創建了一個公開可見的鏈接,也就是說沒了隱私性。

 

有一個簡單的方法可以解決這個問題:只需使用 ZK-SNARKs 轉移資金來支付費用。但這會消耗大量的 Gas,光是單次轉帳就會額外消耗數幾十萬 Gas。

 

另一種比較聰明的方法涉及信任專門的交易聚合器(MEV 術語中的搜尋者 searchers)。這些聚合器將允許用戶支付一次以購買一組可用於支付鏈上交易的「tickets」。當使用者需要在一個不包含任何其他內容的隱身位址中花費NFT 時,他們會向聚合器提供其中一張ticket,使用Chaumian 盲法編碼。這是 1980 年代和 1990 年代提出的集中式隱私保護電子現金方案中使用的原始協議。搜尋者接受 ticket,並重複將交易免費包含在他們的捆綁包中,直到交易在一個區塊中被成功接受。

 

隱身位址和分離支出和檢視金鑰


假設Bob 不是只有一個可以做所有事情的主「根支出金鑰」,而是想要一個單獨的根支出金鑰和檢視金鑰。此查看金鑰可以看到 Bob 的所有隱身地址,但不能進行支出。

 

在橢圓曲線世界中,這可以使用一個非常簡單的密碼技巧來解決:


· Bob 的元位址(M)現在的形式為(K, V),編碼G * k 和G * v,其中k 是支出金鑰,v 是檢視金鑰。

· 共用金鑰現在為 S = V * r = v * R,其中 r 仍是 Alice 的暫存金鑰,R 仍然是 Alice 發佈的暫存公鑰。

· 隱身位址的公鑰是 P = K + G * hash(S),私鑰是 p = k + hash(S)。

 

第一步驟(產生共享秘密)使用檢視金鑰,第二個步驟(Alice 和Bob 的平行演算法產生隱身位址及其私鑰)使用根支出密鑰。

 

這有很多用例。例如,如果Bob 想要接收POAP,那麼Bob 可以給他的POAP 錢包(或甚至是一個不太安全的Web 介面)查看金鑰來掃描鏈並查看他的所有POAP,而不需要為這個介面花費那些POAP 的權力。


隱身位址與易掃描


為了更容易掃描整個臨時公鑰集,一種技術是向每個臨時公鑰添加一個視圖標籤。在上述機制中執行此操作的一種方法是使視圖標籤成為共享金鑰的一個位元組(例如,S modulo 256 的x 座標,或hash(S) 的第一個位元組。

 

這樣,Bob 只需要為每個臨時公鑰執行一次橢圓曲線乘法來計算共享密鑰,由於有了視圖標籤,也更容易進行掃描。


隱身位址與抗量子安全性


上面的方案依賴橢圓曲線,不過儘管這種方案效果很好,但不幸的是,容易受到量子電腦的攻擊。演算法。 /2019/1321.pdf" rel="noopener noreferrer" target="_blank">橢圓曲線同源是一種非常不同的基於橢圓曲線的數學構造,具有線性特性,可以讓我們使用與上面所做的類似的密碼技巧,但巧妙地避免了構造可能容易受到量子電腦離散對數攻擊的循環群。弱點是其高度複雜的底層數學,以及在這種複雜性下隱藏可能的攻擊的風險。 io/" rel="noopener noreferrer" target="_blank">但其他協定仍然安全。同源的主要優勢是相對較小的密鑰大小,以及直接移植多種基於橢圓曲線的方法的能力。 style="text-align: center;">A 3-isogeny in CSIDH


格(lattices)是一種非常不同的密碼結構,依賴比橢圓曲線同構簡單的數學,並且能夠做一些非常強大的事情(例如完全同態加密)。隱身地址方案可以建立在格上,儘管設計最好的方案是一個懸而未決的問題。然而,基於格的結構往往具有更大的密鑰大小。


全同態加密,格的應用。 FHE 還可以用於以不同的方式幫助隱身地址協議:幫助 Bob 外包檢查整個鏈中是否包含資產的隱身地址的計算,而無需透露他的視圖密鑰。


第三種方法是從通用黑盒原語建立隱身位址的方案。此方案的共用金鑰產生部分直接對應到密鑰交換,這是公鑰加密系統中的重要組成部分。更難的部分是讓 Alice 只產生隱身位址(而不是支出金鑰)並讓 Bob 產生支出金鑰的平行演算法。

 

不幸的是,你無法使用比建立公鑰加密系統所需的更簡單的成分來建立隱身位址。有一個簡單的證明是,可以用一個隱身位址方案來建構一個公鑰加密系統。如果Alice 想給Bob 加密一條訊息,她可以發送N 筆交易,每筆交易要么發往Bob 的一個隱身地址,要么發往一個屬於她自己的隱身地址,Bob 可以看到他收到了哪些交易來讀取訊息。這很重要,在數學證明中你不能只用哈希來做公鑰加密,而你可以只用哈希來做零知識證明,因此,隱身位址不能只用哈希來完成。

 

這確實是一種使用相對簡單成分的方法:零知識證明,可以由雜湊和(金鑰隱藏)公鑰加密組成。 Bob 的元位址是一個公開的加密金鑰加上一個雜湊 h = hash(x),他的支出金鑰是對應的解密金鑰加上 x。要建立一個隱身位址,Alice 會產生一個值 c,並將 Bob 可讀的 c 加密作為她的臨時公鑰發布。該地址本身是一個ERC-4337 帳戶,其代碼通過要求交易提供零知識證明來驗證交易,證明值x 和c 的所有權,使得k = hash(hash(x), c)(其中k 是帳戶代碼的一部分)。知道 x 和 c,Bob 就可以自己重建地址及代碼。



(c) 的加密不會告訴Bob 以外的其他任何人任何信息,並且(k) 是一個哈希,它幾乎不會透露有關c 的任何事情。錢包程式碼本身只包含 (k),(c) 私有意味著 (k) 無法追溯到 (h)。

 

然而,這需要一個 STARK。最終,我認為後量子以太坊世界很可能涉及使用許多STARK 的應用,因此我提倡像此處描述的聚合協定將所有這些STARK 組合成一個遞歸STARK 以節省空間。


隱身地址和社交恢復以及多L2 錢包

 

很長一段時間以來,我一直很感興趣社交恢復錢包,社交恢復錢包具有多重簽名機制,其密鑰能在機構、你的其他設備和朋友的某種組合之間共享。如若你遺失主要金鑰,絕大多數金鑰允許恢復帳戶存取。

 

然而,社交恢復錢包不能很好地與隱身地址結合:如果你必須恢復你的帳戶(改變控制它的私鑰),你還必須執行一些步驟來改變你的N 個隱身錢包的帳戶驗證邏輯,這將需要N 筆交易,以高昂的費用、便利性和隱私成本為代價。

 

社交恢復和多個L2 協議的相互作用也存在類似的擔憂:如果你在Optimism、Arbitrum、StarkNet、Scroll、Polygon 上有帳戶,出於擴展原因有十幾個並行實例,並且您在每個實例上都有一個帳戶,那麼更改密鑰可能是一個非常複雜的操作。


更改多條鏈中多個帳戶的金鑰是一項巨大的工作。


也許你可以使用一些自動化軟體在兩週的時間跨度內以隨機間隔將資產轉移到新的隱身地址,以降低基於時間的關聯的有效性。但這遠非完美。另一種方法是在監護人之間秘密共享根密鑰,而不是使用智能合約復原。但是,這會消除停用監護人幫助恢復您帳戶的權力的能力,因此存在長期風險。

 

一種更複雜的方法涉及零知識證明。這允許許多帳戶,甚至跨越許多L2 協議,在某處(在基礎鏈上或某些L2 上)由單個k 值控制,其中更改該值足以更改所有帳戶的所有權,所有這些都不會洩你的多個帳戶之間的聯繫。


結論


目前基本的隱身位址可以快速實施,並且可以顯著提高以太坊上使用者的隱私。我認為出於其他與隱私相關的原因,錢包應該開始轉向更原生的多地址模型(例如,為你與之互動的每個應用程式創建一個新地址可能是一種選擇)。

 

然而,隱身地址確實會帶來一些長期的可用性問題,例如社交恢復的困難。從長遠來看,這些問題是可以解決的,不過隱身地址生態系統看起來確實嚴重依賴零知識證明。


原文連結



歡迎加入律動 BlockBeats 官方社群:

Telegram 訂閱群:https://t.me/theblockbeats

Telegram 交流群:https://t.me/BlockBeats_App

Twitter 官方帳號:https://twitter.com/BlockBeatsAsia

举报 糾錯/舉報
本平台現已全面集成Farcaster協議, 如果您已有Farcaster帳戶, 可以登錄 後發表評論
選擇文庫
新增文庫
取消
完成
新增文庫
僅自己可見
公開
保存
糾錯/舉報
提交