Это машинный перевод. Оригинал на английском здесь: Safe Network Dev Update - December 3, 2020
Резюме
Вот некоторые из основных моментов, которые следует выделить после последнего обновления для разработчиков:
sn_nodeвыпустил свои первые релизы с июля!sn_routingвыпустил первые релизы с августа 2018 года!- У нас есть тесты
sn_client, работающие и вроде бы стабильно работающие. - Мы решили основную проблему с запуском раздела в CI.
- Мы проводим последние несколько оставшихся неудачных тестов sn_api.
- Рабочий прототип кода для подхода Generation Clock к динамическому членству ожидается к концу недели.
- На этой неделе были объединены два важных PR «sn_routing»: мера защиты от атак с продажей ключей и проверка ресурсов во время потенциальных новых узел начальной загрузки
Безопасный клиент, узлы и qp2p
План проекта безопасных сетевых передач
План проекта безопасного клиента
План проекта безопасного сетевого узла
Эта неделя стала важной вехой для sn_node с первым выпуском и публикацией этого ящика под новым названием, и первый с июля. За прошедшие месяцы там было много изменений, поскольку журнал изменений, поэтому четко выделяется, и как мы стараемся держать вас в курсе в этих обновлениях. Эти выпуски не означают, что разработка завершена в sn_node, просто мы сочли его достаточно стабильным, чтобы теперь объединить ранее созданный PR конвейера непрерывной доставки. Разработка продолжается в темпе, и теперь каждый объединенный PR будет приводить к автоматически генерируемой новой версии.
Мы объединили работу с улучшенной обработкой ошибок в sn_node, что очищает путь для продвижения. После удаления кеширования последовательностей на прошлой неделе, на этой неделе мы подвергли клиента более нормальным сетевым условиям, что привело к нескольким неудачным тестам. С некоторыми настройками клиентских тестов, чтобы учесть это, они теперь снова стабильны. Вдобавок к этому мы рассмотрели запуск раздела, который локально работает нормально, но у CI возникли трудности. Мы установили, что отчасти это происходит из-за того, что машины CI работают медленно, и увеличение тайм-аутов между запуском узлов дает нам более надежные результаты. Здесь все еще есть некоторые ошибки, которые нужно исправить.
В ходе сквозного тестирования сети мы добились еще большего прогресса в некоторых неудачных тестах, особенно в отношении хранения данных с использованием типа данных Blob. Мы выявили некоторые проблемы, которые возникли во время некоторых рефакторингов, и с исправленными теперь мы видим, что тесты проходят стабильно. Теперь мы переходим к повторному включению системы репликации фрагментов, когда узлы покидают сеть. Как только это будет сделано, все потоки Blob будут повторно включены в реорганизованной реализации sn_node.
Еще одна функция, над которой мы работали на этой неделе, - это регулирование хранилища в разделе и, в конечном итоге, в сети с помощью PR # 1153. Что касается этого PR, узлы хранения данных контролируют свое хранилище при каждой выполняемой записи, предупреждая своих старших по разделам, если они достигают своей максимальной емкости. Затем старейшины ведут реестр этих заполненных узлов, и когда они достигают порогового значения заполненных узлов в том же разделе, они голосуют за принятие новых узлов для присоединения к их разделу, закрывая ворота, как только спрос / предложение удовлетворяется, тем самым поддерживая баланс. в сети. В ближайшие дни мы будем работать над различными настройками показателей.
PR для Rust-CRDT был поднят, чтобы привести LSeq в соответствие с другими типами CRDT, когда нужно вызвать apply перед изменение самого типа данных. Мы используем это в нашем типе данных Sequence, чтобы гарантировать, что все операции подписаны.
Изменения в sn_api и CLI продолжились на прошлой неделе, адаптируясь к новым API-интерфейсам sn_client и, как упоминалось на прошлой неделе, также пытаясь перейти на новую терминологию UX. У нас большая часть тестов sn_api проходит сейчас с использованием локального раздела, и сейчас мы пытаемся завершить эти изменения, а также разрешить неудачные тесты, что, как мы надеемся, должно означать, что команды CLI и тесты E2E будут снова запущены и запущены.
И, наконец, для увеличения тестового покрытия переводов, платежей, d вознаграждает модули, на этой неделе была начата некоторая реструктуризация этого кода и изменения гранулярности доступа.
BRB - Византийское надежное вещание
Продолжается работа над подходом Generation Clock к динамическому членству. К концу недели ожидается рабочий прототип кода.
На параллельном пути ящик bft-crdts разделяется на отдельные ящики в рамках усилий по модульности. Идея состоит в том, чтобы определить 3 характеристики: одну для реализации BRB, одну для типов данных, которые нужно передать и защитить, и одну для сетевого уровня.
Таким образом, реализации всех трех характеристик могут быть смешаны и согласованы. Например, мы можем использовать использование сети в памяти для тестовых примеров, имплицит qp2p для маршрутизации в безопасной сети, а третья сторона может использовать реализацию сокетов TCP / IP для чего-то еще. Что касается данных, у нас уже есть реализация банка AT2 и реализация CRDT orswot.
Маршрутизация
Как упоминалось выше, на этой неделе впервые был опубликован и выпущен sn_node в его нынешнем виде. Чтобы не отставать, команда маршрутизации теперь также выпущена и опубликована sn_routing, первый выпуск почти за 2,5 года! См. Журнал изменений для ознакомления с внесенными изменениями. Как и в случае с sn_node, эти выпуски не означают, что разработка завершена в sn_routing, просто мы сочли его достаточно стабильным, чтобы теперь объединить ранее созданный PR конвейера непрерывной доставки. Разработка продолжается в темпе, и теперь каждый объединенный PR будет приводить к автоматически генерируемой новой версии.
На этой неделе мы реализовали меру защиты от атак с использованием ключевых продаж. Атака с продажей ключа - это когда узел, который заработал свою репутацию, продает свой секретный ключ потенциально вредоносному объекту, который затем может взять на себя его роль и нанести ущерб. Этот тип атаки очень трудно полностью предотвратить, но мы, по крайней мере, затруднили доступ людей к секретному ключу, убедившись, что ключ не открыт и не хранится на диске.
Мы также работали над внедрением процесса проверки ресурсов во время начальной загрузки, который был объединен сегодня. Это заставляет любые потенциальные новые присоединяющиеся узлы гарантировать, что они достаточно квалифицированы для разделения сетевой нагрузки. После проверки проверки ресурсов все вновь присоединенные узлы будут сразу же считаться «взрослыми» - обработка «младенческих» узлов больше не требуется.
Мы также работали обновление раздела рефакторинга, которое предназначено для упрощения кодовой базы обработки DKG. Для этого предлагаются два основных изменения:
- Сбои DKG больше не будут сообщаться старшим в текущем разделе, вместо этого он перезапускается сам.
- Отдельный аккумулятор результатов DKG будет удален, вместо использования обычного аккумулятора голосования.
Однако после обсуждений в процессе проверки было обнаружено больше проблем, которые мы решили решить. Следовательно, ОР был изменен на статус Черновика и, как ожидается, скоро будет снова готов к рассмотрению с добавлениями.
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества. Так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!