我喜歡更多關於 RPC 級隱私的研究。 這是乙太坊隱私中研究不足、未被充分重視的部分，值得解決方案。 不幸的是，輪換 RPC 不是那個解決方案，至少在此處描述的形式中是這樣。原因如下 🧵

問題 1：任何供應商都不應能夠將您的乙太坊位址與您的 IP 位址相關聯。 問題 2：任何供應商都不應該能夠將您的兩個乙太坊位址相互關聯。 在隱形位址的背景下尤為重要。

提出的第一個解決方案既不能解決這兩個問題。 事實上，它使問題 1 變得更糟：現在多個這樣的供應商都知道它們，而不是一個知道你的 IP 和乙太坊位址的供應商。

第二種解決方案通過在 TEE 中引入中間件來解決問題 1。它本質上是一個盲代理，TEE 為其提供盲性。 但問題 2 仍未解決：供應商仍然可以將您的乙太坊位址相互關聯。

三通不是防彈的。但是，即使我們假設它們按預期工作，用戶端仍然需要驗證他們正在通信的中間件是否實際上在 TEE 中運行。否則，用戶端（錢包）無法確定中間件實際上沒有記錄所有內容。

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

代理應該對它所經過的內容視而不見。密碼學解決了這個問題，不需要 TEE 信任假設。 Tor/Nym/HOPR 等混合網路的工作方式是這樣的：在多層加密中加密有效負載，其中每一跳都會剝掉一層加密。

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

僅靠混合網也無法解決問題 2。 問題仍然是，天真地輪換 RPC（每個請求的隨機提供者）實際上對隱私更不利：這意味著隨著時間的推移，多個提供者會查看您的多個位址。

更好的解決方案：對於關於 'address' 的 RPC，始終將其發送給提供者 #'hash（address） modulo num_providers'。 換句話說，有關同一地址的查詢將轉到同一 RPC 提供者。 這可確保沒有供應商會知道您的完整位址集。

擁有比擁有位址更多的供應商也更好。這樣，每個供應商都會學習您的一個位址，或者不學習任何位址;永遠不要多個。 但真正的解決辦法是什麼？ - 運行自己的節點！ - 請您的錢包開發者開始關心 RPC 級別的隱私。

我沒有涵蓋但也很重要的事情： - RPC 時序關聯攻擊。 - 錢包在單個 RPC 中查找多個地址的餘額。 - 洩露類似數據的非乙太坊請求。今天的錢包里充滿了這些;問我怎麼知道的。 - 具有集中式端點的 L2。（笑）

Even if this thread appears critical of @jimouris's work, I want to emphasize that it is not intended as a dunk. I highly respect anyone who actually steps up to tackle this problem. This is under-researched and needs more attention, so it's heartening to see folks working on it.