Это машинный перевод. Оригинал на английском здесь: Safe Network Dev Update - January 7, 2021
Резюме
Вот некоторые из основных моментов, которые следует выделить после последнего обновления для разработчиков:
- С Новым Годом!
- Мы рады сообщить, что работа с динамическим членством завершена, и сегодня мы опубликовали несколько ящиков Byzantine Reliable Broadcast (BRB) на GitHub
. Все ссылки связаны из центрального brb crate. - Мы много работали, даже в праздничные дни, над улучшением уровня ошибок и обмена сообщениями, включая создание нового ящика
sn_messaging. - Мы находимся в процессе подготовки некоторых мелких исправлений для нового выпуска исправлений интерфейса командной строки.
- Мы также близки к тому, чтобы CLI и
authdбыли построены с помощью musl, что означает совместимость с большим количеством платформ. - У нас есть новый инструмент стресс-тестирования для маршрутизации с PR в настоящее время на рассмотрении. Этот новый инструмент предназначен для выявления ограничений маршрутизации с точки зрения того, как он обрабатывает изменения членства (отток), и уже привлек наше внимание к некоторым проблемам.
Обновление тестовой сети
Спасибо всем, кто нашел время, чтобы опробовать код testnet, выпущенный перед Рождеством. Теперь, когда вся команда MaidSafe снова за своими столами, мы продолжаем работать над некоторыми проблемами, которые мы определили перед выпуском, и другими, которые вы указали для нас. Как только мы убедимся, что эти проблемы решены, мы объявим еще одну итерацию с намерением разместить общедоступную тестовую сеть для всех, кто сможет подключиться.
Безопасный клиент, узлы и qp2p
План проекта безопасных сетевых передач
План проекта безопасного клиента
План проекта безопасного сетевого узла
Мы работали над улучшением нашей истории ошибок во всех наших библиотеках и перешли на использование thiserror на всем узле / data_types / client / transfer чтобы обеспечить лучшую цепочку ошибок и лучшую инкапсуляцию функциональности. Раньше мы использовали много смешанных ошибок, перетаскивая много из sn_data_types в другие библиотеки. Теперь у нас есть определенные ошибки в каждой библиотеке для этой библиотеки, и мы распространяем ошибки только из нижних библиотек как другую версию ошибок текущей библиотеки.
Вдобавок к этому мы извлекли sn_messaging из sn_data_types в отдельный ящик, чтобы отделить наш уровень связи, а также ошибки, которые мы буду отправлять на / от других узлов и клиентов. Это небольшой шаг к более четкому определению сетевого «API» сообщений и ошибок, который обеспечивает более четкое разделение ошибок от внутренних библиотек для клиента.
В рамках этих усилий мы изучаем различные типы сериализации, с конечной целью получить тот, который не зависит от языка программирования. В данный момент мы сосредоточены на простой сериализации JSON (в отличие от используемого в настоящее время bincode), но также поиграем с Msgpack.
Эффектом всего этого стал более чистый код и более четкие потоки ошибок во всех задействованных библиотеках, и это здорово.
В тандеме мы удалили клиентские «проблемы» из потока начальной загрузки узла / клиента. Ранее они использовались для проверки того, что клиент держал ключи, чтобы предотвратить атаки с повторением сообщений. Но с идемпотентностью, исходящей из типов данных AT2 и CRDT, это будет обработано там. Еще одно упрощение как для клиента, так и для узла, и дополнительно разъясняет сетевые операции как только подписанные сообщения.
Раньше, чтобы предотвратить атаки по продаже ключей в сети, мы удалили все API, раскрывающие SecretKey, из sn_routing и поместили их только в их ящик. Однако мы обнаружили, что из-за этого удаления возникло несколько осложнений в дереве зависимостей, и поэтому согласились вернуть эти API-интерфейсы, чтобы мы могли быстро продвигаться вперед с тестовой сетью во время праздников. Мы решили сразу заняться этой проблемой и начали рефакторинг ящиков sn_transfers и sn_node, где мы храним и используем секретные ключи вне sn_routing.
Работа по агрегированию подписи, выполняемая sn_node во время обмена сообщениями между KeySection и DataSection, возможно, дублируется работой по накоплению консенсуса маршрутизации, поскольку оба фактически выполняются старшими узлами. Мы исследуем и проводим некоторую работу по рефакторингу, пытаясь удалить эту часть из ящика sn_node и доверять сообщениям консенсуса от sn_routing.
И последняя небольшая работа по удалению управления потоком с узлов. Это было вставленоместо для поддержания связи с клиентами, но с недавними изменениями qp2p мы можем полагаться на пул соединений там, чтобы справиться с этим за нас и, таким образом, упростить работу с клиентом узла. Мы также находимся в процессе рефакторинга примеров qp2p на отдельные части, чтобы ясно и отчетливо продемонстрировать echo_service и системы обмена сообщениями. Мы проводим пробные запуски этих примеров с ручной переадресацией портов, чтобы потенциально поддерживать маршрутизаторы, несовместимые с IGD, в дальнейших тестовых сетях.
API и CLI
Мы сосредоточились на изменениях и улучшениях со стороны сети, однако мы все еще работаем над устранением некоторых незначительных ошибок, о которых сообщало сообщество при использовании тестовой сети, поэтому сейчас готовятся некоторые незначительные исправления для нового патча CLI.
Кроме того, мы пытаемся создать следующий выпуск CLI и authd с помощью musl, что, как мы знаем, позволит нам запускать эти приложения. на многих других платформах, использующих те же выпущенные артефакты. Мы уже смогли собрать их вручную (большое спасибо @mav и @tfa за их вклад и вклад в это), поэтому сейчас мы надеемся включить это в нашу CI в ближайшие дни.
BRB - Византийское надежное вещание
Мы рады сообщить, что работа с динамическим членством завершена, и сегодня мы опубликовали несколько ящиков Byzantine Reliable Broadcast (BRB) на GitHub . Все ссылки связаны из центрального brb crate.
Система BRB состоит из:
1. Основной протокол широковещательной передачи BRB для членов кворума для репликации данных в стиле BFT.
2. Протокол динамического членства для узлов, которые динамически присоединяются и оставляют активный кворум.
3. Оболочки типов данных, которые инкапсулируют совместимые типы данных (например, CRDT) для передачи через BRB.
4. Комплексные тесты для проверки правильности.
5. brb_node_qp2p: пример приложения / узла CLI для ручного вызова функциональности BRB.
Для тех, кто хочет вникнуть в подробности, доступны слайды, которые дают более подробное представление о системе и протоколах.
Маршрутизация
Как мы все знаем, перемещение полезно для сети, в том числе способствуя старению узлов. Однако мы заметили, что в некоторых случаях мы переезжали. Например, мы перемещались, даже когда у нас не хватало старейшин из-за оттока, а также перемещали узлы, когда они только что присоединились. Чтобы решить эту проблему, мы установили некоторые критерии избежать чрезмерного перемещения, чтобы сохранить стабильность сети в определенных сценариях.
Также было внесено изменение API, чтобы вернуть информацию о разделе для указанного целевого имени. Это в основном для использования sn_node для предстоящей работы по рефакторингу.
Мы составили стресс-тест для маршрутизации (PR на рассмотрении). Это небольшой инструмент, предназначенный для обнаружения ограничений маршрутизации с точки зрения того, как он обрабатывает изменения членства (отток). Он генерирует случайный отток в соответствии с настраиваемым расписанием. Затем он периодически выводит различную полезную информацию о сети и измеряет состояние сети. Этот инструмент будет очень полезен для предстоящей работы по интеграции нового решения для динамического членства. Запустив его в текущей версии маршрутизации, он уже обнаружил некоторые проблемы, которые у нас есть, связанные с перемещениями и разделениями, которые мы скоро рассмотрим. Это действительно хорошо, потому что первый шаг к устранению проблемы - знать о проблеме: smile: Вот небольшой снимок экрана с результатами работы инструмента:
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!