RPC レベルのプライバシーに関する研究がさらに進んでいるのが気に入っています。 これは、イーサリアムのプライバシーの中で十分に研究されておらず、過小評価されている部分であり、解決策に値します。 残念ながら、RPC をローテーションすることは、少なくともここで説明する形式では、その解決策ではありません。その理由🧵は次のとおりです

問題 1: プロバイダーは、イーサリアム アドレスを IP アドレスに関連付けることができなければなりません。 問題 2: プロバイダーは、2 つのイーサリアム アドレスを相互に関連付けることができなければなりません。 ステルスアドレスのコンテキストでは特に重要です。

最初に提案された解決策は、どちらの問題も解決しません。 実際、問題 1 はさらに悪化します: IP アドレスとイーサリアム アドレスを知っているプロバイダーが 1 つではなく、複数のプロバイダーが両方を知っています。

2 番目のソリューションは、TEE にミドルウェアを導入することで問題 1 を解決します。これは本質的にブラインドプロキシであり、TEEによってブラインドが提供されます。 しかし、問題 2 は未解決のままです: プロバイダーは依然としてイーサリアム アドレスを相互に関連付けることができます。

TEEは防弾ではありません。しかし、意図したとおりに動作すると仮定したとしても、クライアントは、通信しているミドルウェアが実際に TEE で実行されていることを確認する必要があります。そうしないと、クライアント (ウォレット) は、ミドルウェアが実際にすべてをログに記録していないことを確認できません。

クライアントは、ワークロード構成証明ダンスを実行することでこれを確認できます。可能ですが、実装は複雑です。 私はこれを実際に実装したのを見たことがなく、実際のミックスネットを統合するよりも実装が簡単かどうかはわかりません。

プロキシは、通過する内容を知らないようにする必要があります。暗号化は、TEEの信頼の仮定を必要とせずにこれを解決します。 Tor/Nym/HOPR などのミックスネットは次のように機能します。ペイロードを複数の暗号化層で暗号化し、各ホップがタマネギから 1 つの暗号化層を剥がします。

なぜ今日ミックスネットは使われていないのですか? - ユーザーはウォレット開発者にRPCレベルのプライバシーを求めません。Walletbeat はこれを修正します。 - <100ms RPC UX の期待。ミックスネット/ミドルウェアはレイテンシーを追加します。 - ブラウザウォレットに統合するには、JSにTLSを再実装してラストホップを暗号化する必要があります。

ミックスネットだけでは問題 2 も解決できません。 問題は、RPCを素朴にローテーションすること(リクエストごとにランダムなプロバイダー)は、実際にはプライバシーにとって悪いことです:それは、複数のプロバイダーが時間の経過とともに複数のアドレスのビューを取得することを意味します。

より良い解決策: 'address' に関する RPC の場合は、常にプロバイダー #'hash(address) modulo num_providers' に送信してください。 つまり、同じアドレスに関するクエリは、同じ RPC プロバイダーに送信されます。 これにより、プロバイダーがアドレスの完全なセットを学習することはありません。

また、アドレスよりも多くのプロバイダーを持つ方が良いです。このようにして、各プロバイダーはアドレスの 1 つを学習するか、まったく学習しません。決して複数ではありません。 しかし、本当の解決策は? - 独自のノードを実行してください! - ウォレット開発者に、RPC レベルのプライバシーに気を配るように依頼してください。

私が取り上げなかったが、重要なこと: - RPC タイミング相関攻撃。 - ウォレットは、単一のRPCで複数のアドレスの残高を検索します。 - 同様のデータを漏洩するイーサリアム以外のリクエスト。今日の財布にはそれらがいっぱいです。どうやって知っているのか聞いてください。 - 一元化されたエンドポイントを備えた L2。(笑)

このスレッドが@jimourisの作品に批判的であるように見えても、ダンクを意図したものではないことを強調したいと思います。 私は、この問題に実際に取り組むために立ち上がる人を非常に尊敬しています。これは十分に研究されておらず、もっと注意が必要なので、人々がそれに取り組んでいるのを見るのは心強いことです。