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

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

Всех с Новым годом! Мы снова в седле :cowboy_hat_face: и рвемся вперед.

Большое спасибо @josh за настройку недавней тестовой сети сообщества и всем, кто принял в ней участие. Некоторые из аномалий, о которых мы сообщали, мы видели в результатах наших собственных тестов, и было также несколько сюрпризов, включая максимальные всплески ЦП, которые мы сейчас изучаем. Здоровья, ребята!

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

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

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

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

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

@bochaco продолжает совершенствовать процесс членства, то есть то, как мы поддерживаем правильное количество старших в разделе и как мы добавляем новые узлы для взрослых в раздел, когда это необходимо. Когда новый узел запрашивает присоединение, он запускает процесс, который включает в себя сообщения AE и проверку ресурсов, и как только старейшины соглашаются его принять, сообщение отправляется обратно присоединяющемуся узлу. Этот поток теперь интегрирован с крейтом sn_membership — по крайней мере, для взрослых, повышающихся до старших, и старейшин, уходящих. Однако в настоящее время этот процесс «принадлежности к членству» предполагает, что все задействованные узлы являются членами с правом голоса (т. е. старейшинами), поэтому он исключает повышение уровня взрослого до старейшины. @bochaco и @davidrusu сейчас работают над этим. Мы объясним больше в будущем обновлении.

Тем временем @lionel.faber рассматривает возможность ускорения процесса CI/CD с помощью собственных исполнителей GitHub на AWS. Собственные виртуальные машины в GitHub Actions могут быть довольно медленными, особенно для Windows, что оказалось узким местом при тестировании. Размещая сервис на AWS, мы можем использовать более мощные виртуальные машины для более быстрого выполнения наших рабочих процессов. Лайонел также документирует процесс генерации распределенного ключа (DKG), который мы используем для согласования.

Остановимся на мгновение на тестировании, иногда тесты могут быть слишком строгими. Как же так? Скважинные тесты предназначены для обнаружения каждой ошибки, когда она возникает, тогда как отказоустойчивая сеть с CRDT может обойти эти сбои, в конечном итоге достигая гарантированно согласованного состояния. Таким образом, может быть расточительно создавать тесты, которые поймают все, но это сложный баланс!

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

В этом сценарии обмен сообщениями между актерами также имеет нюансы, и это еще одна тема для обсуждения. Когда фрагмент был успешно помещен, клиенту следует (необязательно) сообщить, что он был сохранен, и благодаря CRDT это должно быть уверено на 100%, но если он явно «сбой», это не на 100% уверено из-за асинхронности и других факторов, поэтому клиенту нужны варианты дальнейших действий.

@Qi_ma просматривает журналы, чтобы отследить ошибку с отсутствующими данными, а @yogesh ищет причину потока сообщений AE, которые иногда перегружают связь между узлами. Они связаны? Мы должны скоро узнать. Тем временем @joshuef занимается поиском ошибки, которая может вызывать проблемы в узлах, которые перегружаются клиентами, вызывая всплеск памяти узла и время от времени приводя к его сбою. Прямо сейчас мы просто ограничиваем это произвольным пределом одновременных клиентских сообщений, но мы постараемся сделать это динамическим в зависимости от загрузки узла по мере нашего продвижения.

Каждый шаг другойр шаг ближе.


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

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

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