Мені подобається, що все більше досліджень проводиться на рівні конфіденційності на рівні RPC. Це недостатньо вивчена, недооцінена частина конфіденційності Ethereum, яка заслуговує на рішення. На жаль, обертові ПКС не є таким рішенням, принаймні у формі, описаній тут. І ось чому 🧵

Проблема 1: Жоден провайдер не повинен мати можливість пов'язати вашу адресу Ethereum з вашою IP-адресою. Проблема 2: Жоден провайдер не повинен мати можливість пов'язати дві ваші адреси Ethereum одна з одною. Особливо важливо в контексті прихованих адрес.

Перше запропоноване рішення не вирішує жодної з проблем. Фактично, це погіршує проблему 1: замість одного провайдера, який знає вашу IP-адресу та адреси Ethereum, тепер кілька таких провайдерів знають їх обидва.

Друге рішення вирішує проблему 1 шляхом введення проміжного програмного забезпечення в TEE. По суті, це сліпий проксі, для якого сліпота забезпечується TEE. Але проблема 2 залишається невирішеною: провайдери все ще можуть пов'язувати ваші адреси Ethereum одна з одною.

TEE не є куленепробивними. Але навіть якщо ми припустимо, що вони працюють належним чином, клієнт все одно повинен переконатися, що проміжне програмне забезпечення, з яким він спілкується, взагалі працює в TEE. В іншому випадку клієнт (гаманець) не може бути впевнений, що проміжне програмне забезпечення насправді не реєструє все.

Клієнт може переконатися в цьому, виконавши танець атестації навантаження. Це можливо, але складно в реалізації. Я не бачив реального втілення цього на практиці, і мені незрозуміло, чи буде це простіше впровадити, ніж просто інтегрувати справжній мікснет.

Проксі повинен бути сліпим до того, через що він проходить. Криптографія вирішує цю проблему без необхідності в припущеннях про довіру TEE. Мікснети, такі як Tor/Nym/HOPR, працюють таким чином: шифрують корисне навантаження кількома рівнями шифрування, де кожен перехід знімає один шар шифрування з onion.

Чому сьогодні не використовують мікснети? - Користувачі не вимагають конфіденційності на рівні RPC від розробників своїх гаманців. Walletbeat виправляє це. - <100 мс RPC очікування UX. Mixnets/middleware додають затримку. - Інтеграція в браузерні гаманці вимагає повторного впровадження TLS в JS для шифрування останнього переходу.

Самі по собі мікснети також не вирішують проблему 2. Проблема полягає в тому, що наївна ротація RPC (випадковий провайдер на кожен запит) насправді гірша для конфіденційності: це означає, що кілька провайдерів отримують перегляд кількох ваших адрес з часом.

Краще рішення: для RPC про 'address', завжди надсилайте його провайдеру #'hash(address) за модулем num_providers'. Іншими словами, запити про одну і ту ж адресу надходять до одного і того ж провайдера RPC. Це гарантує, що жоден провайдер не дізнається ваш повний набір адрес.

Також краще, щоб провайдерів було більше, ніж адрес. Таким чином, кожен провайдер дізнається або одну з ваших адрес, або жодної; Ніколи не множинні. Але справжнє виправлення? - Запустіть свій власний вузол! - Попросіть розробника вашого гаманця почати піклуватися про конфіденційність на рівні RPC.

Речі, які я не висвітлив, але також мають значення: - Кореляційні атаки RPC Timing. - Гаманці, які шукають баланс кількох адрес в одному RPC. - Запити, що не належать Ethereum, які призводять до витоку аналогічних даних. У сьогоднішніх гаманцях повно таких; запитайте мене, звідки я знаю. - L2 з централізованими кінцевими точками. (лол)

Навіть якщо ця тема здається критичною щодо роботи @jimouris, я хочу наголосити, що вона не задумана як данк. Я з великою повагою ставлюся до кожного, хто насправді береться за вирішення цієї проблеми. Це недостатньо вивчено і потребує більшої уваги, тому приємно бачити, що люди працюють над цим.