Обновление Safe Network 🇷🇺 18 ноября 2021 г

Это машинный перевод. Оригинал на английском здесь: Update 18 November 2021

Итак, на этой неделе мы передаем Габ
Как вы знаете, он не из тех, кто хвастается
Но он незаметно исправил ошибку при обмене сообщениями.
Сохраняя SectionChains в DAG
ОК, это не Ламбо и даже не Ягуар
Но для сетевых операций это действительно потрясающе
Посмотри, если это твоя сумка

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

@danda создал диаграммы UML для всех ящиков Safe Network, что позволяет легко увидеть, как все они сочетаются друг с другом. Для нетехнических специалистов возможность просматривать названия блоков кода и то, как они связаны, дает представление о работе сети. Подобно тому, как вы видите все зубцы в часах, вы можете не понимать всех деталей шага и количества зубцов, но может быть полезно увидеть зубцы за безелем, чтобы лучше понять его работу. Вы можете увидеть чистые, компактные и полные версии каждого ящика с увеличивающимся уровнем детализации, с зелеными блоками, представляющими черты, синими структурами и желтыми перечислениями. Сайт лучше всего просматривать в Chrome.

“Голое” SVG-представление ящика sn_dbc

Тем временем @qi_ma и @lionel.faber обращают внимание на реализацию паттерна Anti-Entropy в процессе генерации распределенных ключей.

ОК, Габриэль (@bochaco).

Обработка сетевых знаний

Сетевые знания описывают процессы, с помощью которых старейшины отслеживают топологию сети. Поскольку Safe является асинхронным и всегда меняется, это делается по принципу служебной необходимости, при этом, когда узел связывается с другим узлом, они сначала синхронизируются, обмениваясь сообщениями Anti-Entropy (AE).

Чтобы уменьшить количество сообщений, теперь у нас есть DAG для отслеживания всех SectionChains и PrefixMap для хранения текущих разделов SAP. Ниже объясняется, как это влияет на проверку AE и SAP, когда исходное сообщение отклоняется.

SectionChain

SectionChain - один из наиболее важных инструментов, доступных узлу, поскольку он позволяет ему проверять, является ли часть данных или сообщение действительными (имеет сетевые полномочия).

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

Каждый блок в цепочке содержит ключ раздела, который старейшины - в тот конкретный момент - использовали для подписания всех процедур соглашения. Каждый раз, когда Старейшины меняются (отток), создается новый ключ раздела, и новый блок добавляется в SectionChain.

Как он используется для проверки сообщений и данных? Что ж, любой фрагмент контента или информации, подписанный ключом раздела, можно проверить, посмотрев на SectionChain. Если ключ найден там, это означает, что часть контента / информации была подписана разделом в прошлом и, следовательно, имеет сетевые права доступа.

Anti-Entropy Retry и Redirect

Сеть использует набор сообщений Anti-Entropy (AE) для узлов, чтобы синхронизировать себя о топологии сети и секции, к которой они принадлежат. Каждое сообщение, отправленное на узел или в другой раздел, должно включать ключ текущего раздела адресата, чтобы сообщение было принято получателем. Если это не так, получатель отклонит сообщение, вернув его отправителю в сообщении «AE-Retry». Сообщение AE-Retry содержит актуальную информацию о своем разделе, то есть о текущем поставщике полномочий раздела (SAP), который перечисляет текущих старейшин раздела и ключ текущего раздела (см. Главу AE в учебнике).

Аналогичный поток событий запускается, когда сообщение отправляется в неправильный раздел, что может быть вызвано отсутствием у отправителя последней информации о топологии сети. Получатель также отклонит сообщение, отправив его обратно отправителю в сообщении AE-Redirect. В этом случае сообщение «AE-Redirect» содержит SAP раздела, в который сообщение должно быть повторно отправлено.

Когда отправитель получает новый SAP через сообщение «AE-Retry» или «AE-Redirect», ему сначала необходимо убедиться, что это действительный и надежный SAP, то есть убедиться, что SAP соответствует сети, которой доверяет отправитель.

Для этого узел должен проверить, что ключ раздела, найденный в полученном SAP, криптографически проверяется с помощью SectionChain на всем пути до ключа генезиса, в противном случае злонамеренный узел может перенаправить его на другой (небезопасный) сети или злонамеренным партнерам или разделам. Вот почему каждое сообщение Anti-Entropy также содержит ProofChain, чтобы исходный отправитель мог проверить и доверять новому SAP.

ProofChain - это несколько самых последних блоков SectionChain - нам не нужно отправлять полную SectionChain, если мы недавно контактировали с другим разделом, только дельту.

Что изменилось?

До сих пор каждый узел сохранял копию своего собственного SectionChain и SAP. Это использовалось для проверки любого входящего сообщения или нового SAP, полученного в сообщениях AE, а также для создания ProofChain при отправке.передача сообщений AE другим узлам.

Это было хорошо для известных нам разделов, но для далеких, неизвестных разделов требовалось немало дополнительной работы.

Допустим, мы отправили сообщение, и оно возвращается, говоря, что нам нужно перенаправить его в раздел, с которым мы не связались раньше, включая SAP этого неизвестного раздела. Мы знаем раздел по его адресному префиксу XOR, но мы ничего не знаем ни о нем, ни о нас. Мы не видели его SAP раньше, и у нас нет ProofChain. Поэтому, прежде чем мы сможем повторно отправить сообщение в новый раздел, нам нужно отправить дополнительные сообщения для обмена SectionChains, что является сложным и подверженным ошибкам.

Вот почему мы недавно работали над тем, чтобы все узлы отслеживали цепочки разделов все других разделов. Это позволяет каждому узлу предоставлять ProofChain одноранговым узлам не только при обновлении их с помощью SAP их собственного раздела, но и когда сообщение «AE-Redirect» говорит им сделать это для удаленного раздела.

Это устраняет некоторый трафик и сложность AE, а также позволяет узлам гарантировать, что они взаимодействуют только с одноранговыми узлами, которым они доверяют принадлежать к той же сети, путем криптографической проверки любого ключа раздела, который они получают, вплоть до ключа генерации.

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

Теперь мы реализовали DAG (направленный ациклический граф) для отслеживания всех цепочек разделов и PrefixMap (регистр, отображающий префикс раздела в его SAP) в хранить текущие SAP-файлы всех разделов.

DAG

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

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

Этот процесс повторяется в каждой из двух новых ветвей независимо друг от друга. Они разбиваются на несколько разделов, создавая больше ветвей в соответствующих цепочках разделов. Это естественным образом формирует DAG, каждая из вершин которого содержит ключ раздела и подпись, сделанную с помощью ключа раздела предыдущей вершины.

Учитывая любой ключ раздела, его ProofChain может быть построен из DAG путем сбора всех вершин (ключей раздела и подписей), которые находятся на пути от ключа создания к этому ключу раздела. Обратите внимание, что, поскольку разделы никогда не объединяются, а только разделяются, всегда существует уникальный путь от ключа создания к любому другому ключу раздела в DAG, другими словами, существует уникальная цепочка доказательств от ключа происхождения для любого заданного ключа раздела.

Эта разработка подробно описана в этом PR.


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

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

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