我喜歡越來越多的研究投入到RPC層級的隱私。 這是以太坊隱私中一個被低估且研究不足的部分，值得尋找解決方案。 不幸的是，旋轉RPC並不是那個解決方案，至少在這裡描述的形式下是如此。這就是為什麼 🧵

問題 1: 沒有任何提供者應該能夠將您的以太坊地址與您的 IP 地址關聯。 問題 2: 沒有任何提供者應該能夠將您的兩個以太坊地址彼此關聯。 這在隱形地址的背景下尤其重要。

所提出的第一個解決方案並未解決任何問題。 事實上，它使問題 1 變得更糟：現在不再只有一個提供者知道你的 IP 和以太坊地址，而是 𝙢𝙪𝙡𝙩𝙞𝙥𝙡𝙚 這樣的提供者都知道它們。

第二個解決方案通過在可信執行環境（TEE）中引入中介來解決問題1。它本質上是一個盲代理，盲目性由TEE提供。 但問題2仍然未解決：提供者仍然可以將您的以太坊地址彼此關聯。

TEEs 並不是萬無一失的。但即使我們假設它們按預期運作，客戶端仍然需要驗證他們所交談的中介軟體是否實際上在 TEE 中運行。否則，客戶端（錢包）無法確定中介軟體是否真的在記錄所有內容。

客戶可以通過執行工作負載驗證舞蹈來驗證這一點。這是可能的，但實施起來很複雜。 我還沒有看到這在實踐中的真正實現，對我來說不清楚這是否比僅僅整合一個實際的混合網絡更容易實施。

代理伺服器應該對其傳遞的內容保持盲目。密碼學在不需要 TEE 信任假設的情況下解決了這個問題。 像 Tor/Nym/HOPR 這樣的混合網絡就是這樣運作的：將有效載荷加密為多層加密，每一跳都去除一層洋蔥加密。

為什麼今天不使用混合網絡？ - 用戶並不要求他們的錢包開發者提供RPC級別的隱私。Walletbeat解決了這個問題。 - <100ms的RPC用戶體驗期望。混合網絡/中介會增加延遲。 - 在瀏覽器錢包中集成需要在JS中重新實現TLS以加密最後一跳。

僅僅依賴混合網絡也無法解決問題 2。 問題在於，天真地輪換 RPC（每次請求隨機提供者）實際上對隱私來說是 𝙬𝙤𝙧𝙨𝙚：這意味著多個提供者隨著時間的推移會看到你多個地址的情況。

更好的解決方案：對於有關 `address` 的 RPC，始終將其發送到提供者 #`hash(address) modulo num_providers`。 換句話說，對同一地址的查詢將發送到同一 RPC 提供者。 這確保沒有提供者能夠了解您的完整地址集。

擁有的提供者數量應該多於地址數量。這樣，每個提供者要麼學到你的其中一個地址，要麼什麼都不學到；絕對不會學到多個。 但真正的解決方案是？ - 自行運行節點！ - 要求你的錢包開發者開始關注RPC層級的隱私。

我沒有涵蓋但也很重要的事情： - RPC 時間相關攻擊。 - 錢包在單個 RPC 中查詢多個地址的餘額。 - 泄露類似數據的非以太坊請求。今天的錢包充滿了這些；問我我是怎麼知道的。 - 具有集中端點的 L2s。（哈哈）

即使這個討論串看起來對 @jimouris 的工作持批評態度，我想強調這並不是一種貶低。 我非常尊重任何真正願意站出來解決這個問題的人。這個問題的研究不足，需要更多的關注，因此看到人們在努力解決它讓人感到振奮。