Это машинный перевод. Оригинал на английском здесь: Update 13 October, 2022
Мы уже некоторое время говорили о реорганизованном процессе избрания новых старейшин секций и управления расколами. На этой неделе @anselme копается в размышлениях о подходе к этому с поясом и подтяжками.
Общий прогресс
@Chriso проводит рефакторинг процессов подписи фрагментов и регистров, а также тестирования хранилища и двойных расходов DBC.
@roland работает над тестами для sn_sdkg AE и функций членства, описанных ниже.
Мостафа изучает механизмы децентрализованного консенсуса и пересматривает нашу текущую настройку.
@davidrusu перерабатывает процесс присоединения, чтобы включить обновление знаний о сети перед присоединением.
А @anselme и @dirvine реорганизуют процесс полномочий, как описано на прошлой неделе.
@bzee, @bochaco и @joshuef работают над отладкой более низкого уровня стабильности. Мы видели сочетание медленной обработки сообщений и ошибок в управлении соединениями, которые иногда вызывали проблемы. Таким образом, мы совершаем глубокое погружение здесь. Мы добились определенного прогресса, упростив обработку сообщений, и продолжаем работать в этом направлении, так как кажется, что это будет многообещающий рефакторинг, как с точки зрения простоты кода, так и с точки зрения стабильности.
Все о sn_sdkg
DKG с sn_sdkg
- На основе генерации ключей poanetwork в hbbft.
- Удаляет таймеры
- Представляет сплетни
- Охватывает одновременный DKG
- Гонка между DKG до передачи
Мы только что интегрировали sn_sdkg (синхронная распределенная генерация ключей безопасной сети), заменив предыдущую версию, в которой мы видели сбои и тайм-ауты, когда сети были медленными. Основная причина, вероятно, в том, что мы используем таймеры. Этот новый процесс DKG не использует таймеры, на самом деле, нам вообще не нужны таймеры в Safe, где бы то ни было.
DKG не активен, это просто то, что узлы делают в фоновом режиме, когда получают системные сообщения, и они могут одновременно запускать несколько сеансов.
Помимо использования антиэнтропии (AE), sn_sdkg также вводит сплетни, чтобы убедиться, что узлы получают любые сообщения, которые они могут пропустить, чтобы в конечном итоге все были согласованы.
Давайте пройдемся по нему.
Старейшины отправляют DkgStart
- разделение секций
- передача участка
Первым шагом в этом процессе является отправка старейшинами сообщения «DkgStart». Это происходит, когда возникает одна из двух ситуаций. Во-первых, когда узел прибывает в раздел, который старше одного или нескольких текущих старших. В этом случае мы должны передать - новый узел продвигается, и знания о разделе передаются. Второй сценарий — когда раздел становится слишком большим и разделяется.
ржавчина
структура публикации DkgSessionId {
/// Префикс сессии, на которую мы являемся старшими кандидатами
паб префикс: Префикс,
/// Другие старейшины в этом сеансе dkg
старейшины паба: BTreeMap<XorName, SocketAddr>,
/// Длина основной ветви цепочки секций.
паб section_chain_len: u64,
/// Элементы начальной загрузки для следующего экземпляра Membership.
pub bootstrap_members: BTreeSet<NodeState>,
/// Генерация членства, в которой был создан этот SAP
pub member_gen: Генерация,
}
Когда происходит событие DkgStart, старейшины генерируют информацию в структуре, называемой DkgSessionId (в Rust этот формат называется ‘struct’). Они подписывают эту структуру своим общим ключом BLS и обмениваются им с другими старейшинами. Каждый DkgSessionId предоставляет базовую информацию о текущем состоянии дел и уникален для раунда DKG.
Префикс — это префикс текущего раздела. В случае передачи это не меняется. В случае разделения это так, и мы добавляем единицу или ноль к нашему текущему префиксу в зависимости от того, находимся ли мы на стороне 0 или 1 разделения.
Поле «старейшины» содержит всех новых кандидатов в старейшины для этого сеанса DKG, узлы с возрастом узла, равным или превышающим возраст текущего старейшины.
section_chain_length (будет переименован) — это расстояние от текущего ключа раздела до Genesis. Мы можем думать об этом как о «генерации раздела».
membership_gen также показывает создание членства. Это отличается от генерации раздела. Каждая секция имеет много поколений членства, и длина цепочки не меняется.
bootstrap_members — текущие старшие в разделе.
Как только узлы получают DkgSessionId от всех текущих старейшин, они могут начать сеанс DKG.
Пойдем!
Шаги Дкг
``русалка
блок-схема ЛР;
A[DkgStart] --> B[Эфемерный ключ]
Все текущие старейшины и кандидаты в старейшины получают адресованное им сообщение DkgStart, в котором они включены как старейшины в структуру DkgSessionId.
Затем каждый из этих узлов генерирует эфемерный одноразовый ключ BLS, который используется только для этого раунда DKG. Этот эфемерный ключ подписан их ключом ed25519, который служит их идентификатором, поэтому другие узлы могут проверить его действительность.
Шаги Дкг
``русалка
блок-схема ЛР;
A[DkgStart] --> B[Эфемерный ключ] --> C[Голосование]
Далее следует этап голосования, на котором каждый узел может генерировать свои собственные ключи для голосования. Мы используем процесс, заимствованный из Poanetwork в hbbft, что гарантирует, что каждый узел может генерировать только свой собственный ключ и не использовать информацию от других узлов для создания отдельного ключа для раунда DKG.
Голосуют узлы, по которым из кандидатов и существующих старейшин теперь должны быть старейшины секции.
Шаги Дкг
``русалка
блок-схема ЛР;
A[DkgStart] --> B[Эфемерный ключ] --> C[Голосование] --> D{Генерация ключа}
После завершения голосования кандидат генерирует новый ключ, который отправляет текущим старейшинам, чтобы доказать, что он имеет право стать старейшиной (поскольку подавляющее большинство узлов подписало его новым ключом). Так что DKG — это своего рода тест для хорошего кандидата. Если они не закончат DKG, они недостаточно хороши.
Параллелизм
``русалка
блок-схема ЛР;
A[DkgStart1] --> B[Эфемерный ключ] --> C[Голосование] --> D{Генерация ключа1}
русалка
блок-схема ЛР;
A[DkgStart2] --> B[Эфемерный ключ] --> C[Голосование] --> D{Генерация ключа2}
Несколько сеансов DKG могут происходить одновременно. Каждый раз, когда в секции появляется новый участник, мы можем (если новый узел старше, чем любой из текущих старших) иметь новый сеанс DKG, поэтому, если во время одного сеанса присоединяется новый узел, может начаться другой сеанс DKG. Некоторые прекратят работу, другие просто выйдут из строя и потерпят неудачу. Это гонка, и мы выбираем того, кто финиширует первым. Позже, если выяснится, что есть более старый узел, который не является старшим, процесс начинается снова.
Решено передачей
русалка
stateDiagram-v2
Dkg1 --> Передача
Передача --> Победитель:Dkg1
Dkg2 --> Передача
Dkg3 --> Передача
Если будет ничья, нам нужен только один победитель, то есть один новый старейшина. Передача — это процесс, в котором используется консенсус, чтобы решить, какой из них должен выиграть.
Активный автоэкспозитор
русалка
stateDiagram-v2
DkgStart --> ЭфемералКей
EphemeralKey --> EphemeralKey: включает DkgStart AE
EphemeralKey --> Голосование
Голосование --> Голосование: включает EphemeralKeys AE
Голосование --> Прекращение
На этих этапах, упомянутых выше, получение сообщения DkgStart, создание эфемерного ключа и голосование, нам нужно компенсировать проблемы с сетью и медленные узлы. Например, нам нужны все ключи, чтобы начать голосование, иначе мы застрянем. Поэтому мы включаем AE в каждое сообщение, связанное с ключом, чтобы предоставить информацию, которая может отсутствовать в узле. AE — это легкий и эффективный способ убедиться, что все узлы работают на должном уровне.
ржавчина
перечисление SystemMsg {
DkgStart(DkgSessionId),
DkgEphemeralPubKey {
/// Идентификатор сеанса DKG, для которого это сообщение.
session_id: DkgSessionId,
/// Полномочия раздела для стартового сообщения DKG
section_auth: AuthorityProof<SectionAuthProof>,
/// Эфемерный ключ bls, выбранный кандидатом
pub_key: BlsPublicKey,
/// Подпись кандидата ed25519
знак: подпись,
},
DkgVotes {
/// Идентификатор сеанса DKG, для которого это сообщение.
session_id: DkgSessionId,
/// Эфемерные открытые ключи bls, используемые для этого раунда Dkg
pub_keys: BTreeMap<XorName, (BlsPublicKey, Подпись)>,
/// Сообщение DKG.
голоса: Vec<DkgSignedVote>,
},
DkgAE(DkgSessionId),
}
В коде системное сообщение, которое является типом сообщения, используемым для процессов, которые могут изменить структуру сети, выглядит так, как показано выше. Это инкапсулирует все процессы, о которых мы говорили.
Устойчивость
- Активная АЭ
- Голосование АЕ
- Сплетни
- при ожидании голосов
- при получении просроченных голосов
Подводя итог, у нас есть несколько механизмов устойчивости при обработке хендоверов и разделений.
Активный AE означает, что узлам отправляется информация с предыдущего шага на случай, если они ее пропустили.
У нас также есть сплетни в качестве резерва. Если вы находитесь в сеансе DKG, вы готовы получать эфемерные ключи или голоса от кого-либо. Если они не появляются, вы отправляете свои текущие знания другим в надежде, что они обновят вас. Кроме того, если вы получили от кого-то устаревшие AE, вы можете обновить их.
Итак, сплетни преследуют две цели. Чтобы убедиться, что мы в курсе, чтобы мы могли двигаться вперед, и обновить других, чтобы мы могли завершить.
Вместе с AE и возможностью конкуренции между процессами DKG это обеспечивает гораздо более надежный процесс продвижения новых старейшин и обработки расколов. Во время сплитов у нас происходит два DKG, а не один.
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!