В дорожную карту 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.
В этом разделе мы мотивируем доказательство протокола валидатора, описывая атаку 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 соответствует какому валидатору.
Чтобы выполнить эти задачи, протокол доказательства валидности должен отвечать следующим требованиям:
Такой протокол доказательства валидатора будет использоваться Бобом во время установления соединения на уровне DHT, чтобы Алиса знала, что она разговаривает с валидатором.
Наш протокол доказательства валидатора по сути является простой анонимной схемой проверки полномочий. Его цель - дать Алисе возможность сгенерировать уникальный производный ключ, обозначаемый как D, тогда и только тогда, когда она является валидатором. Впоследствии Алиса использует этот полученный ключ D на сетевом уровне.
При разработке этого протокола мы стремились создать решение, которое было бы простым в реализации и анализе, а также обеспечивало бы эффективное выполнение изложенных требований.
В протоколе используется подпротокол доказательства принадлежности, в котором Алиса доказывает, что она является валидатором, демонстрируя знание секретного хэш-пред-образа с помощью ZK-доказательств. Затем Алиса строит уникальную пару ключей, полученную из этого секретного хэш-представления.
Подпротокол доказательства членства может быть создан различными методами. В этом посте мы покажем протокол, использующий деревья Меркла, и второй протокол, использующий поиск.
Хотя оба подхода демонстрируют приемлемую эффективность, они имеют различные компромиссы. Деревья Меркла полагаются на хэш-функции, дружественные SNARK, такие как Poseidon (которые можно считать экспериментальными). С другой стороны, эффективные протоколы поиска полагаются на доверенную установку размером, равным размеру набора валидаторов (в настоящее время 700 тыс. валидаторов, но их количество растет).
Теперь давайте погрузимся в протоколы:
Деревья Меркла широко использовались для доказательства принадлежности (например. см. Семафор 3). Вот пространство компромиссов при разработке доказательства принадлежности с использованием деревьев Меркла:
Ниже мы опишем доказательство протокола валидатора, основанного на деревьях Меркла:
)
В конце протокола Алиса может использовать D в DHT для подписи сообщений и получения своего уникального идентификатора узла DHT.
Теперь давайте рассмотрим немного более сложное, но гораздо более эффективное решение с использованием поисковых подсказок.
Вот каков компромисс при использовании протоколов lookup 2, таких как Caulk 2:
Ниже мы опишем конкретное доказательство протокола валидатора:
Точно так же, как и в подходе Меркла, каждый валидатор i регистрирует в блокчейне новое значение pi, такое, что:
Мы провели сравнительный анализ времени работы нашего протокола доказательства членства(ссылка 6 на эталонный код 5) с точки зрения создания и проверки доказательства. Обратите внимание, что, хотя доказательство членства является лишь одной из частей нашего протокола доказательства валидатора, мы ожидаем, что оно будет доминировать в общем времени работы.
Ниже мы приводим контрольные результаты для доказательства принадлежности к дереву Меркла, используя систему доказательств Halo2 с IPA в качестве полиномиальной схемы обязательств. IPA - более медленная схема, чем KZG, но она не требует доверенной установки, что максимизирует преимущества подхода с использованием дерева Меркла.
Мы наблюдаем, что время работы провера и верификатора хорошо согласуется с нашими требованиями к эффективности. По этой причине мы решили не проводить сравнительный анализ подхода на основе Caulk, поскольку ожидается, что его производительность будет значительно выше во всех категориях (особенно во времени работы провера и размере доказательства).
Бенчмарки были собраны на ноутбуке, работающем на Intel i7-8550U (процессор пятилетней давности).
Свойство уникальности протокола доказательства валидатора гарантирует, что каждый участник сети обладает отдельной производной парой ключей. Однако для некоторых сетевых протоколов может быть выгодно разрешить валидаторам иметь вращающиеся идентификаторы, когда их производные ключи периодически меняются, возможно, ежедневно.
В таком сценарии, если Ева плохо себя ведет в определенный день, Алиса может заблокировать ее в списке на этот день. Однако на следующий день Ева может сгенерировать новый производный ключ, который не занесен в блок-лист. Если бы мы хотели иметь возможность постоянно блокировать валидаторов на основе их вращающейся личности, нам бы понадобилась более продвинутая схема анонимных учетных данных, такая как SNARKBlock 1.
Альтернативным (возможно, более простым) подходом было бы создание обязательства из всех ключей идентификации валидатора BLS12-381 и выполнение доказательства членства на основе этого обязательства.
Однако такой подход потребует от проверяющих вставлять свой личный ключ в систему доказательства ZK, чтобы создать действительное доказательство членства и вычислить уникальный производный ключ.
Мы решили не использовать этот подход, потому что вставлять чувствительные идентификационные ключи в сложный криптографический протокол - не лучшая практика, к тому же это усложнило бы задачу валидаторов хранить свой основной идентификационный ключ в автономном режиме.
Спасибо Энрико Боттацци, Cedoor, Вивиан Пласенсия и Wanseob за помощь в навигации по паутине кодовых баз, подтверждающих членство.
В дорожную карту 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.
В этом разделе мы мотивируем доказательство протокола валидатора, описывая атаку 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 соответствует какому валидатору.
Чтобы выполнить эти задачи, протокол доказательства валидности должен отвечать следующим требованиям:
Такой протокол доказательства валидатора будет использоваться Бобом во время установления соединения на уровне DHT, чтобы Алиса знала, что она разговаривает с валидатором.
Наш протокол доказательства валидатора по сути является простой анонимной схемой проверки полномочий. Его цель - дать Алисе возможность сгенерировать уникальный производный ключ, обозначаемый как D, тогда и только тогда, когда она является валидатором. Впоследствии Алиса использует этот полученный ключ D на сетевом уровне.
При разработке этого протокола мы стремились создать решение, которое было бы простым в реализации и анализе, а также обеспечивало бы эффективное выполнение изложенных требований.
В протоколе используется подпротокол доказательства принадлежности, в котором Алиса доказывает, что она является валидатором, демонстрируя знание секретного хэш-пред-образа с помощью ZK-доказательств. Затем Алиса строит уникальную пару ключей, полученную из этого секретного хэш-представления.
Подпротокол доказательства членства может быть создан различными методами. В этом посте мы покажем протокол, использующий деревья Меркла, и второй протокол, использующий поиск.
Хотя оба подхода демонстрируют приемлемую эффективность, они имеют различные компромиссы. Деревья Меркла полагаются на хэш-функции, дружественные SNARK, такие как Poseidon (которые можно считать экспериментальными). С другой стороны, эффективные протоколы поиска полагаются на доверенную установку размером, равным размеру набора валидаторов (в настоящее время 700 тыс. валидаторов, но их количество растет).
Теперь давайте погрузимся в протоколы:
Деревья Меркла широко использовались для доказательства принадлежности (например. см. Семафор 3). Вот пространство компромиссов при разработке доказательства принадлежности с использованием деревьев Меркла:
Ниже мы опишем доказательство протокола валидатора, основанного на деревьях Меркла:
)
В конце протокола Алиса может использовать D в DHT для подписи сообщений и получения своего уникального идентификатора узла DHT.
Теперь давайте рассмотрим немного более сложное, но гораздо более эффективное решение с использованием поисковых подсказок.
Вот каков компромисс при использовании протоколов lookup 2, таких как Caulk 2:
Ниже мы опишем конкретное доказательство протокола валидатора:
Точно так же, как и в подходе Меркла, каждый валидатор i регистрирует в блокчейне новое значение pi, такое, что:
Мы провели сравнительный анализ времени работы нашего протокола доказательства членства(ссылка 6 на эталонный код 5) с точки зрения создания и проверки доказательства. Обратите внимание, что, хотя доказательство членства является лишь одной из частей нашего протокола доказательства валидатора, мы ожидаем, что оно будет доминировать в общем времени работы.
Ниже мы приводим контрольные результаты для доказательства принадлежности к дереву Меркла, используя систему доказательств Halo2 с IPA в качестве полиномиальной схемы обязательств. IPA - более медленная схема, чем KZG, но она не требует доверенной установки, что максимизирует преимущества подхода с использованием дерева Меркла.
Мы наблюдаем, что время работы провера и верификатора хорошо согласуется с нашими требованиями к эффективности. По этой причине мы решили не проводить сравнительный анализ подхода на основе Caulk, поскольку ожидается, что его производительность будет значительно выше во всех категориях (особенно во времени работы провера и размере доказательства).
Бенчмарки были собраны на ноутбуке, работающем на Intel i7-8550U (процессор пятилетней давности).
Свойство уникальности протокола доказательства валидатора гарантирует, что каждый участник сети обладает отдельной производной парой ключей. Однако для некоторых сетевых протоколов может быть выгодно разрешить валидаторам иметь вращающиеся идентификаторы, когда их производные ключи периодически меняются, возможно, ежедневно.
В таком сценарии, если Ева плохо себя ведет в определенный день, Алиса может заблокировать ее в списке на этот день. Однако на следующий день Ева может сгенерировать новый производный ключ, который не занесен в блок-лист. Если бы мы хотели иметь возможность постоянно блокировать валидаторов на основе их вращающейся личности, нам бы понадобилась более продвинутая схема анонимных учетных данных, такая как SNARKBlock 1.
Альтернативным (возможно, более простым) подходом было бы создание обязательства из всех ключей идентификации валидатора BLS12-381 и выполнение доказательства членства на основе этого обязательства.
Однако такой подход потребует от проверяющих вставлять свой личный ключ в систему доказательства ZK, чтобы создать действительное доказательство членства и вычислить уникальный производный ключ.
Мы решили не использовать этот подход, потому что вставлять чувствительные идентификационные ключи в сложный криптографический протокол - не лучшая практика, к тому же это усложнило бы задачу валидаторов хранить свой основной идентификационный ключ в автономном режиме.
Спасибо Энрико Боттацци, Cedoor, Вивиан Пласенсия и Wanseob за помощь в навигации по паутине кодовых баз, подтверждающих членство.