Обновление Safe Network 🇷🇺 18 февраль 2021 г

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

Резюме

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

  • Добавлен новый набор сообщений инфраструктуры, которые sn_routing может использовать для лучшей обработки и возврата ошибок во время разделения и оттока разделов.
  • Началась работа по обращению с недействительными SignatureShares злоумышленниками при передаче, и в настоящее время составляются и согласовываются штрафы для этих злоумышленников.
  • Работа с потоком сообщений близится к завершению, что означает значительно меньшее количество кода и сложность для анализа входящих сообщений в sn_node и освобождает путь для интеграции вознаграждений.
  • Выпущены новые версии CLI (v0.19.0) и authd (v0.1.1), что делает их совместимыми с последней версией sn_node (v0.26.16), а также включает ряд других улучшений.
  • Самый первый пример приложения теперь доступен в ящике sn_api, демонстрирующий, как загрузить файл в сеть, а затем получить его, используя его XOR-URL.
  • Мы предпринимаем шаги по интеграции sn_fs и BRB, чтобы создать прототип распределенной файловой системы P2P с византийской отказоустойчивостью.
  • Модификации цепочки разделов sn_routing для разрешения разветвлений сейчас в основном на месте, и наше тестирование показывает значительное улучшение стабильности сети, особенно вокруг разделений.
  • Еще один фантастический вклад сообщества в базу кода :heartbeat:

Статус тестовой сети - на удержании

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

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

Спасибо за ваше терпение!

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

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

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

Чтобы лучше справляться с проблемами при разделении разделов и во время оттока, мы добавили новый набор сообщений инфраструктуры, которые sn_routing может использовать для возврата ошибок, таких как DKGINprocess, когда мы пытаемся сообщить старейшинам в такое время. Для этого клиенты / узлы будут предоставлять текущий PublicKey для раздела, насколько им известно, и мы можем принять меры, если он, например, устарел. Эти изменения были добавлены в sn_messaging, sn_client и sn_routing, и мы рассматриваем несколько небольших рефакторов, чтобы упростить работу с узлами.

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

Наказание плохих исполнителей

Обработка недействительных SignatureShares злоумышленниками при передаче также находится в разработке. До сих пор мы одобряли передачу всякий раз, когда действительные доли “threshold + 1” были успешно агрегированы, игнорируя любые неисправные доли, которые не нужны для этого агрегирования. Теперь мы введем механизмы штрафов в сети, чтобы наказать узлы соответствующим образом после проверки. Мы начинаем наш рефакторинг с sn_transfers, так как именно здесь происходит накопление платежей для переводов, а затем мы продвигаемся вверх по уровням.

Поток сообщений

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

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

API и CLI

На этой неделе были выпущены новые версии CLI (v0.19.0) и authd (v0.1.1), которые включают в себя все исправления, улучшения и новые функции, реализованные с момента предыдущего выпуска. Как обычно, их можно обновить с помощью «$ safe update» и «$ safe auth update» соответственно. Эти приложения совместимы с последней версией sn_node v0.26.16, поэтому при обновлении убедитесь, что вы также обновили двоичный файл sn_node ($ safe node install или $ safe node update).

@scorch обнаружил, что самая последняя версия clippy жаловалась на Windows из-за CLI и кодовой базы authd, и представила исправление для этого. Это привело к тому, что мы улучшили резкие проверки в наших сценариях CI для запуска не только в Linux, но и в Windows, что должно предотвратить повторное проскальзывание этого.

С добавлением (посредством @mav) нового API в наш тип данных последовательности CRDT для извлечения записи, указывающей один индекс, а не диапазон, @mav теперь изменил наш sn_api, чтобы использовать этот новый API для получения определенной версии последовательности.

В этот новый интерфейс командной строки (v0.19.0) также было внесено несколько улучшений, которые позволяют пользователю настраивать информацию начальной загрузки для сети с использованием IP-адреса (v4 или v6) и номера порта. Для получения дополнительных сведений об этой новой команде см. в соответствующий раздел в Руководстве пользователя CLI.

Для тех, кому интересно посмотреть, как развивается Rust API и как он будет выглядеть при создании приложения с его помощью, самый первый [пример приложения теперь доступен в ящике sn_api](MaidSafe · GitHub sn_api/blob/master/sn_api/examples/file_upload.rs), который демонстрирует, как загрузить файл в сеть, а затем получить его, используя его XOR-URL. Надеюсь, это вдохновит других на создание других простых примеров приложений для нашего Rust Safe API, узнает о возможностях улучшения, когда мы начнем их использовать, а также станет хорошим ресурсом для новых разработчиков, желающих писать безопасные приложения.

CRDT

Дэвид Русу, автор rust-crdt, а также нашей реализации BRB, проверял код LSeq после того, как @mav сообщил о проблемах с это когда выполняется много вставок. Он заменил реализацию ID, основанную на оригинальной статье LSeq, на рациональное число из ящика num. Это значительно упрощает код LSeq, а также приводит к лучшему (более равномерному) распределению, решая проблему и позволяя вставлять произвольное количество элементов. LSeq также был переименован в List. Запрос на извлечение.

BRB - Византийская надежная трансляция

Помните sn_fs, наш прототип файловой системы с использованием дерева CRDT? На этой неделе мы делали шаги по интеграции sn_fs и BRB, чтобы создать прототип распределенной файловой системы P2P с византийской отказоустойчивостью.

Сначала мы разделили brb_node_qp2p и создали brb_node_tree, который демонстрирует отправку операций crdt_tree через brb. Затем мы модифицировали ящик sn_fs и превратили его в библиотеку. Совсем недавно мы создали ящик brb_node_snfs, в котором собрали все вместе. На сегодняшний день мы смогли вызвать два (или более) узла и выполнить такие операции с каталогами, как mkdir, rmdir. Операции отражаются в смонтированной файловой системе каждого однорангового узла. Файловые операции пока не работают, но скоро будут.

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

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

План проекта

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

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

Мы объединили другой PR, чтобы ответить с ошибкой на запрос клиента, если DKG продолжается. Текущее DKG (распределенное создание ключей) означает, что раздел собирается перейти к новому набору старейшин, и поэтому в настоящее время все может быть не совсем стабильным или последовательным, поэтому лучше сообщить клиенту, чтобы он отступил и попробовал агаиn немного позже.

[ОБНОВЛЕНИЕ 22 февраля] - Безопасный браузер

То, что мы изначально забыли добавить в это обновление: man_facepalming:

@bzee создал PR для ускорения работы sn_nodejs с последними изменениями API, который необходим для обновления Safe Browser до снова быть совместимым с остальной частью Безопасного ландшафта. Он также изучал ограничения текущей библиотеки и видел возможности для улучшения!.

Спасибо @bzee! :tada: и извиняюсь за то, что изначально пропустил ваш вклад в ОП.

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


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

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