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

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

Резюме

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

  • Сегодняшний ожидаемый выпуск тестовой сети пришлось отложить, поскольку мы не могли вовремя получить вознаграждение, а отключение того, что у нас было до сих пор, все еще не сокращало его.
  • Возможность видеть разделение сети, происходящее в последние дни, с последними разработками, позволило нам найти и устранить некоторые ранее неизвестные многосекционные проблемы.
  • Работа по упрощению API ящика qp2p для внутреннего управления соединениями и потоками и снятия некоторой нагрузки с потребителя API теперь проходит экспертную оценку.
  • BRB PR для исправления случайных потерь пакетов, которые мешали операциям BRB, был поднят, протестирован и, как ожидается, будет вскоре объединен.
  • Особая благодарность членам сообщества @bzee, @mav и @scorch за их усилия на прошлой неделе по объединению нескольких PR сообщества.

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

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

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

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

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

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

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

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

Во-первых, на этой неделе PR от @bzee, который позволяет программно конфигурировать узлы, был объединен для управления сегодня. Хорошо сделано! : Raved_hands:

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

Помимо этого, мы отлаживали различные проблемы с разделением разделов, теперь, когда мы смогли увидеть это в действии (хотя и ограниченное из-за вышеупомянутых проблем), а веб-приложение @ mav node-logger оказалось отличным маленьким инструментом для быстрого просмотра межузловых потоков и сужения вывода журнала нашей многосекционной сети до чего-то более удобочитаемого.

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

За последнюю неделю мы внесли некоторые дополнения в ящик qp2p для внутреннего управления соединениями и потоками, чтобы снизить нагрузку на потребителя API. Эта работа завершена и в настоящее время проходит проверку в этом PR, при этом новый API также интегрирован с маршрутизацией с прохождением всех тестов. Мы откладывали выпуск общедоступной итерации тестовой сети перед их объединением, но с задержкой мы можем решить объединитьили заранее. Тестирование показало, что это изменение значительно упростило работу, и это значительно упростит отладку любых дальнейших сетевых проблем p2p.

API и CLI

На прошлой неделе было отправлено еще несколько PR сообщества, которые были объединены и уже являются частью новой версии CLI, только что опубликованной сегодня (v0.18.0).

Благодаря этот PR, представленный @mav, проверка NRS теперь исключает больший набор символов, которые никогда не имели бы разумной цели, включенной в какие-либо URL. Ограничение общей длины URL-адреса NRS в 255 байтов, где каждое подимя не может быть больше 63 байтов, теперь применяется с помощью этого другого PR .

Команды интерфейса командной строки safe auth теперь отдают приоритет аргументу --config по сравнению с использованием переменных среды, это также теперь используется в новой версии благодаря PR # 700, также отправлено @mav.

На стороне qjsonrpc PR # 698, представленный @Scorch реализует базовое приложение-пример клиент / сервер с использованием API qjsonrpc. Клиент qjsonrpc отправляет сообщение ping на сервер qjsonrpc, и сервер отвечает сообщением ack. Этот пример приложения просто и четко показывает, как qjsonrpc можно использовать для создания любого приложения с использованием JSON-RPC поверх QUIC. @Scorch проделал гораздо больше работы и исследований с большим количеством идей вокруг qjsonrpc - для тех, кто заинтересован в более подробной информации и / или в участии в этих усилиях, взгляните на его собственную ветку разработчиков, где он делится всем это. :хлопать в ладоши:

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

Мы подняли PR в brb_node_qp2p, чтобы исправить случайную потерю пакетов, которая мешала BRB операции. Это делает узел стабильным на случай, если какие-либо члены технического сообщества захотят «наладить» взаимодействие с BRB в среде CLI. Основные инструкции по использованию для этого приведены здесь (обратите внимание, что вы должны создать код самостоятельно, по крайней мере, на данный момент).

Обсуждения дизайна интеграции BRB с BLS Distributed Key Generation (DKG) продолжились с несколькими представленными вариантами. Согласие, похоже, срастается вокруг одного из вариантов. Подробная информация об этих планах будет представлена ​​в будущих обновлениях по мере начала работы.

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

План проекта

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

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


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

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