Saya suka bahwa lebih banyak penelitian dilakukan tentang privasi tingkat RPC. Ini adalah bagian yang kurang diteliti dan kurang dihargai dari privasi Ethereum yang layak mendapat solusi. Sayangnya, memutar RPC bukanlah solusi itu, setidaknya dalam bentuk yang dijelaskan di sini. Inilah alasannya 🧵
Dimitris
Dimitris24 Jul, 23.44
Ide sederhana: server antara dompet dan penyedia RPC. Server secara acak menggunakan RPC yang berbeda untuk setiap permintaan. Jalankan ini dalam TEE 🔒! Cloud tidak melihat permintaan Anda (hati-hati, mereka masih metadata!) - dan RPC tidak melihat IP Anda (mereka melihat cloud)
Masalah 1: Tidak ada penyedia yang dapat mengaitkan alamat Ethereum Anda dengan alamat IP Anda. Masalah 2: Tidak ada penyedia yang dapat mengaitkan dua alamat Ethereum Anda satu sama lain. Sangat penting dalam konteks alamat siluman.
Solusi pertama yang diusulkan tidak menyelesaikan masalah tersebut. Faktanya, itu membuat masalah 1 lebih buruk: alih-alih satu penyedia yang mengetahui alamat IP dan Ethereum Anda, sekarang beberapa penyedia tersebut mengetahui keduanya.
Dimitris
Dimitris24 Jul, 23.44
Saya melihat dua cara untuk menerapkan RPC berputar: ➡️ 1. Terapkan fungsionalitas ini di dompet secara langsung. Keuntungan 👍 •Cepat •Kerugian 👎 • Ini tidak dapat disesuaikan dengan dompet apa pun karena perlu diterapkan setiap saat. • **Lebih penting lagi** RPC masih melihat IP pengguna
Solusi kedua memecahkan masalah 1 dengan memperkenalkan middleware di TEE. Ini pada dasarnya adalah proksi buta, yang kebutaan disediakan oleh TEE. Tetapi masalah 2 tetap belum terpecahkan: Penyedia masih dapat mengaitkan alamat Ethereum Anda satu sama lain.
Dimitris
Dimitris24 Jul, 23.44
Ide sederhana: server antara dompet dan penyedia RPC. Server secara acak menggunakan RPC yang berbeda untuk setiap permintaan. Jalankan ini dalam TEE 🔒! Cloud tidak melihat permintaan Anda (hati-hati, mereka masih metadata!) - dan RPC tidak melihat IP Anda (mereka melihat cloud)
TEE tidak antipeluru. Tetapi bahkan jika kita berasumsi bahwa mereka bekerja sebagaimana mestinya, klien masih perlu memverifikasi bahwa middleware yang mereka ajak bicara benar-benar berjalan di TEE sama sekali. Jika tidak, klien (dompet) tidak dapat memastikan middleware tidak benar-benar mencatat semuanya.
Klien dapat memverifikasi ini dengan melakukan tarian pengesahan beban kerja. Itu mungkin, tetapi rumit untuk diterapkan. Saya belum melihat implementasi nyata dari ini dalam praktiknya, dan tidak jelas bagi saya apakah itu akan lebih mudah diterapkan daripada hanya mengintegrasikan mixnet yang sebenarnya.
Proxy harus buta terhadap apa yang dilewatinya. Kriptografi memecahkan ini tanpa memerlukan asumsi kepercayaan TEE. Mixnet seperti Tor/Nym/HOPR bekerja dengan cara ini: Enkripsi muatan dalam beberapa lapisan enkripsi, di mana setiap lompatan mengupas satu lapisan enkripsi dari bawang.
Mengapa mixnet tidak digunakan saat ini? - Pengguna tidak meminta privasi tingkat RPC dari pengembang dompet mereka. Walletbeat memperbaikinya. - <Ekspektasi UX RPC 100ms. Mixnet/middleware menambahkan latensi. - Integrasi di dompet browser memerlukan penerapan ulang TLS di JS untuk mengenkripsi lompatan terakhir.
Mixnet saja juga tidak menyelesaikan masalah 2. Masalahnya tetap bahwa memutar RPC secara naif (penyedia acak pada setiap permintaan) sebenarnya lebih buruk untuk privasi: itu berarti beberapa penyedia mendapatkan tampilan beberapa alamat Anda dari waktu ke waktu.
Solusi yang lebih baik: untuk RPC tentang 'alamat', selalu kirimkan ke penyedia #'hash(address) modulo num_providers'. Dengan kata lain, kueri tentang alamat yang sama masuk ke penyedia RPC yang sama. Ini memastikan tidak ada penyedia yang mempelajari rangkaian lengkap alamat Anda.
Juga lebih baik memiliki lebih banyak penyedia daripada alamat Anda. Dengan cara ini, setiap penyedia mempelajari salah satu alamat Anda, atau tidak sama sekali; tidak pernah berlipat ganda. Tapi perbaikan yang sebenarnya? - Jalankan node Anda sendiri! - Minta pengembang dompet Anda untuk mulai peduli dengan privasi tingkat RPC.
Hal-hal yang tidak saya bahas tetapi juga penting: - Serangan korelasi waktu RPC. - Dompet mencari saldo beberapa alamat dalam satu RPC. - Permintaan non-Ethereum yang membocorkan data serupa. Dompet hari ini penuh dengan itu; tanyakan padaku bagaimana aku tahu. - L2 dengan titik akhir terpusat. (lol)
Bahkan jika utas ini tampak kritis terhadap karya @jimouris, saya ingin menekankan bahwa itu tidak dimaksudkan sebagai dunk. Saya sangat menghormati siapa pun yang benar-benar melangkah untuk mengatasi masalah ini. Ini kurang diteliti dan membutuhkan lebih banyak perhatian, jadi sangat menggembirakan melihat orang-orang mengerjakannya.
4,9K