Обновление Safe Network 🇷🇺 21 июля 2022 г

Это машинный перевод. Оригинал на английском здесь: Update 21 July, 2022

Что-то вроде приквела на этой неделе, когда мы посмотрим, как SectionChains и SAP вписываются в изменения PrefixMap, объявленные на прошлой неделе.

Общий прогресс

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

@davidrusu искал способы мониторинга сети и администрирования Node Age, в том числе то, как взрослые могут доказать старейшинам, что они живы и здоровы, даже если сетевой активности не так много.

@bzee продолжает изучать OpenTelemetry инструмент мониторинга с открытым исходным кодом, в котором уже реализованы некоторые рефакторинги для включения ведения журнала по протоколу OTLP. Мы надеемся, что это должно заставить нас войти в эластичный сервер, где мы можем более легко получить обзор состояния тестовых сетей.

А @joshuef продолжает возиться с оптимизацией памяти. Мы удалили некоторые чрезмерно усердные повторные попытки, которые потенциально поддерживали соединения, и ожидающие сообщения в памяти, в то время как отправка повторялась, повторялась и повторялась (как на уровне qp2p, так и на узле). Он также делал другие мелкие настройки, которые помогли значительно снизить нагрузку на память.

У @yogesh есть PR, позволяющий возвращать клиенту информацию о трассировке. В нем будут перечислены все узлы, участвующие в потоке обмена сообщениями для данного запроса/команды, что должно помочь при отладке.

SectionChains и SAP

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

Ключ «Genesis» можно рассматривать как «доказательство сети». Это самый первый ключ, созданный самым первым узлом в самом первом разделе — разделе с префиксом «0». Как только к этому первому одинокому узлу присоединяется другой узел (пытаясь не называть его Евой, поскольку это быстро приведет к путанице), создается новый ключ раздела B, который подписывается ключом генезиса. Когда присоединяется новый узел C, снова создается новый ключ раздела, на этот раз подписанный B, и так далее.

Дни подписи ключа Genesis закончились, как только он подписал ключ B. Тем не менее, он остается чрезвычайно полезным в качестве доказательства того, что текущий ключ раздела и все предшествующие ему действительны, а не подкрадены злоумышленником, потому что криптографически очень легко доказать, что текущий ключ любого раздела в конечном итоге связан с Genesis, как бы долго он ни находился. SectionChain становится.

Подписание

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

Если использовать классический пример, Алиса отправляет сообщение Бобу и подписывает его своим секретным ключом, то есть она создает уникальную «подпись» из комбинации содержимого сообщения и своего секретного ключа. Боб может быть уверен, что она была подписана Алисой, потому что он может проверить подпись с помощью ее открытого ключа. У подслушивающей Евы также есть открытый ключ Алисы, но она бессильна обмануть Боба, изменив сообщение Алисы, поскольку оно больше не будет содержать действительной подписи.

В данном разделе мы имеем дело не с отдельными людьми, такими как Алиса и Боб, а с групповыми решениями, которые должны быть одобрены квалифицированным большинством старейшин. Чтобы быть отказоустойчивым по-византийски (это означает, что треть узлов может работать без сбоев), пять из семи старейшин должны подписать сообщение. Вместо того, чтобы каждый старший выполнял процесс, как Алиса и Боб выше, гораздо более эффективным способом сделать это является генерация распределенного ключа (DKG), где каждый старший вносит свой ключ. Как только у нас будет пять таких общих ключей — любые пять — мы создадим действительный ключ подписи, и решение будет подтверждено. Это эквивалент секретного ключа раздела, подписывающего сообщение, хотя в BLS секретный ключ не существует.

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

Важно то, что каждый текущий ключ раздела в каждом разделе имеет путь вниз по ветвям к ключу генезиса. То есть мы можем доказать, что находимся в правильной сети и что процесс приветствия новых узлов действителен на каждом этапе, по крайней мере, до уровня D.КГ обеспокоен. Но как только появляется более одного раздела, каждый раздел имеет свой путь обратно к «Бытию», после чего цепочка разделов становится DAG (ориентированным ациклическим графом), а не линейной цепочкой.

Поставщик полномочий раздела (SAP)

Цепочка разделов — простой, но жизненно важный инструмент. Каждый узел и клиент содержит SectionChain. Как клиент или узел, он сообщает нам, что текущий раздел, с которым мы говорим, криптографически действителен, и что мы находимся в правильной сети (что подтверждается ключом «Genesis»), а не в каком-то ответвлении, но это все. .

Когда узел или клиент присоединяется к сети, ему присваивается SectionChain и SAP. SAP сообщает нам о нынешних старейшинах. Это список текущих старших (каждый старейшина имеет уникальный ID, IP и порт), подписанный одним из ключей в SectionChain. Это означает, что когда мы подключаемся к узлу в этом списке, мы можем быть уверены, что он действителен, потому что, опять же, подпись можно проследить вплоть до Genesis. SAP также содержит текущий SectionKey.

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

На следующей неделе подробнее о том, как все это сочетается друг с другом.


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

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

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