Обновление Safe Network 🇷🇺 20 января 2022 г

Это машинный перевод. Оригинал на английском здесь: Update 20 January, 2022

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

Общий прогресс

Ящик sn_membership обрабатывается @davidrusu. Сейчас почти все тесты проходят, так что в основном наводит порядок.

@bochaco изучает потоки внутри членства: каков порядок событий, когда присоединяется новый узел или повышается старший взрослый?

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

Помимо членства, @chriso работал над ночным тестированием и, закончив документацию CLI, теперь пишет NRS.

Что касается данных, @yogesh занимается тестированием репликации данных, а @joshuef обновил qp2p до последней версии quinn.

Тем временем @danda усердно работает с DBC. Интеграция Ring CT в значительной степени завершена, и следующий шаг — монетные дворы, хотя требуется дополнительная работа, чтобы заставить монетные дворы правильно работать с Ring CT. ).

@happybeing сделал прекрасный небольшой пиар обновление журнала узла. Это должно помочь сэкономить место на любых запущенных узлах и упростить отслеживание журналов с помощью таких команд, как tail -f.

Членство

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

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

Членство в разделе ограничено максимальным размером раздела. Когда у нас есть такие ограничения в распределенной системе, нам часто приходится прибегать к консенсусу, чтобы выбрать между конкурирующими вариантами. В нашем случае членства старшие должны решить, какой из (многих) узлов, ожидающих присоединения к разделу, должен быть допущен.

До этого момента мы не использовали алгоритм консенсуса, текущие процессы управления членством иногда сбоят, когда происходят непредвиденные события.

Новый крейт sn_membership предоставляет алгоритм консенсуса BFT без лидера, обеспечивающий хорошую производительность в потенциально синхронной сетевой модели. После беспощадного тестирования он готов к интеграции в сеть.

sn_membership работает вместе с антиэнтропией (AE) и распределенной генерацией ключей (DKG) для управления членством в секциях. Вот некоторые потоки.

Соединение узлов

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

В старой системе после прохождения теста узел находился в нем, но это было угрозой безопасности и могло привести к блокировке (см. ниже). Теперь старейшина отправляет предложение добавить узел по протоколу sn_membership другим старейшинам секции. sn_membership завершается, когда у нас есть супербольшинство над супербольшинством, то есть сверхбольшинство старейшин видят, что сверхбольшинство старейшин приняло это предложение. Как только sn_membership запущен, он гарантированно завершится (до тех пор, пока наше предположение о конечной синхронности сети не будет нарушено).

Как только предложение достигает консенсуса среди старейшин, старейшина отправляет одобрение присоединяющемуся узлу.

Повышение в должности для взрослых и передача старшего возраста

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

Алгоритм Elder Handover, управляющий этим процессом, который теперь готов к интеграции в крейт sn_membership, работает следующим образом.

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

Старейшина предлагает новый наборстарейшины.

Старейшины следуют консенсусу в стиле sn_membership, чтобы выбрать одно сообщение NewElders. Этот шаг требуется, когда у нас есть сложная цепочка событий, которая заканчивается тем, что несколько групп узлов мчатся, чтобы завершить DKG и стать следующими старейшинами.

Список текущих членов раздела передается новому старейшине, поставщик полномочий раздела (SAP) обновляется, и в цепочку разделов добавляется новый блок.

Роль консенсуса

Так почему же для членства необходим консенсус, когда другие части сети полагаются на AE, чтобы оставаться в курсе событий?

Вот пример. Допустим, раздел почти заполнен. Ограничение размера секции составляет 50 узлов (только для примера), и в настоящее время в ней 49 членов. Новый узел отправляет JoinRequest старшему. В системе без консенсуса старший проверяет емкость и видит, что емкость есть, обменивается сообщениями AE, и, если новый узел проходит тест проверки ресурсов, он включен.

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

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

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

Чтобы предотвратить возникновение этой проблемы, старейшины приходят к консенсусу относительно того, какие узлы будут разрешены. С помощью sn_consensus каждый из семи старейшин может предложить до одного изменения. Это означает, что за один раунд может быть принято до семи изменений (присоединение/выход).

В приведенном выше случае sn_membership будет означать некоторую дополнительную работу по сравнению со старейшинами, действующими самостоятельно, но эти накладные расходы видны только тогда, когда у нас есть много конкурирующих вариантов. sn_membership изящно масштабируется до Byzantine Reliable Broadcast (BRB), когда старейшины в целом согласны с действиями, которые необходимо предпринять, мы платим накладные расходы консенсуса только тогда, когда у старейшин начинаются разногласия. sn_membership — это мирный способ разрешения разногласий :slight_smile:


Полезные ссылки

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

Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!