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

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

Резюме

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

  • Прием волонтеров для фонда BambooGarden завершен! У нас есть 8 уважаемых и опытных членов комитета из сообщества.
  • После утверждения комитета фонда BambooGarden мы перейдем к настройке каналов связи и возможности пригласить первые заявки на участие в фонде.
  • За последнюю неделю мы внесли несколько относительно небольших изменений в клиентскую базу кода, в результате чего мы видим, что большинство клиентских тестов проходит последовательно в многосекционной сети.
  • После стабилизации клиента мы смогли повторно включить выплату вознаграждений и теперь работаем над устранением проблем и оптимизацией.
  • Внедрение ленивого обмена сообщениями продолжается повсеместно.
  • Дополнительные вопросы поступают в AMA и другой ответ тоже см. последнее видео @jimcollinson здесь
  • Мы опубликовали обзор функций для предстоящей тестовой сети ранее на этой неделе.
  • Регулярно следите за веткой Like This Tweet на форуме, чтобы получить отличные рекомендации о том, как способствовать продвижению безопасной сети, и окружающие компоненты, простым нажатием кнопки! :bird:

Новости фонда BambooGarden

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

Изначально мы планировали иметь 3 члена комитета сообщества одновременно, но решили изменить это так, чтобы в комитет входили все 8 из этих добровольцев. Это изменение имеет несколько преимуществ, например, позволяет нам максимально использовать разнообразный опыт и знания, которые они предлагают. Также неизбежно, что будут времена, когда у некоторых членов комитета будут другие обязательства, поэтому это большее число означает, что мы можем продолжать работать без проблем, несмотря ни на что. Члены смогут воздержаться при голосовании, если они не могут этого сделать или даже если они не считают себя квалифицированными для рассмотрения заявки, не беспокоясь о том, что они покинут комитет.

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

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

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

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

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

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

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

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

Улучшения клиентского кода

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

Награды

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

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

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

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

Соседи маршрутизации

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

API и CLI

После завершения изменений, необходимых для нового типа данных CRDT «Register» в крейтах sn_node и sn_client, мы начали адаптировать кодовую базу sn_api и ее API для ее поддержки.

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

Мы также начали с адаптации всех наших абстракций (NRS, FilesContainers и Wallets) для использования этого типа данных. Здесь мы видим большую проблему с точки зрения UX, учитывая, что чтение FilesContainer может привести к просмотру более чем одного состояния, как описано выше. Таким образом, теперь мы ищем лучший способ представить это в нашем API, чтобы пользователь и / или разработчик приложенияон может решить, что делать в таких ситуациях. Например, конечному пользователю может быть предложено решить не только какую ветвь читать, но также, возможно, как снова объединить их в одну ветку. Как вы уже можете видеть, может быть несколько способов, которыми пользователь или разработчик хотел бы разрешить возникновение ветвей в данных, и теперь это основной драйвер для нового дизайна этих API.

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

CRDT

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

Мы также доработали дизайн новой MultiMap CRDT на основе MerkleReg. Это, вероятно, будет основой для типов данных поддоменов NRS, а также гибкой структурой для других приложений, которым требуется карта, подобная типу данных.

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

Дополнительные вопросы поступают в AMA и еще один ответ тоже. На этот раз @jimcollinson решает вопрос от @dimitar: _Слишком поздно для конфиденциальности в Интернете? Разве они еще не получили всю нашу информацию? _

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


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

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