Это машинный перевод. Оригинал на английском здесь: Safe Network Dev Update - February 11, 2021
Резюме
Вот некоторые из основных моментов, которые следует выделить после последнего обновления для разработчиков:
- Выпуск тестовой сети все еще приостановлен, так как мы работаем над завершением некоторого рефакторинга потока сообщений, который блокирует выполнение вознаграждений.
- Работа по рефакторингу потока сообщений идет хорошо, с черновиком PR. Это приведет к более чистому, простому и эффективному потоку сообщений.
- Мы перенесли наши сценарии развертывания / удаления тестовой сети на использование terraform, что привело к значительному сокращению времени, необходимого для создания тестовых сетей любого размера для внутреннего / внешнего тестирования. развертывание.
- Потратив некоторое время на работу с настройкой «без вознаграждений», мы смогли выявить и устранить некоторые ошибки, которые в противном случае оставались бы скрытыми до тех пор, пока не были полностью реализованы вознаграждения.
- Новая подкоманда
$ safe networks setреализуется в интерфейсе командной строки, которая позволит пользователям более легко подключаться к сетям, просто используя свой начальный IP: адрес порта с соответствующим PR сейчас проходит проверку. - Мы считаем, что нашли решение для разветвления цепочки разделов в sn_routing. Это решение в настоящее время внедряется, и мы уверены, что оно поможет сделать тестовые сети достаточно стабильными, чтобы справиться с исследованиями сообщества.
-
Вклады кода сообщества продолжают поступать!
Статус тестовой сети - на удержании
Опять же, мы стремились включить награды в общедоступную тестовую сеть на этой неделе, но некоторая связанная с этим работа по настройке потоков сообщений после того, как мы переключились на накопление сообщений только в sn_routing, которое влияет на все части sn_node, изменилась это займет больше времени, чем мы ожидали. Эта работа в настоящее время блокирует продвижение наград.
Ранее на этой неделе мы решили сосредоточить некоторую энергию на альтернативе тестовой сети без вознаграждений, т. Е. Исключить часть потока вознаграждений, что мы начали на прошлой неделе. Мы добились неплохого прогресса в этом вопросе, но по пути столкнулись с несколькими проблемами блокировки, которые нам пришлось применить несколько «хитростей», чтобы временно решить их, пока не появятся награды и соответствующие функции. Получившимся в результате сетям «без вознаграждения», которые мы раскручивали, не хватало стабильности, надежности и согласованности, поэтому в нынешнем виде мы не считаем, что есть смысл запускать тестовую сеть без вознаграждения. Этот альтернативный подход действительно имел некоторые преимущества на этой неделе, поскольку он позволил нам немного продвинуться в многосекционном тестировании, что привело к выявлению и исправлению нескольких проблем, которые в противном случае мы не увидели бы до тех пор, пока не появятся награды и соответствующие функции.
Мы по-прежнему ожидаем, что тестовая сеть будет размещена как можно скорее, смещая акцент назад, чтобы снова двигаться вперед с вознаграждением и выпустить надежную тестовую сеть с этим. Возможно, мы проведем еще немного тестов, используя работу «без вознаграждения», чтобы увидеть, сможем ли мы обнаружить что-нибудь еще, что скрывается для нас в будущем.
Подготовка и тестирование тестовой сети
Ближе к концу прошлой недели мы пытались опубликовать большие тестовые сети, и быстро стало очевидно, что наш сценарий bash для этого не годится для работы - запуск 20 узлов или около того занимает 30 минут, а это чертовски дольше. запустить 100 узлов! Таким образом, мы перешли на terraform для управления развертыванием / уничтожением дроплетов и узлов, и это на много лучше. Теперь мы можем запустить 40 с лишним узлов за несколько минут. Мы довольно активно использовали это для итерации, и теперь мы настроили его, чтобы мы могли также развертывать собственные сборки узлов. Что оказалось очень кстати на итерационном фронте. PR для этого перехода на terraform на месте и довольно тщательно протестирован сейчас, с некоторой очисткой перед слиянием.
На каком-то этапе в течение недели мы довольно регулярно видели, как внутренние тестовые сети хотели разделиться, но не делали этого. Мы начали отладку с меньшими разделами (например, 3 старших, размер раздела 5 узлов), чтобы вызвать большее количество разделений, но это не помогло. Оказалось, что мы не видели разделений, так как наш код зависел от разделов Elders moving, но на самом деле это не требуется (в нынешних условиях). Как и все вероятности, даже эти маловероятные события, казалось, происходили достаточно часто … и поэтому все наши старейшины попадали в одну половину раздела и, таким образом, формировали новый раздел для себя, без необходимости менять ключ , и ни один из наших кодов не выполняется.
Благодаря большему количеству исправлений ошибок, наряду с удалением некоторых переработанных функций вознаграждений, мы устранили проблему, которая возникала при запуске сети, когда при каждом оттоке в разделе генезиса недавно повышенный старейшина повторно предлагал генезис выплату еще раз, заставляя остальных старейшин ждатьВыплата другого генезиса, которая изначально должна была произойти только один раз. С этим прибавленным, мы также устранили еще одну связанную ошибку, при которой не происходило накопления подтверждения платежа Genesis (мы сохраняли все платежные события, кроме проверочных); что помогло сдвинуть дело с мертвой точки.
После этого мы также столкнулись с некоторым зацикливанием в sn_routing, которое, как было замечено, приводило к некоторому высокому использованию памяти, что могло привести к смерти узлов. Мы знаем, в чем проблема, и на данный момент приняли временные меры, чтобы этого не произошло. Со временем появится более постоянное исправление.
Выполнив все вышеперечисленное с помощью ветки no-rewards, мы, наконец, добрались до стадии, когда мы могли видеть, что большинство клиентских тестов проходит, а сбои выделяют несколько других проблем, таких как случайное попадание в какой-то код, который мы не должны получить доступ (для этого требуется некоторая обработка ошибок), и теперь мы решаем проблему с клиентскими кошельками. Получение набора клиентских тестов немного экологичнее, чтобы подготовиться к тому, когда поток вознаграждений снова будет полностью интегрирован.
Безопасный клиент, узлы и qp2p
План проекта безопасных сетевых передач
План проекта безопасного клиента
План проекта безопасного сетевого узла
QP2P
На прошлой неделе мы протестировали новый qp2p API со всеми нашими ящиками. Первоначально были некоторые проблемы, но теперь все они устранены, и мы находимся на стадии финального обзора и слияния по всем направлениям. Мы будем включать эти изменения во время сквозного тестирования, и они станут частью следующего выпуска тестовой сети.
Сообщения
Недавно мы перешли к накоплению сообщений только в sn_routing, раньше мы не делали это и в sn_node. Чтобы завершить этот рефакторинг, было изменено много кода, но также удалено около 1350 строк.
В результате поток сообщений становится проще, чище и эффективнее.
Работа над этим в настоящее время продолжается, и прогресс отслеживается черновиком PR. Это поможет нам продвинуться вперед с потоками сообщений в целом, но, что очень важно, теперь и с наградами, которые были немного сдержаны этими обновлениями.
API и CLI
Технический долг, который у нас был в нашем ящике sn_api, заключался в том, чтобы заставить наш тип / s Error реализовать черту std :: error :: Error. Это то, что мы завершили и объединили на прошлой неделе с помощью thiserror ящик. Мы также изменили кодовую базу CLI, чтобы использовать в любом случае, поэтому все функции теперь возвращают anyhow :: Result, и обработка ошибок стала намного проще без потери информации или контекста. о первопричине каждой распространенной ошибки.
В CLI внедряется новая подкоманда «$ safe networks set», которая позволит пользователям более легко подключаться к сетям, просто используя их начальный IP: адрес порта. Соответствующий PR включает обновление Руководства пользователя, поэтому всем, кто заинтересован в раннем предоставлении отзывов об этой команде, просим вас взглянуть на описание здесь.
На прошлой неделе сообщества продолжали поступать. Существует работа в процессе от @bzee, чтобы сделать пакет nodejs совместимым с последней версией sn_api, а также исправление в CLI, чтобы удалить имя флага, которое вызывало конфликт между двумя разными командами (https://github.com/maidsafe/sn_api/pull/708). PR также был поднят и объединен, чтобы удалить реализацию ведения журнала из sn_client, поскольку это следует оставить приложениям или двоичным файлам, которые используют библиотеку, что делает убедитесь, что приложения не получают неожиданный вывод на stdout или stderr.
Поскольку большинство зависимостей наших ящиков используют tiny-keccak v2.0.2, @mav отправляет PR, чтобы обновить все наши ящики, чтобы они зависели от этой же версии. Мы все очень ценим усилия всех, кто участвует, как только может: clap:
BRB - Византийское надежное вещание
Мы проделали некоторую дополнительную работу над brb_node_qp2p, чтобы заставить его работать с двунаправленными потоками и новым (скоро) API qp2p. Это позволяет каждому узлу отправлять и получать из одного и того же порта вместо открытия новых соединений через отдельный случайный порт для исходящих пакетов. В процессе мы добавили пару небольших PR в qp2p. Один, в частности, упрощает совместное использование конечной точки qp2p между потоками, что должно стать победой для любого, кто создает приложение p2p с библиотекой.
sn_data_types
У нас есть дизайн для упрощения Политики / Разрешениялогика, регулирующая доступ к сетевым данным, в настоящее время проходит внутреннюю проверку. У нас также есть PoC для нового Chain CRDT, который может оказаться лучшим базовым CRDT для нашего типа данных Sequence. из поднятого вопроса @mav, касающегося нашего типа данных Sequence.
Маршрутизация
На этой неделе мы изучали многообещающий подход к разрешению вилок. Резюмируя: у нас есть нечто, называемое «цепочкой разделов», которая представляет собой список ключей раздела, связанных вместе с подписями. Его можно использовать для доказательства того, что часть данных была подписана группой узлов, которые когда-то были действительными членами раздела, даже после того, как эти узлы давно исчезли. В настоящее время эта цепочка требует, чтобы секция согласовала, какой ключ добавить к ней следующим. Если есть разногласия по этому поводу, цепочка может разделиться на две (или более) взаимно несовместимые цепочки, которые могут в настоящее время разорвать раздел. Это может произойти, например, во время сильного оттока. Мы надеялись, что сможем обойтись без решения этой проблемы немного дольше, то есть до тех пор, пока не будет отключена тестовая сеть, но оказалось, что мы иногда видим вилки даже в относительно небольших тестовых сетях.
Итак, мы были заняты обсуждением того, как лучше всего решить эту проблему, и пришли к нескольким многообещающим идеям. В настоящее время реализуется одна такая идея, которая, как мы надеемся, поможет сделать тестовые сети достаточно стабильными, чтобы справиться с исследованиями сообщества. По-прежнему существуют некоторые потенциальные опасения по поводу безопасности и возможных векторов атак, но они будут рассмотрены позже. Сейчас в центре внимания стабильность. Шаги малыша.
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!