Это машинный перевод. Оригинал на английском здесь: Update 23 March, 2023
Мы знаем, что вы все стремитесь снова получить тестовую сеть, но есть одно или два исправления, которые нам нужно сделать в первую очередь, чтобы убедиться, что это даст нам ценные знания. Одна из них, в частности, заключается в обеспечении надежной работы старения узлов. @joshuef рассказывает больше о препятствиях и о том, как мы готовимся преодолеть их, направляясь к более зеленым пастбищам.
Общий прогресс
Как всегда, происходит много всего, включая некоторые глубокие погружения в основы. Как некоторые из вас знают, наша сетевая библиотека qp2p основана на Quinn, реализации Rust отраслевого стандарта QUIC, разработанной Google.
Преимущество использования широко используемых компонентов в том, что на них обращают внимание и они постоянно обновляются, но недостатком является то, что они не всегда работают так, как мы хотим. В этом случае библиотека TLS полагается на DNS, для чего требуется центр сертификации (CA), оба из которых в своей стандартной форме не подходят для p2p-сети. Но… У Дэвида есть хитрый план использовать консенсус нашей группы, чтобы стать нашим собственным ЦС, который должен позволить нам защищать трафик и подписывать с помощью наших ключей ed25519, по крайней мере, при обновленной версии rustls, что должно быть скоро. В конечном счете, мы хотим свести к минимуму использование qp2p, и это будет шагом к этому.
@bzee также изучает qp2p и добавляет урезанную версию в репозиторий stableset_net для повышения эффективности обмена сообщениями. @davidrusu также работает над стабильным набором, в том числе получает инструмент Stateright, чтобы разгрузить свою рабочую очередь на диск, чтобы мы могли протестировать более сложные модели.
Что касается DBC, @oetyng добился значительных успехов в обновлении ящика sn_dbc, а также в уточнении языка, который мы используем для описания ослепления (скрытия суммы транзакций) и разблокировать, чтобы упростить отслеживание. Сейчас он работает над обновлением потока команд между клиентами и старейшинами при работе с DBC.
@bochaco работает над раскрытием gRPC для safe_node и добавляет шаг в наш инструмент тестовой сети для проверки запускаемых кодов с помощью такого сервиса.
Роланд усердно работал над телеметрией, улучшая нашу видимость на уровне узлов и функций. Трассировки позволяют нам увидеть, что происходит с каждой функцией, но в необработанном виде их трудно прочитать, поэтому Roland загружает их в OpenSearch, где их можно агрегировать по узлу и времени, чтобы дать нам очень детализированную картину того, что и где происходит. .
И, убрав юридические вопросы, @JimCollinson обращает свое внимание на брендинг. Какими должны быть наши основные сообщения и как мы должны их представлять? Есть чему поучиться у тех, кто все сделал правильно, поэтому, если есть компании или отдельные лица, которые вас особенно вдохновляют, дайте нам знать в этой теме.
Переход к устаревшей сети
Есть несколько вещей, которые мы хотели бы сделать более надежными для любой новой тестовой сети. Основная проблема, которую мы увидели в последней тестовой сети, заключалась в том, что наш код перемещения и, следовательно, возраст узла не работали должным образом.
Основная причина этого заключалась в том, что у нас просто не было достаточного оттока до открытия сети. Но это открыло вопрос о том, как надежно добиться этого и переехать в будущем.
Одним из простых изменений было уменьшение начального возраста узла, что ускоряет перемещение… но само по себе это также сопряжено с различными затратами и компромиссами, особенно до тех пор, пока мы не внедрим многоуровневое хранилище данных. Но мы также столкнулись с некоторыми другими проблемами.
Мы видели, что наш прежний «двухэтапный» подход к членству вызывал у нас проблемы (у нас есть «Членство», где происходит голосование, а также «SectionPeers», которые должны были обновляться для изменений членства и основаны на наших SectionAuthorityProvider (SAP), но эти два могут не синхронизироваться). Поэтому здорово, что PR @qi_ma был объединен, что должно уменьшить такие разногласия.
Мы также столкнулись с проблемой, когда решения о членском голосовании становились невероятно большими и вызывали слишком много трафика, что приводило к увеличению времени проверки. Это само по себе было рефакторингом до нормального уровня, а также непреднамеренно выявило некоторые блокировки, которые у нас были.
Эта блокировка процесса также была устранена, поэтому теперь все работает намного более гладко с членским голосованием и DKG.
Таким образом, мы снова смотрим на скорость перемещения и пытаемся убедиться, что мы не видим никаких петель, когда узлы перемещаются по сети. Как только это будет сделано, мы будем в гораздо лучшем месте для обработки оттока и хранения данных.
Это само по себе отличное место, но мы не останавливаемся на достигнутом. Работа над отдельным POC для стабильного набора begun, как заметили здесь некоторые люди! Это должен быть самый простой узел (и он мог бы быть намного проще, если бы мы могли избежать большого количества обслуживания знаний о сети и DKG, которые исходят от нашей основной ветки). Это еще рано, но мы стремимся получить простую реализацию и выбросить ее к черту, чтобы посмотреть, как все выглядит.
Оба пути весьма интересны, и мы надеемся, что в ближайшем будущем они приведут к еще одной, более «старой» тестовой сети!
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!