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

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

Резюме

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

  • В прошлую пятницу сообщество открытых дверей Safe Chat имело большой успех! Большое спасибо всем участникам, особенно @sotros25 и @m3data за их отличные презентации. :clap:
  • @jimcollinson запускает AMA на Reddit - пожалуйста, примите участие!
  • Глубокое погружение в многосекционные сети и их отладка были основной темой на этой неделе, и было введено несколько новых уловок обработки ошибок, поскольку мы отсеивали проблемы, которые могут привести к сбою сетей.
  • Новые версии sn_api (v0.20.0), sn_authd (v0.2.0) и CLI (v0.20.0) только что выпущены, что делает его совместимым с последней версией sn_node.
  • Мы завершили разработку MerkleReg, упомянутого на прошлой неделе, и поэтому началась работа по его интеграции в sn_data_types.
  • На этой неделе были переданы первые файлы с одного узла SNFS на другой через BRB. :tada:
  • В маршрутизации мы наконец объединили PR разрешения вилки.
  • Также в маршрутизации мы объединили три отдельных PR (# 2349, # 2351 и # 2336), в которых исправлены различные проблемы, возникшие во время стресс-тестирования. Маршрутизация теперь считается готовой для стабильной тестовой сети.

Безопасный клиент, узлы и qp2p

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

Ближе и ближе…

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

Другие исправления

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

Решение основной проблемы

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

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

Безопасный браузер

Также на этой неделе в Safe Browser мы потратили немного времени на очистку репозитория (это было давно!), Обновляя зависимости, поэтому у нас не будет кучи проблем с безопасностью, когда мы будем готовы к этому. (@bzee, похоже, успешно преуспел в преобразовании sn_nodejs в napi, что приятно видеть!). Это не заголовок захватывающих новостей, но это одна проблема меньше, чем нужно заниматься, когда мы довольны стабильностью тестовой сети.

API и CLI

Только что вышла новая версия sn_api (v0.20.0), sn_authd (v0.2.0) и CLI (v0.20.0) с некоторыми улучшениями в способе хранения файлов и контейнеров NRS в сети. как с новыми подкомандами bin-version для auth и node, чтобы запросить их двоичную версию. Как обычно, вы можете использовать CLI для обновления ($ safe update и $ safe auth update) или установить последнюю версию CLI, как подробно описано в Руководстве пользователя. Эти новые версии совместимы с последней версией sn_node v0.28.1.

Как упоминалось на прошлой неделе, мы переносим наш тип данных Sequence, чтобы теперь он содержал неизменяемую политику, которая устраняет все сложности, которые он привносит в наш подход CRDT. С тхаТеперь в наличии, на прошлой неделе мы смогли адаптировать все наши API-интерфейсы и типы обмена сообщениями по всем направлениям, чтобы исключить возможность изменения политик.

Из-за рефакторинга и других изменений, произошедших в предыдущие месяцы в способе отправки сообщений клиентом в сеть, нам пришлось временно отключить наши E2E-тесты sn_api в CI, поскольку они должны быть адаптированы к новой, более асинхронной природе обмена сообщениями. . Теперь мы начали медленно адаптировать их, чтобы вернуть их в нашу систему CI.

CRDT - бесконфликтные реплицированные типы данных

Мы завершили разработку упомянутого на прошлой неделе MerkleReg: rust-crdt # 111, и поэтому началась работа по его интеграции. в sn_data_types. Напоминаем, что MerkleReg будет новой поддерживающей CRDT для типа Sequence. Он поддерживает историю ветвлений, которую можно просмотреть (аналогично истории веток git).

Также на этой неделе в CRDT GList / List обнаружена проблема с вставкой между индексами, которые использовали один и тот же идентификатор, и поэтому эта проблема была быстро решена в rust-crdt # 112.

BRB - Византийское надежное вещание

Интеграция безопасной сетевой файловой системы (SNFS) с BRB оказалась очень плодотворной в обнаружении некоторых недостающих функций в BRB:

  1. Клиент не был уведомлен, когда был применен Op. Эта информация необходима клиентам для повторной отправки потенциально отброшенных пакетов. Это было решено с помощью пакетов Delivered: brb # 27.
  2. Когда операция выполнялась BRB на клиенте, он полагался на сетевой стек для отправки пакетов самому себе. Это могло бы вызвать условия гонки для клиентов с высокой степенью одновременного выполнения, когда операции выполняются в быстрой последовательности. Теперь мы закорачиваем эти пакеты себе и обрабатываем их перед возвратом клиенту: brb # 29.
  3. Чтобы справиться с отброшенными пакетами, мы добавили API для повторной отправки пакетов, на которые мы еще не получили ответа: brb # 29.

SNFS - безопасная сетевая файловая система

Хорошие новости! На этой неделе первые файлы были переданы с одного узла SNFS на другой через BRB. :tada:

Первоначально мы выполняли передачу BRB синхронно с операцией FUSE, но это оказалось слишком медленным. Улучшена постановка операций в очередь и немедленный возврат в FUSE. Затем отдельный поток лениво отправляет операции одноранговым узлам в исходном порядке и обеспечивает выполнение каждого из них. Это необходимый шаг на пути к файловой системе, которую можно использовать в автономном режиме, а затем синхронизировать с одноранговыми узлами при восстановлении связи. С этим изменением файловая система ощущается с точки зрения скорости, как при использовании обычной файловой системы операционной системы, такой как ext4 в Linux с SSD. Возможно, еще не так быстро, но того же порядка.

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

Маршрутизация

План проекта

На этой неделе мы наконец объединили PR разрешения форка. Суть PR - это новая реализация структуры данных SectionChain, которая теперь является полноценной CRDT. Это означает, что он гарантирует (конечную) согласованность независимо от того, в каком порядке применяются операции, как они группируются или даже дублируются. Даже если в него вставлено несколько отдельных ключей, все в конечном итоге согласятся, какой из них является самым последним, и, следовательно, кто являются текущими старейшинами (поскольку каждый ключ раздела однозначно связан с одной группой старейшин). И все это достигается без использования какого-либо сложного механизма консенсуса. Это именно то, что мы хотели, когда удалили Parsec, и теперь он, наконец, здесь.

Затем последовали три отдельных PR (# 2349, # 2351 и # 2336), в которых исправлены различные проблемы, возникшие во время стресс-тестирования. Вот некоторые из наиболее примечательных:

  • Избегайте бесконечного цикла запрос-ответ во время начальной загрузки, игнорируя дублирующиеся ответы на перенаправление - вызывали массовые утечки памяти.
  • Исправлено случайное отклонение действительных ответов начальной загрузки при перемещении - из-за того, что узел, перемещенный в другой раздел, зависал.
  • Исправлено случайное аннулирование подписи повторно отправленных возвращенных сообщений Sync - иногда узлы не могли должным образом обновляться о состоянии их раздела.
  • Уведомить переехавших старейшин о том, что за них проголосовали из их первоначального раздела - в противном случае они никогда непрогресс их переселения.
  • Убедитесь, что информация одноуровневого раздела является доверенным после разделения - в противном случае узлы забыли, кем были узлы в их одноуровневом разделе сразу после разделения, и, таким образом, не смогли связаться с ними. Это также привело к зависанию некоторых узлов во время начальной загрузки.
  • Разрешить несколько ожидающих результатов DKG - в противном случае узлы иногда забывали свои общие секретные ключи и, таким образом, становились неспособными подписывать сообщения раздела.
  • Используйте уникальный ключ для сеансов DKG с одними и теми же участниками - невыполнение этого иногда приводило к повреждению результата DKG, и узлы не могли подписывать сообщения раздела.

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

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

Безопасный чат

Первый день открытых дверей Safe Chats прошел в пятницу, и какое удовольствие! Хотя повестка дня была сосредоточена вокруг темы общественного маркетинга Сети, с отличными презентациями от @sotros25 и @m3data, дискуссии были шире, чем вы можете себе представить.

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

Если вы еще этого не сделали, вы можете поговорить здесь:

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

Я UX-дизайнер и помогаю строить новый Интернет: спросите меня о чем угодно!

@jimcollinson запускает AMA на Reddit и вообще все социальные каналы.

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

Пожалуйста, присоединяйтесь!

Пользовательский интерфейс приложения Safe Network

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

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

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

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

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

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

Но больше нет! Мы можем сделать компенсацию инфляции более понятной и надежной, но немного более ручной, если мы просто продолжим и создадим ручное пополнение.

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

Помогите другу войти в Сеть и заплатите ему за обед сразу.

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


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

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