Это машинный перевод. Оригинал на английском здесь: Update 29 September, 2022
Мы упростили код и устранили множество глюков, убрав все ненужные асинхронные многопоточные процессы в коде узла. В то же время остаются некоторые проблемы с медленной связью, которые, как мы думаем, могут быть вызваны самим Quic, поэтому мы углубляемся в это.
Новый синхронный код sn_sdkg теперь готов к интеграции. @anselme расскажет нам об этом на этой неделе.
Общий прогресс
Qi_ma наблюдает, как старейшины проверяют «node_age» узла, когда они решают, какой из них переместить в новый раздел, поскольку мы наблюдаем там некоторое аномальное поведение, в том числе «зомби-узлы», которые могут присоединиться к сети.
@ChrisO экспериментирует с Quinn, который представляет собой реализацию протокола Quic на Rust для установления и поддержания соединений между узлами. К сожалению, Quic является чем-то вроде черного ящика, и мы думаем, что некоторые из проблем с подключением, с которыми мы сталкиваемся, могут быть связаны с тем, как он работает, в частности, с тем, что связь часто медленная, что вызывает проблемы, когда время ожидания процессов истекает. У Криса настроена песочница Quinn, и он наблюдает, что происходит, когда мы запускаем в нее различные типы сообщений. В то же время @bzee изучает структуру сообщений qp2p, чтобы подтвердить, что мы используем Quinn максимально эффективно. Ключевая проблема заключается в асинхронном получении параллельных потоков с одновременным ожиданием ответов (возврат наблюдателя для отслеживания ответных сообщений на том же канале).
@roland работает над нечеткими тестами для нового ящика sn_sdkg, который @anselme подробно описывает ниже.
sn_sdkg Интеграция
Генерация распределенного ключа (также известная как DKG) — это способ, которым старейшины секций генерируют ключ секции безопасным способом, сохраняя секретность ключа секции. В конце DKG каждый старейшина знает только свою долю секретного ключа, таким образом, никто никогда не увидит секретный ключ всей секции. Это механизм для уменьшения диапазона действия потенциально плохих старейшин: именно так Safe Network может гарантировать, что пока у нас меньше 5/7 плохих старейшин, они не смогут ничего подписывать с полномочиями раздела. Полномочия раздела необходимы для изменения данных, продвижения или обозначения узлов и чеканки токенов, поэтому это очень важно.
Недавно мы работали над новым DKG, который более устойчив к потере пакетов и не использует таймеры, поэтому он не может выйти из строя из-за медленного сетевого трафика и тайм-аутов. Этот пост описывает, как работает этот новый DKG. Для этой реализации мы используем крейт sn_sdkg синхронной распределенной генерации ключей, основанный на алгоритме синхронной генерации ключей poanetwork в их крейте hbbft.
Как работает ДКГ
DKG запускается старейшинами, когда они замечают, что самые старые члены не являются старейшинами, или когда секция распадается, и им нужно выбрать старших кандидатов. Заметив это, нынешние старейшины просят кандидатов начать новую сессию DKG с сообщением DkgStart, чтобы они могли сгенерировать следующий ключ раздела.
Первым шагом в нашем DKG является создание временных ключей BLS, которые используются для шифрования в процессе DKG. У каждого узла в безопасной сети есть ключ ed25519, но, хотя эти ключи отлично подходят для подписи, мы не можем безопасно выполнять с ними шифрование. Нам нужен другой путь.
Поскольку у наших узлов нет ключей BLS (у старших есть общий ключ BLS, но не простой ключ BLS), мы генерируем одноразовый ключ только для этого сеанса DKG и удаляем его после использования. Однако нам нужно, чтобы другие узлы доверяли этому ключу BLS, потому что он совершенно новый, поэтому, прежде чем что-либо еще произойдет, каждый кандидат транслирует свой вновь сгенерированный открытый ключ BLS в сообщении, содержащем его подпись (сделанную с помощью доверенного ключа ed25519) поверх нового одноразовый открытый ключ BLS, который они будут использовать для этого сеанса DKG.
Как только кандидаты получат все открытые ключи BLS для этого сеанса DKG, они смогут начать голосование. Голосование проходит в 3 этапа:
- «Части»: каждый узел отправляет «Часть», которая будет использоваться для окончательной генерации ключа, она содержит зашифрованные данные, которые будут использоваться для генерации их общего ключа.
- «Подтверждения»: узлы проверяют «Часть» и отправляют свои «Подтверждения» (подтверждения) вместо «Части». Эти подтверждения также будут использоваться для генерации ключей.
-
AllAcks: каждый должен убедиться, что все они имеют одинаковый наборAcksиParts, отправив свою версию наборов. Эта последняя часть предназначена для того, чтобы убедиться, что кандидаты в конечном итоге генерируют один и тот же ключ раздела!
После завершения голосования кандидаты могут сгенерировать свои общие секретные ключи вместе с открытым ключом нового раздела из «Частей» и «Подтверждений».
Сплетни и возможное прекращение
В сети сообщения могут быть потеряны, что может привести к ситуациям, когда некоторые кандидаты не получат голоса, а некоторые ожидают ответа на голоса, которые так и не поступили. Чтобы противостоять этой проблеме, у нас есть сплетни! Время от времени, если узел не получил новых сообщений DKG, когда он их ожидает, он отправляет все свои голоса другим. Это имеет две цели:
- один должен сообщить другим голоса, и получить их up, чтобы ускорить голоса, которые они могли пропустить
- второй — показать другим участникам, что нашему узлу не хватает голосов, чтобы другие могли в свою очередь ответить своими голосами и помочь нам догнать их
Действительно, если узел получает сообщение сплетни, в котором отсутствует информация, он ответит своим знанием. Это происходит даже после завершения (завершение раунда голосования), потому что иногда, когда узел завершается (и, таким образом, перестает сплетничать, потому что он не ожидает больше голосов), он все еще будет получать сплетни от других узлов, которые не попали туда. пока что. В этом случае знающий узел ответит на эту сплетню своими знаниями, чтобы другие узлы также могли завершить работу. В конце концов, в ходе этого процесса каждый кандидат завершает работу.
Параллельные DKG
В этой реализации мы используем параллельные DKG. Иногда сразу после срабатывания DKG к разделу присоединяется новый узел, который кажется лучшим старшим кандидатом, поскольку возраст его узла очень высок. В этом случае текущий набор лучших старших кандидатов изменяется, и текущие старейшины выдают новое сообщение DkgStart новым кандидатам.
Предыдущая сессия DKG не остановлена, вместо этого теперь это гонка между ними! Мы хотим, чтобы старейшины были очень надежными узлами. В некотором смысле, интенсивный процесс DKG является тестом, чтобы проверить, действительно ли эти кандидаты подходят для того, чтобы быть старейшинами. Если несколько DKG завершатся одновременно, ничего страшного, «консенсус передачи» гарантирует, что текущие старейшины выберут только одного победителя. Сеансы DKG, которые не выиграли гонку, могут быть или не быть завершены, но это не имеет большого значения, они в конечном итоге будут удалены, когда узлы поймут, что они проиграли.
Вывод
Короче говоря, новый DKG фокусируется на том, чтобы быть очень устойчивым к потере сообщений, устраняя необходимость в таймерах и гарантируя, что все в конечном итоге завершат работу без возможных тайм-аутов. Это также делает одновременные DKG функцией выбора лучших кандидатов в гонке за прекращение между DKG.
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!