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

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

Резюме

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

  • В пятницу, 26 февраля (завтра) в 21:00 по Гринвичу, состоится виртуальная встреча Community Safe Chat. Полная информация здесь.
  • Идентификация и устранение ошибок продолжается, наряду с несколькими улучшениями эффективности, поскольку на этой неделе мы добились значительного прогресса на пути к общедоступной тестовой сети.
  • На этой неделе было объединено несколько значительных PR “sn_routing”, в частности PR # 2323, PR # 2328 и PR # 2336. Полная информация ниже.
  • Два других важных PR “sn_routing”, # 2335 и # 2336, оба критических для стабильной тестовой сети, сейчас поднимаются и должны быть пересмотрены и объединены в ближайшие дни.
  • @scorch отправил PR, чтобы (наконец!) решить «эту проблему», когда версии самого интерфейса командной строки и внешних двоичных файлов, таких как sn_node или sn_authd где перепутали.
  • Ознакомьтесь с отличным копанием и анализом @bzee здесь, поскольку он стремится улучшить и обновить привязки к Node.js.

Безопасный чат сообщества: пятница, 26 февраля, 21:00 по Гринвичу

Маркетинговые усилия сообщества продолжаются благодаря работе @sotros25, @m3data, @piluso и других. Надо сказать, неутомимые усилия!

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

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

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

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

Полная информация и ссылка для присоединения будут доступны здесь.

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

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

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

С изменениями в инфраструктуре обмена сообщениями, завершенными на прошлой неделе, узлы больше не включают никакой логики для агрегирования подписей, полностью полагаясь на способность маршрутизации делать это. Раньше у нас была агрегация только в источнике, где маршрутизация агрегировала подписи в Elders перед отправкой в ​​цель, в результате чего сообщение с агрегированной подписью отправлялось в пункт назначения несколько раз, а дубликаты отфильтровывались на целевом узле. Перенеся агрегирование подписей в место назначения, мы можем снизить некоторую нагрузку со стороны старейшин и значительно сократить количество сообщений, которыми обмениваются. Мы добавили поддержку накопление пунктов назначения в маршрутизации и использовали это в sn_node для связи между разделом и взрослыми, содержащими его фрагменты. С двумя вышеупомянутыми исправлениями у нас теперь есть все клиентские тесты, проходящие в одном разделе, с значительно упрощенным кодом узла. Тем не менее, необходим дополнительный PR, чтобы охватить дополнительный вариант использования, который представляет собой общение между старейшинами в одном разделе и старейшинами в другом разделе, часть потока вознаграждений (поскольку средства раздела управляются одним разделом, но удерживаются / проверяются. в другом разделе). Это освещается, пока мы говорим, и их следует объединить до конца недели.

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

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

В качестве задачи с более низким приоритетом и параллельно с описанным выше мы начали подготовку к обновлению до новой версии Quinn, которая позволяет нам наконец перейти на стабильную версию Tokio v1. Мы только что попробовали и готовим PR для этой миграции, как только будет опубликован выпуск Quinn v0.7.0.

Еще одно улучшение, сделанное на этой неделе, касается удаления личных данных. Перед недавно объединенными изменениями в self_encryption и sn_client, удаление частного большого двоичного объекта означало удаление только корневого большого двоичного объекта, который был картой данных фактических данных, которые самошифруются и хранятся в сети. В нашем последнем дополнении к команде, @kanav, реализован подход рекурсивного удаления, который удаляет отдельные фрагменты вместе с фрагментами, в которых хранятся карты данных, обеспечивая удаление в истинном смысле.

API и CLI

@scorch отправил PR, чтобы удалить параметр -V из подкоманд CLI, чтобы избежать путаницы между версией самого CLI и версией внешние двоичные файлы, такие как sn_node или sn_authd. Это изменение также включало добавление подкоманды bin-version к подкомандам $ safe node и $ safe auth для получения версии внешних двоичных файлов, так что семантика ясна, а также различие между CLI version и версии sn_node или sn_authd.

В настоящее время реализована библиотека qjsonrpc для поддержки стандарта JSON-RPC 2.0. Тем не менее, есть определенные коды ошибок, определенные в спецификации, которые не были обнаружены ящиком. Это означает, что потребители должны сами переопределять одни и те же константы, что не обязательно, поскольку они в некотором смысле являются частью реализации. По этой причине @scorch также отправил PR, чтобы раскрыть эти коды ошибок как константы из qjsonrpc.

Как упоминалось в предыдущем разделе, мы также пытались подготовиться к обновлению до Tokio v1, поэтому мы готовили крейты CLI и authd для такого обновления, выполнив некоторые предварительные тесты.

CRDT

Мы повторяли CRDT, лежащий в основе типа последовательности, в sn_data_types. Ранее Sequence реализовывался с помощью LSeq. Мы попробовали более простой List, чтобы устранить некоторые паники с помощью глубоких вставок, а затем перешли в GList для поддержки варианта использования только для роста. По результатам анализа, все эти CRDT не выполняют управление версиями моделей, как нам хотелось бы. Они пытаются линеаризовать порядок документов, когда на самом деле история документа формирует DAG. У нас есть дизайн CRDT регистра Merkle-DAG, который позволит нам достоверно моделировать историю документов и читать самые свежие версии.

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

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

Наша попытка интегрировать прототип файловой системы sn_fs с BRB обнажила несколько острых углов. Причина в том, что sn_fs получает операции от ядра операционной системы быстрее, чем они могут быть применены BRB. С этой целью мы придумали несколько связанных решений: 1) обойти сетевой уровень при отправке операции самому себе, и 2) отслеживать, когда одноранговые узлы получили ProofOfAgreement, чтобы мы могли избежать отправки следующей операции до 2 / 3 сверстников применили текущую операцию. Это необходимо для удовлетворения требований BRB к размещению заказов. Упорядочивание источников означает, что операции, поступающие из одного и того же источника (актора), должны быть последовательно упорядочены, однако операции от многих разных субъектов могут обрабатываться одновременно.

Также в рамках интеграции sn_fs мы модифицировали ящик brb_dt_tree для поддержки отправки нескольких операций с деревом в одной операции BRB. Это фактически дает нам свойство атомарной транзакции для применения логически связанных операций CRDT по принципу «все или ничего». Мы намерены использовать этот же шаблон в других типах данных BRB.

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

План проекта

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

Как подробно описано в разделе «Узлы» выше, мы также реализовали [накопление подписи сообщений в пункте назначения] (Add support for accumlation at dest node by lionel1704 · Pull Request #2328 · maidsafe/sn_routing · GitHub), что означает, что пользователям маршрутизации больше не нужно реализовывать этот поток вручную. , что приводит к упрощению кода.

Наконец, PR разрешения форка сейчас находится в стадии рассмотрения. Во время работы над этим PR мы обнаружили несколько дополнительных ошибок, не связанных с обработкой вилок. Всю неделю мы были заняты их отладкой, и на сегодняшний день, похоже, мы в основном исправили их все. Результаты внутреннего стресс-тестирования выглядят многообещающими, к тому же нам удалось запустить локальную сеть с ** 111 (!) Узлами ** на одной машине, и все прошло гладко. PR с этими исправлениями в настоящее время находится в статусе * черновик * и должен быть готов к рассмотрению в ближайшее время.

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


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

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