Обновление Safe Network 🇷🇺 11 марта 2021 г

Это машинный перевод. Оригинал на английском здесь: Safe Network Dev Update - March 11, 2021

Резюме

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

  • После проработки некоторых мелких рефакторингов и исправлений мы теперь можем обновить все наши ящики Rust до Tokio v1.
  • На этой неделе мы пересмотрели sn_routing, чтобы изменить способ достижения соглашения и теперь требует сверхквалифицированного большинства (более 2/3) вместо простого большинства (более 1/2). Мы считаем, что это было необходимо, чтобы сделать сеть устойчивой к определенным типам атак.
  • Мы решили реализовать Lazy Messaging в sn_node, работа уже ведется. Изначально это планировалось для пост-тестовой сети, но мы сочли целесообразным внести свой вклад.
  • @jimcollinson выгнали AMA на Reddit, и прямо здесь, на форуме, на прошлой неделе - еще есть время, чтобы задать свои вопросы!
  • @jimcollinson создал первую серию видеоответов YouTube, которые, как мы полагаем, на более серьезные вопросы, полученные в AMA - вы можете посмотреть здесь. :movie_camera:
  • @dimitar работал за кулисами, чтобы помочь повысить осведомленность о безопасной сети в Индии с помощью рекламной кампании в Facebook и Twitter. :heart:
  • Постоянно следите за веткой Like This Tweet на форуме, чтобы получить отличные рекомендации о том, как способствовать продвижению безопасной сети, и окружающие компоненты, простым нажатием кнопки! :bird:

Безопасный клиент, узлы, маршрутизация и qp2p

План проекта безопасного сетевого переноса
План проекта безопасного клиента
План проекта безопасного сетевого узла

На прошлой неделе долгожданный выпуск Quinn, наконец, прибыл с важным обновлением: Tokio v1. До сих пор использование более старой версии Tokio в Quinn не позволяло нам обновить все наши ящики до Tokio v1 из-за несовместимых версий среды выполнения, поэтому мы находимся в процессе обновления всех наших ящиков до Tokio v1. С некоторыми незначительными доработками и исправлениями мы смогли пройти все тесты с новой версией Tokio. Это обновление также помогло нам выявить ранее не обнаруженную проблему, из-за которой потоки оставались открытыми, что в конечном итоге привело к остановке сетевых подключений при достижении верхнего предела. Команда Куинна незамедлительно нам помогла, и проблема теперь исправлена ​​в qp2p. Связь sn_routing снова работает безупречно! Мы ожидаем, что все наши ящики будут обновлены в ближайшие несколько дней.

На этой неделе мы также добавили больше примеров в ящик qp2p, чтобы лучше продемонстрировать использование API, и для стресс-тестирования qp2p как локально и о Digital Ocean.

В «sn_routing» на этой неделе мы решили изменить способ достижения соглашения, чтобы теперь требовать сверхбольшинства (более 2/3) вместо простого большинства (более 1/2). Это было необходимо, чтобы сделать сеть устойчивой к определенным типам атак. Мы также увеличили количество старейшин в секции с 5 до 7, что означает, что секция может потерять до двух старейшин и продолжать функционировать. Эти изменения в настоящее время проходят проверку и тестирование, и мы ожидаем, что они скоро будут объединены.

Учитывая необходимость включения ленивого обмена сообщениями (см. Подраздел ниже), мы рассматривали, как лучше всего этого добиться в sn_node. Возможно, мы сможем вставить некоторые мелкие части этого, но мы также рассмотрим здесь более крупный рефакторинг, чтобы упростить вещи. Похоже, что с исключением части кода sn_node (по сути, с удалением Duties) и прямым синтаксическим анализом сообщений, мы получим что-то, из чего мы можем легко исправить ошибку, а также, вероятно, потерять много _ sn_node. сложность. Первоначальные усилия в этой области были довольно позитивными. Мы надеемся, что это не будет такой уж сложной задачей, поскольку основная логика должна оставаться прежней, но, несмотря на то, что мы приближаемся к этому параллельно с более легкими решениями, мы надеемся, что мы ничего не блокируем.

sn_node Ленивый обмен сообщениями

Ленивый обмен сообщениями в sn_node будет работать за счет небольшого увеличения размера сообщений, отправляемых между узлами, чтобы они включали некоторую дополнительную информацию о текущем состоянии сети, которую видят разные наблюдатели в пространстве и времени. Альтернативой этому подходу был бы постоянный опрос на предмет изменений - мы твердо веримe что стоимость дополнительных данных на сообщение более чем компенсируется снижением общего трафика по сравнению с постоянным опросом. С опросом, даже когда Сеть находится в периоде затишья, опрос должен продолжаться в фоновом режиме. Другие подходы к остановке / паузе частей Сети для достижения согласия чреваты множеством побочных эффектов и сложным кодом, поэтому они не рассматриваются.

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

Ленивый обмен сообщениями был реализован в sn_routing уже некоторое время, что доказало свою эффективность и надежность. В sn_node мы столкнулись с некоторыми проблемами за последние пару недель, пытаясь обновить узлы с последними изменениями * состояния сети * (после оттока, повышения, понижения и т. Д.). Например, когда раздел разделяется, мы сталкиваемся с проблемами, связанными с тем, чтобы новые старейшины соответствующих новых родственных разделов работали быстрее со старейшинами родительского раздела, при этом сохраняя способность справляться с типичным ожидаемым трафиком и сетевыми событиями.

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

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

CRDT

Началась работа над типом ограниченного счетчика, который позволит нам ограничивать операции над типом данных. Это ценный компонент, который позволяет изменяемым данным постоянно увеличиваться, ограничивая данные по отсекам. Это означает, что мы можем заплатить за загрузку типа данных, а затем свободно добавлять к нему до определенной точки, когда пользователь снова платит и освобождает еще один набор операций. Такое разделение растущих данных распределяет нагрузку по сети. Это оптимизация, но важная, которая требуется для запуска, но не для Флеминга. Приятно видеть, что сейчас в конвейере есть эти мелкие детали.

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

Сообщество и маркетинг

@jimcollinson выгнали AMA на Reddit и прямо здесь, на форуме, на прошлой неделе.

Первоначальная цель заключалась в том, чтобы собрать несколько интересных вопросов и ответить на них в ходе сеанса вопросов и ответов на YouTube. Был замечательный ответ, и ответы на многие вопросы оказались гораздо более подробными, чем можно было бы обработать за один сеанс вопросов и ответов. Итак, вот первый видеоответ из того, что, вероятно, станет серией:

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

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


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

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