Мне нравится, что больше исследований посвящено приватности на уровне RPC.
Это недостаточно исследованная и недооцененная часть приватности Ethereum, которая заслуживает решения.
К сожалению, ротация RPC не является этим решением, по крайней мере, в той форме, которая описана здесь. Вот почему 🧵
Проблема 1: Ни один провайдер не должен иметь возможность связать ваш адрес Ethereum с вашим IP-адресом.
Проблема 2: Ни один провайдер не должен иметь возможность связывать два ваших адреса Ethereum друг с другом.
Особенно важно в контексте скрытых адресов.
Первое предложенное решение не решает ни одной из проблем.
На самом деле, оно делает проблему 1 𝙬𝙤𝙧𝙨𝙚: вместо одного провайдера, который знает ваш IP и адреса Ethereum, теперь 𝙢𝙪𝙡𝙩𝙞𝙥𝙡𝙚 такие провайдеры знают их оба.
Я вижу два способа реализации вращающихся RPC:
➡️ 1. Реализовать эту функциональность непосредственно в кошельках.
Преимущества 👍
• Быстро
• Недостатки 👎
• Это нельзя адаптировать к любому кошельку, так как это нужно будет реализовывать каждый раз.
• **Что более важно** RPC все равно видят IP-адрес пользователя.
Второе решение решает проблему 1, вводя промежуточное ПО в TEE. Это по сути слепой прокси, для которого слепота обеспечивается TEE.
Но проблема 2 остается нерешенной: Провайдеры все еще могут связывать ваши адреса Ethereum друг с другом.
TEE не являются непроницаемыми. Но даже если предположить, что они работают как задумано, клиент все равно должен убедиться, что промежуточное ПО, с которым он общается, действительно работает в TEE. В противном случае клиент (кошелек) не может быть уверен, что промежуточное ПО не записывает все.
Клиент может это проверить, выполнив танец аттестации рабочей нагрузки. Это возможно, но сложно реализовать.
Я не видел реальной реализации этого на практике, и мне неясно, будет ли это проще реализовать, чем просто интегрировать настоящий микснет.
Прокси должен быть слеп к тому, что он передает. Криптография решает эту задачу без необходимости в доверительных предположениях TEE.
Смешанные сети, такие как Tor/Nym/HOPR, работают таким образом: шифруйте полезную нагрузку в несколько слоев шифрования, где каждая передача снимает один слой шифрования с луковицы.
Почему микснеты не используются сегодня?
- Пользователи не требуют конфиденциальности на уровне RPC от разработчиков кошельков. Walletbeat это исправляет.
- Ожидания UX для RPC менее 100 мс. Микснеты/промежуточное ПО добавляют задержку.
- Интеграция в браузерные кошельки требует повторной реализации TLS на JS для шифрования последнего хопа.
Микснеты сами по себе также не решают проблему 2.
Проблема остается в том, что наивная ротация RPC (случайный провайдер при каждом запросе) на самом деле 𝙬𝙤𝙧𝙨𝙚 для конфиденциальности: это означает, что несколько провайдеров получают доступ к нескольким вашим адресам с течением времени.
Лучшее решение: для RPC по `address` всегда отправляйте его провайдеру #`hash(address) modulo num_providers`.
Другими словами, запросы по одному и тому же адресу идут к одному и тому же RPC провайдеру.
Это гарантирует, что ни один провайдер не узнает ваш полный набор адресов.
Также лучше иметь больше провайдеров, чем у вас адресов. Таким образом, каждый провайдер узнает либо один из ваших адресов, либо ни один; никогда не несколько.
Но настоящее решение?
- Запустите свой собственный узел!
- Попросите разработчика вашего кошелька начать заботиться о конфиденциальности на уровне RPC.
Вещи, которые я не упомянул, но которые тоже важны:
- Атаки на корреляцию времени RPC.
- Кошельки, запрашивающие баланс нескольких адресов за один RPC.
- Запросы, не относящиеся к Ethereum, которые утечкуют аналогичные данные. Сегодняшние кошельки полны таких; спросите меня, как я это знаю.
- L2 с централизованными конечными точками. (лол)
Даже если эта тема кажется критической по отношению к работе @jimouris, я хочу подчеркнуть, что это не предназначено для того, чтобы унизить.
Я очень уважаю тех, кто действительно берется за решение этой проблемы. Это недостаточно исследовано и требует большего внимания, поэтому приятно видеть людей, работающих над этим.
3,1 тыс.
25
Содержание этой страницы предоставляется третьими сторонами. OKX не является автором цитируемых статей и не имеет на них авторских прав, если не указано иное. Материалы предоставляются исключительно в информационных целях и не отражают мнения OKX. Материалы не являются инвестиционным советом и призывом к покупке или продаже цифровых активов. Раздел использует ИИ для создания обзоров и кратких содержаний предоставленных материалов. Обратите внимание, что информация, сгенерированная ИИ, может быть неточной и непоследовательной. Для получения полной информации изучите соответствующую оригинальную статью. OKX не несет ответственности за материалы, содержащиеся на сторонних сайтах. Цифровые активы, в том числе стейблкоины и NFT, подвержены высокому риску, а их стоимость может сильно колебаться. Перед торговлей и покупкой цифровых активов оцените ваше финансовое состояние и принимайте только взвешенные решения.