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

Dimitar · 07.Январь.2023 07:33:15

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

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

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

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

Разделение универсальных сообщений NodeMsg::Propose на четыре различных варианта для ясности.

RequestHandover: когда узлы завершают DKG и запрашивают передачу обслуживания текущим старейшинам (узел->старейшина)
SectionHandoverPromotion: когда старейшины сообщают этим узлам, что они повышены как старшие (старейшина-> узел)
SectionSplitPromotion: когда старейшины сообщают этим узлам, что они продвигаются как старшие по обе стороны от разделения (старейшина-> узел)
ProposeSectionState: когда старейшины решают удалить узлы или принять новые узлы в разделе (старейшина-> старейшина)

Это различие делает явным, кто подписывает и кто получает/объединяет подписи.

Удаление ненужных сообщений
Мы исправили дорогостоящую проблему, из-за которой сообщения AE неоднократно проверяли SectionTree для каждого сообщения, даже если оно уже было проверено.

Оптимизация автоматической экспозиции
Мы экспериментировали с замедлением зондирования AE вокруг разветвлений, чтобы уменьшить количество летающих сообщений, а также реорганизовали знание разделов глобальной сети, чтобы ориентироваться на один случайный старейшина в трех случайных секциях каждые пять минут. Раньше по умолчанию все старейшины в трех разделах каждые 30 секунд. Это привело к значительному снижению использования ЦП и памяти во время разделения, и более длительного времени должно быть достаточно для наших нужд: в конце концов, разделение не происходит каждые 30 секунд.

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

Рефакторинг связи
Уродливая блокировка в коде для send-streams в sn_node была переработана. Кроме того, мы тестируем сообщения «счастливого пути», когда клиенты могут отправить сообщение только одному старейшине, а не всем им.

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

Изменения параметров хранения
К емкости хранилища был добавлен запас, поэтому мы ожидаем минимальный объем хранилища, но узлы могут хранить больше. Это должно помочь устранить ошибки «не удалось сохранить» перед разделением. Мы также настроили старших для хранения данных (раньше их не было) и использовали их локальную минимальную емкость хранилища в качестве индикатора того, когда нужно разделить, как обсуждалось на форуме.

Теперь у нас есть следующий поток:

Узлы получают данные.
Каждый раз, когда мы проходим определенный уровень используемого хранилища (в первый раз), мы разрешаем присоединяться новым узлам.
2.1 Когда узел запрашивает присоединение, мы видим, что присоединения разрешены, и старейшины начинают голосование за добавление узла.
Когда присоединяется новый узел, присоединения отключаются, мы проверяем, достигли ли мы min_capacity
3.1. Мы не достигли min_capacity, продолжайте как обычно.
3.2. Мы достигли min_capacity, очистите лишнее хранилище.
3.3 Если мы все еще находимся на уровне min_capacity или выше, активируйте отказоустойчивый allow_joins_until_split.
3.4. Когда узел запрашивает присоединение, мы видим, что присоединения разрешены, и старейшины начинают голосование за добавление узла.
Присоединяющийся узел снижает нагрузку на хранилище.

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

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

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