Обновление Safe Network 🇷🇺 2 декабрь 2021 г

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

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

В последнем обновлении мы упомянули, что DKG вызывает (не связанные) проблемы, когда узлы иногда не могут быть повышены до старших, а разделение иногда происходит не так, как должно. Часть вины лежит на сообщениях, поступающих не по порядку и не обрабатываемых должным образом во время выполнения DKG. @lionel.faber объясняет, как мы исправляем это с помощью антиэнтропии.

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

Большинство команд CLI теперь работают хорошо, но некоторые пока не согласованы. Нам также необходимо добавить интерфейс командной строки в новый автоматизированный процесс выпуска.

@Anselme углубился в NRS, в том числе реализовал поддержку пробного запуска для пакетной обработки операций. Он также помогал @danda и Дэвиду Русу в их работе над доказательством оплаты и частными транзакциями. Если вы следили за этими обновлениями, то знаете, что они исследуют наилучшие способы реализации DBC таким образом, чтобы транзакции могли быть быстрыми и неотслеживаемыми, а также поддавались аудиту и поддерживали несколько выходных данных DBC. Ребята выбрали несколько путей, и на данный момент наиболее многообещающим подходом кажется версия кольцевых конфиденциальных транзакций (RingCT), используемая Monero, которую можно использовать для подтверждения платежа. Дэвид Русу представил команде презентацию по этому поводу, которую мы воспроизведем здесь в ближайшее время.

Решение проблем с DKG с помощью Anti Entropy

Распределенная генерация ключей (DKG) — это способ управления процессом согласования между узлами. Для выполнения действия требуется ключ. Этот ключ разделен на ключевые доли, при этом каждый голосующий узел имеет одну уникальную долю. Только после того, как определенное количество акций (скажем, 5 из 7) будет получено и агрегировано, может быть сгенерирован ключ подписи.

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

Прогон DKG представляет собой пошаговый процесс с шестью отдельными фазами: инициализация, участие, жалоба, обоснование, обязательство и завершение. Ключи должны быть сгенерированы, обменены, агрегированы и согласованы. С сообщениями, проходящими туда-сюда на каждом этапе. Хотя общий порядок сообщений в целом не требуется для DKG, узел может обрабатывать только сообщения, относящиеся к его текущей фазе DKG.

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

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

Есть две различные ситуации, когда требуется AE для сообщений DKG.

Сообщения DKG приходят не в фазе

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

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

Чтобы показать, почему это более эффективно, рассмотрим следующее.

Предположим, что требуется порядок сообщений

1.1, 1.2, 1.3, 2.1, 2.2, 2.3...

где каждое сообщение

<фаза>.<сообщение_номер>

Например, Initialization.message1, Initialization.message2, Contribution.message1 и т. д.

Скажем, у нас есть два узла A и B. Узел A находится в фазе 2, а узел B — в фазе 1.

Есть два варианта:

Методом проб и ошибок

# Шаг 1
B (фаза 1) получает 2.1 -> Не готов -> сохранить 2.1

# Шаг 2
B (фаза 1) получает 1,2 -> применяется 1,2
B (этап 1) -> применяется 2.1 из хранилища -> Не готов

# Шаг 3
B (фаза 1) получает 1,3 -> применяет 1,3
B (фаза 2) -> применяет 2.1 из хранилища -> ОК -> удалить 2.1 из хранилища

Здесь чем дольше 1.2 и 1.3 приходят, тем больше проб и ошибок.

АЕ

# Шаг 1
B (этап 1) получает 2.1 -> Не готов -> Запрашивает у А все сообщения

B (фаза 1) получает 1.1, 1.2, 1.3, 2.1 -> Применяет их все -> ОК
Б(фаза 2)

Таким образом, AE намного эффективнее и уменьшит количество неожиданных потоков сообщений.

Сообщения DKG, поступающие для сеанса, который еще не начался

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

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


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

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

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