Доказательство Validator: Простая схема анонимного подтверждения полномочий для DHT Ethereum

Введение

В дорожную карту Ethereum включена технология масштабирования под названием Data Availability Sampling (DAS) 6. DAS вводит новые <a href="https://notes.ethereum.org/@djrtwo/das-requirements"> требования. 4 сетевом стеке Ethereum, что требует реализации специализированных сетевых протоколов 7. Один из выдающихся <a href="https://notes.ethereum.org/@dankrad/S-Kademlia-DAS"> протоколов. Предложение 4 использует распределенную хэш-таблицу (DHT) на базе Kademlia 2 для хранения и извлечения образцов данных.

Однако DHT 4 подвержены атакам Sybil: Злоумышленник, контролирующий большое количество узлов DHT, может сделать образцы DAS недоступными. Чтобы противостоять этой угрозе, можно создать сетевой уровень с высоким уровнем доверия, состоящий исключительно из валидаторов цепочек маячков. Такая мера безопасности значительно повышает барьер для злоумышленников, поскольку теперь они должны ставить на кон свой собственный ETH, чтобы атаковать DHT.

В этом посте мы представляем протокол доказательства валидатора, который позволяет участникам DHT продемонстрировать с нулевым знанием дела, что они являются валидатором Ethereum.

Мотивация: Атака "сокрытия образца" на DAS

В этом разделе мы мотивируем доказательство протокола валидатора, описывая атаку Sybil на выборку доступности данных.

Протокол DAS вращается вокруг создателя блока, обеспечивающего доступность данных блока, чтобы клиенты могли их получить. Существующие подходы предполагают разбиение данных на выборки, и участники сети получают только те выборки, которые относятся к их интересам.

)

Рассмотрим сценарий, в котором злоумышленник Sybil хочет помешать участникам сети получать образцы от узла-жертвы, который отвечает за предоставление образца. Как показано на рисунке выше, злоумышленник генерирует множество идентификаторов узлов, которые близки к идентификатору узла жертвы. Окружая узел жертвы своими собственными узлами, злоумышленник мешает клиентам обнаружить узел жертвы, поскольку злые узлы будут намеренно скрывать информацию о существовании жертвы.

Более подробную информацию о таких атаках Sybil см. в недавней научной статье 2 об атаках DHT Eclipse. Более того, <a href="https://notes.ethereum.org/@dankrad/S-Kademlia-DAS#SKademlia-модификации"> Dankrad's Предложение по сетевому протоколу DAS 8 описывает, как протокол S/Kademlia DHT страдает от таких атак, и показывает необходимость протокола доказательства валидности.

Доказательство наличия валидатора

Описанная выше атака мотивирует необходимость создания протокола доказательства валидатора: Если только валидаторы могут присоединиться к DHT, то злоумышленник, желающий провести атаку Sybil, должен также поставить на карту большое количество ETH.

Используя наш протокол подтверждения валидатора, мы гарантируем, что только валидаторы цепочки маяков могут присоединиться к DHT и что каждый валидатор получает уникальный идентификатор DHT.

Кроме того, для обеспечения устойчивости валидаторов к DoS, мы также стремимся скрыть личность валидаторов на сетевом уровне. То есть, мы не хотим, чтобы злоумышленники могли определить, какой узел DHT соответствует какому валидатору.

Чтобы выполнить эти задачи, протокол доказательства валидности должен отвечать следующим требованиям:

• Уникальность: Каждый валидатор цепочки маячков должен быть способен получить единственную, уникальную пару ключей. Это свойство не только ограничивает количество узлов, которые может сгенерировать злоумышленник Sybil, но и позволяет участникам сети локально наказывать непослушные узлы, занося их производную пару ключей в список.
• Конфиденциальность: Недоброжелатели не должны узнать, какой валидатор соответствует определенному производному открытому ключу.
• Время проверки: Процесс проверки протокола должен быть эффективным и занимать менее 200 мс на узел, позволяя каждому узлу изучать не менее пяти новых узлов в секунду

Такой протокол доказательства валидатора будет использоваться Бобом во время установления соединения на уровне DHT, чтобы Алиса знала, что она разговаривает с валидатором.

Доказательство протокола валидатора

Наш протокол доказательства валидатора по сути является простой анонимной схемой проверки полномочий. Его цель - дать Алисе возможность сгенерировать уникальный производный ключ, обозначаемый как D, тогда и только тогда, когда она является валидатором. Впоследствии Алиса использует этот полученный ключ D на сетевом уровне.

При разработке этого протокола мы стремились создать решение, которое было бы простым в реализации и анализе, а также обеспечивало бы эффективное выполнение изложенных требований.

Обзор протокола

В протоколе используется подпротокол доказательства принадлежности, в котором Алиса доказывает, что она является валидатором, демонстрируя знание секретного хэш-пред-образа с помощью ZK-доказательств. Затем Алиса строит уникальную пару ключей, полученную из этого секретного хэш-представления.

Подпротокол доказательства членства может быть создан различными методами. В этом посте мы покажем протокол, использующий деревья Меркла, и второй протокол, использующий поиск.

Хотя оба подхода демонстрируют приемлемую эффективность, они имеют различные компромиссы. Деревья Меркла полагаются на хэш-функции, дружественные SNARK, такие как Poseidon (которые можно считать экспериментальными). С другой стороны, эффективные протоколы поиска полагаются на доверенную установку размером, равным размеру набора валидаторов (в настоящее время 700 тыс. валидаторов, но их количество растет).

Теперь давайте погрузимся в протоколы:

Подход №1: Деревья Меркла

Деревья Меркла широко использовались для доказательства принадлежности (например. см. Семафор 3). Вот пространство компромиссов при разработке доказательства принадлежности с использованием деревьев Меркла:

• Положительно: Нет необходимости в доверенной настройке
• Положительно: Простота понимания
• Отрицательные: Полагается на дружественные SNARK хэш-функции, такие как Poseidon
• Отрицательное: Медленное создание доказательств

Ниже мы опишем доказательство протокола валидатора, основанного на деревьях Меркла:

Протокол доказательства валидатора с использованием деревьев Меркле

)

В конце протокола Алиса может использовать D в DHT для подписи сообщений и получения своего уникального идентификатора узла DHT.

Теперь давайте рассмотрим немного более сложное, но гораздо более эффективное решение с использованием поисковых подсказок.

Подход №2: Поисковые запросы

Вот каков компромисс при использовании протоколов lookup 2, таких как Caulk 2:

• Положительно: Чрезвычайно эффективное создание доказательств (с использованием этапа предварительной обработки)
• Позитивно: Протокол может быть адаптирован для использования обычной хэш-функции вместо Poseidon
• Негативно: Требуется доверенная установка большого размера (в идеале равная размеру валидаторов)

Ниже мы опишем конкретное доказательство протокола валидатора:

Доказательство протокола валидатора с использованием поиска

Точно так же, как и в подходе Меркла, каждый валидатор i регистрирует в блокчейне новое значение pi, такое, что:

Эффективность

Мы провели сравнительный анализ времени работы нашего протокола доказательства членства(ссылка 6 на эталонный код 5) с точки зрения создания и проверки доказательства. Обратите внимание, что, хотя доказательство членства является лишь одной из частей нашего протокола доказательства валидатора, мы ожидаем, что оно будет доминировать в общем времени работы.

Ниже мы приводим контрольные результаты для доказательства принадлежности к дереву Меркла, используя систему доказательств Halo2 с IPA в качестве полиномиальной схемы обязательств. IPA - более медленная схема, чем KZG, но она не требует доверенной установки, что максимизирует преимущества подхода с использованием дерева Меркла.

Мы наблюдаем, что время работы провера и верификатора хорошо согласуется с нашими требованиями к эффективности. По этой причине мы решили не проводить сравнительный анализ подхода на основе Caulk, поскольку ожидается, что его производительность будет значительно выше во всех категориях (особенно во времени работы провера и размере доказательства).

Бенчмарки были собраны на ноутбуке, работающем на Intel i7-8550U (процессор пятилетней давности).

Обсуждение

Вращающиеся идентичности

Свойство уникальности протокола доказательства валидатора гарантирует, что каждый участник сети обладает отдельной производной парой ключей. Однако для некоторых сетевых протоколов может быть выгодно разрешить валидаторам иметь вращающиеся идентификаторы, когда их производные ключи периодически меняются, возможно, ежедневно.

В таком сценарии, если Ева плохо себя ведет в определенный день, Алиса может заблокировать ее в списке на этот день. Однако на следующий день Ева может сгенерировать новый производный ключ, который не занесен в блок-лист. Если бы мы хотели иметь возможность постоянно блокировать валидаторов на основе их вращающейся личности, нам бы понадобилась более продвинутая схема анонимных учетных данных, такая как SNARKBlock 1.

Почему бы не использовать открытый ключ идентификации BLS12-381?

Альтернативным (возможно, более простым) подходом было бы создание обязательства из всех ключей идентификации валидатора BLS12-381 и выполнение доказательства членства на основе этого обязательства.

Однако такой подход потребует от проверяющих вставлять свой личный ключ в систему доказательства ZK, чтобы создать действительное доказательство членства и вычислить уникальный производный ключ.

Мы решили не использовать этот подход, потому что вставлять чувствительные идентификационные ключи в сложный криптографический протокол - не лучшая практика, к тому же это усложнило бы задачу валидаторов хранить свой основной идентификационный ключ в автономном режиме.

Направления будущих исследований

• Можем ли мы полностью избежать схем SNARK и выполнить доказательство принадлежности и извлечение ключа чисто алгебраическим способом?
• Связано с этим: Можно ли создать эффективный протокол доказательства принадлежности без доверенной установки и без опоры на хэш-функции, дружественные SNARK?

Благодарности

Спасибо Энрико Боттацци, Cedoor, Вивиан Пласенсия и Wanseob за помощь в навигации по паутине кодовых баз, подтверждающих членство.

Отказ от ответственности：

1. Эта статья перепечатана с сайта[ethresear]. Все авторские права принадлежат авторам[Джордж Кадианакис, Мэри Маллер, Андрия Новакович, Супханат Чунхапанья]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
2. Отказ от ответственности: Это
   Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.