Предложение Finalization protocol (host-initiated, collectors, commit certificate)

Резюме

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

Он предназначен для:

сохранить безопасность при византийском поведении,

разрешить ход финализации, когда пользователь не в сети или мошенничает,

уменьшить поток сообщений с помощью детерминированного набора сборщиков,

• заставить основную сеть принимать финализацию только тогда, когда фаза фиксации доказуемо завершена.

Похожие предложения:

• Протокол синхронизации высоты (https://github.com/gonka-ai/gonka/discussions/1340) — один из дополнительных способов получения маяка случайности коллектора (см. Маяк случайности коллектора).

• Детерминированная случайность в стиле Педерсена (еще один источник сигналов). ЗАДАЧА: описать

Важно учитывать

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

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

• Nonce ↔ расписание исполнителя (гипотеза). Со строгой привязкой между nonce и хостом-исполнителем (например. N хостов в фиксированном порядке): если хост A выполнил nonce NoID , то хост A снова запланирован на nonce NoID + N и так далее. После полного цикла N последовательных одноразовых номеров каждый хост выполнил один шаг. Открытое предположение: это означает, что каждый другой хост знает об одной и той же линейной истории (или может получить ее) без дополнительного обмена сообщениями. Прежде чем строить на этом аргументы в пользу безопасности, это должно быть подтверждено точными правилами планирования, транспортировки и хранения.

Nonce ↔ расписание исполнителя (гипотеза). Со строгой привязкой между nonce и хостом-исполнителем (например. N хостов в фиксированном порядке): если хост A выполнил nonce NoID , то хост A снова запланирован на nonce NoID + N и так далее. После полного цикла N последовательных одноразовых номеров каждый хост выполнил один шаг. Открытое предположение: это означает, что каждый другой хост знает об одной и той же линейной истории (или может получить ее) без дополнительного обмена сообщениями. Прежде чем строить на этом аргументы в пользу безопасности, это должно быть подтверждено точными правилами планирования, транспортировки и хранения.

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

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

• Случайность коллектора не связана с разделением состояний. Перед этапами 2–4 участники должны договориться о маяке случайности сборщиков — общедоступных материалах, смешанных с начальным числом отбора коллекционеров, чтобы ни один инициатор не мог выбрать подходящие агрегаторы. Синхронизация по высоте не является обязательным условием финализации. Когда используется протокол синхронизации высоты (https://github.com/gonka-ai/gonka/discussions/1340), его роль здесь заключается только в создании этого маяка (обычно выровненная высота основной сети после проверенных LightBlock s). Другие схемы детерминированной случайности в равной степени действительны, если они соответствуют требованиям маяка случайности коллектора (например, открытые значения из обязательств Педерсена, собранные во время сеанса).

Случайность коллектора не связана с разделением состояний. Перед этапами 2–4 участники должны договориться о маяке случайности сборщиков — общедоступных материалах, смешанных с начальным числом отбора коллекционеров, чтобы ни один инициатор не мог выбрать подходящие агрегаторы. Синхронизация по высоте не является обязательным условием финализации. Когда используется протокол синхронизации высоты (https://github.com/gonka-ai/gonka/discussions/1340), его роль здесь заключается только в создании этого маяка (обычно выровненная высота основной сети после проверенных LightBlock s). Другие схемы детерминированной случайности в равной степени действительны, если они соответствуют требованиям маяка случайности коллектора (например, открытые значения из обязательств Педерсена, собранные во время сеанса).

• Порядок этапов доработки. Сквозная финализация заключается в следующем: Совместное использование состояния — запуск выделенного протокола до тех пор, пока все необходимые стороны не разделят общее представление о состоянии терминала (или не прекратят работу). Соглашение о случайности — получите и проверьте маяк случайности коллектора для этой попытки завершения (зависит от источника; может совпадать с синхронизацией высоты, раскрытием Педерсена или другой определенной церемонией). Маяк передается в FinalizeInit как randomness_source +collector_randomness_beacon. Обязательство по предложению — трансляция/блокировка FinalizeInit с помощью Finalization_hash, полей маяка и свидетельства триггера. Голосование — FinalizeVote и агрегация в VoteQC (QC = Сертификат кворума: доказательство того, что достаточно хостов проголосовали за один и тот же Finalization_hash). Голосование за обязательство — FinalizeCommit и агрегирование в CommitQC (этап фиксации согласованного предложения), затем FinalizeSubmit в основную сеть.

Порядок этапов доработки. Сквозная доработка – это:

• Совместное использование состояния — запускайте выделенный протокол до тех пор, пока все необходимые стороны не разделят общее представление о состоянии терминала (или не прекратят работу).

• Соглашение о случайности — получите и проверьте маяк случайности коллектора для этой попытки завершения (зависит от источника; может совпадать с синхронизацией высоты, раскрытием Педерсена или другой определенной церемонией). Маяк передается в FinalizeInit как randomness_source +collector_randomness_beacon.

• Обязательство по предложению — трансляция/блокировка FinalizeInit с помощью Finalization_hash, полей маяка и свидетельства триггера.

• Голосование — FinalizeVote и агрегация в VoteQC (QC = Сертификат кворума: доказательство того, что достаточно хостов проголосовали за один и тот же Finalization_hash).

• Голосование за обязательство — FinalizeCommit и агрегирование в CommitQC (этап фиксации согласованного предложения), затем FinalizeSubmit в основную сеть.

Фазы 1–2 могут проходить как одна объединенная церемония или как отдельные этапы; Схемы сообщений ниже соответствуют этапам 3–5. Фаза 1 здесь выходит за рамки в ожидании спецификации совместного использования состояния.

Цели

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

• Причина срабатывания должна быть подкреплена криптографическими доказательствами, которые могут проверить все хосты.

• Результат финализации должен быть уникальным/безопасным (сертификат фиксации, а не только голосование).

• Основная сеть должна проверить завершение фиксации перед применением урегулирования.

• Сетевые коммуникации должны быть ограничены; по возможности избегайте тотального наводнения.

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

Причины и необходимые доказательства

FinalizationTriggerReason:

ПОЛЬЗОВАТЕЛЬ_CHEATING

EPOCH_CHANGE_IMMINENT

USER_TIMEOUT

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

1) ПОЛЬЗОВАТЕЛЬ_CHEATING

Требуемые доказательства:

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

конфликтующие подписанные фрагменты одновременно (форк/двусмысленность),

неверный переход последовательности с подписью пользователя,

• неправильно сформированный подписанный пользовательский запрос, который не может быть исправлен с помощью более поздних различий.

Каждый предмет доказательств должен включать в себя:

необработанные подписанные байты полезной нагрузки,

подпись пользователя,

nonce/высота/контекст темы,

• хеш предыдущего фрагмента (если есть).

2) EPOCH_CHANGE_IMMINENT

Требуемые доказательства:

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

• epoch_current, epoch_next, height_proven.

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

3) ПОЛЬЗОВАТЕЛЬ_ТАЙМ-АУТ

Требуемые доказательства:

• последний пользователь HeightSyncSection (раздел 1 конверта пользователь-хост), наблюдаемый при обмене данными, с действительным CometBFT LightBlock и подписью отправителя,

• наибольшая наблюдаемая высота ответа/запроса для каждого хоста для одного и того же сеанса (из проверенного раздела 1 в обоих направлениях),

• окно тайм-аута в блоках.

Тайм-аут рассчитывается по:

• max(user_height_seen, host_response_height_seen) и текущий совет основной сети.

Формат конверта, доказательства и подписи определены в: Протокол синхронизации высоты (https://github.com/gonka-ai/gonka/discussions/1340) (структурированное тело HTTP: раздел высоты + раздел сообщения).

Примечание. Синхронизация по высоте здесь доказывает отсутствие активности пользователя для триггера. Само по себе это не оправдывает обработку выровненной высоты основной сети как глобальных часов финализации, если только это же значение не будет также принято как Collector_randomness_beacon в случайном_источнике = HEIGHT_SYNC_ALIGNED_HEIGHT.

Депонирование, привязанное к эпохе: валидаторы L1 от участников эпохи

Если срок службы подсети ограничен одной эпохой основной сети и подсеть завершается при переключении эпохи (в соответствии с политикой перехода EPOCH_CHANGE_IMMINENT/эпохи), запуск условного депонирования не обязательно должен включать набор валидаторов L1. Валидаторы CometBFT, которые могут подписывать блоки в течение этой эпохи, определяются участниками эпохи основной сети (каноническое состояние в цепочке; точный модуль/запрос подлежит уточнению). Каждый хост загружает этот список участников один раз за эпоху, преобразует записи в адреса консенсусных валидаторов Cosmos/CometBFT (тот же вывод, что и в блоках), кэширует их и использует результат для вычисления ожидаемого validators_hash на высоте H при проверке LightBlock (например, в доказательствах USER_TIMEOUT или когда randomness_source = HEIGHT_SYNC_ALIGNED_HEIGHT) на шаге 3b в протоколе синхронизации высоты. (https://github.com/gonka-ai/gonka/discussions/1340), поэтому одноранговые LightBlock не могут использовать изготовленный набор валидаторов.

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

Обязательство состояния и хеш завершения

Чтобы избежать двусмысленности и обеспечить детерминированный выбор коллектора, определите:

NonceLeaf_i = H(nonce_i || state_hash_i || tx_digest_i)

NonceMerkleRoot = MerkleRoot(NonceLeaf_1..NonceLeaf_N) (упорядочено по nonce)

Затем дайджест кандидата на доработку:

FinalizationHash = H(escrow_id || round || триггер_причина || триггер_evidence_hash || nonce_merkle_root || терминал_nonce || Settlement_payload_hash)

Trigger_evidence_hash — это корень Merkle для всех элементов триггерных доказательств.

Маяк случайности коллектора не является частью этого дайджеста. Он переносится в FinalizeInit (и отображается в FinalizeSubmit) и смешивается только с начальным числом выбора сборщика (см. Детерминированные сборщики). Отсутствие случайности в FinalizationHash позволяет одному и тому же предложению состояния терминала использовать разные источники или раунды маяков, при этом привязывая голоса/фиксации к одной полезной нагрузке расчета.

Обоснование:

• Корень Меркла меньше по размеру, и его легче проверить постепенно, чем объединение всех хешей nonce.

• доказательства для отдельных одноразовых номеров/доказательств компактны.

Незавершенная работа на стадии доработки

Когда начинается финализация (состояние завершения раунда фиксировано), протокол применяет детерминированные значения по умолчанию, поэтому расчет всегда закрывается:

• Незавершенные выводы — любой вывод, не находящийся в состоянии окончательного успеха (Ожидание, Начато, текущее выполнение и т. д.), рассматривается как успешно завершенный для расчета: зачисляется исполнителю по зарезервированной или согласованной стоимости, включенной в nonce_merkle_root и Settlement_payload, так же, как и обычный завершенный результат.

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

Эти правила применяются во время совместного использования состояния при построении представления терминала, которое передает FinalizationHash. Все хосты должны применять одни и те же значения по умолчанию, чтобы поля nonce_merkle_root и payout совпадали. Споры о правильности расчетов (если таковые имеются) выходят за рамки настоящего протокола голосования/фиксации.

Коллекторный маяк случайности

Детерминистическим сборщикам нужен общий источник псевдослучайности, который:

• Каждый честный хост получает одно и то же значение перед отправкой FinalizeVote (с учетом принятого FinalizeInit ).

• Инициатор не может в одностороннем порядке выбрать исходный материал, благоприятный для сборщика, после того, как станет известно конечное состояние (в противном случае он может измельчить комбинации FinalizationHash + beacon).

• Основная сеть может проверить правильность создания маяка для объявленного источника randomness_source.

• Независим от FinalizationHash, поэтому содержимое расчетов и начальное значение перемешивания являются отдельными обязательствами (см. выше).

Синхронизация высоты удовлетворяет условиям (1)–(3) при использовании только в качестве источника случайности: стороны запускают правила конвергенции синхронизации высоты из протокола синхронизации высоты (https://github.com/gonka-ai/gonka/discussions/1340) и принимают полученную выровненную высоту основной сети в качестве материала маяка. Эта высота не требуется для финализации, поскольку хосты должны «согласовать подсказку L1» в целом — она требуется только в той мере, в какой выбранная схема случайности использует ее.

Поддерживаемые источники (расширяемое перечисление)

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

Почему бы не использовать только FinalizationHash?

FinalizationHash фиксируется по предложению инициатора. Без внешней случайности начальное значение = H(FinalizationHash || «коллекторы») полностью предсказуемо для инициатора, который может пробовать альтернативные представления доказательств/состояний до тех пор, пока сборщики не отдадут предпочтение своему слоту. Маяк разрушает эту шлифовку.

Детерминированные коллекторы

Коллекторы выбираются из активных слотов с помощью FinalizationHash, randomness_source и Collector_randomness_beacon из FinalizeInit (одна и та же тройка, которую каждый хост и основная сеть должны использовать в раунде).

Параметры:

Collector_count = c (например, c=3 или c=5, параметр цепочки)

• randness_source: перечисление, выбирающее правила проверки (см. Маяк случайности сборщика).

• Collector_randomness_beacon: непрозрачные байты, кодировка которых зависит от randomness_source.

семя выбора: семя = H(FinalizationHash || случайный_источник || коллектор_рандомность_маяк || "коллекторы")

семя = H(FinalizationHash || источник_рандомизма || коллектор_рандомность_маяк || "коллекторы")

Хэш H — это та же функция, которая используется в других местах этого предложения (например, Хеш финализации). Детерминированное «случайное» перемешивание: начальное число фиксирует псевдослучайную перестановку слотов; все верификаторы получают один и тот же набор сборщиков без дополнительных сообщений.

Эталонное кодирование для синхронизации по высоте: когда randomness_source = HEIGHT_SYNC_ALIGNED_HEIGHT, Collector_randomness_beacon ДОЛЖЕН быть 8-байтовым выравниванием_mainnet_height с прямым порядком байтов из протокола синхронизации по высоте (https://github.com/gonka-ai/gonka/discussions/1340).

Алгоритм:

• Проверьте Collector_randomness_beacon для случайного_источника.

• Создайте детерминированный список активных слотов (отсортированные идентификаторы слотов).

• Используйте детерминированное перетасовывание, управляемое начальным числом.

• Возьмите сначала уникальные слоты в качестве коллекционеров.

Обязанности коллекторов:

агрегировать голоса и строить VoteQC,

собирать аттестации коммитов и строить CommitQC,

• после существования CommitQC отправьте один подписанный FinalizeSubmit в основную сеть (без более раннего трафика основной сети для голосования/фиксации).

Резервный вариант:

• если тайм-аут сборщика истекает, любой хост может принять отправку с теми же сертификатами.

Точный протокол (инициатор, заказ, транспорт)

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

Инициатор

• Кто: Любой хост в наборе активных участников может инициировать попытку финализации условного депонирования при условии, что он прикрепит действительные доказательства триггера для одного из FinalizationTriggerReason (см. Причины триггера и необходимые доказательства).

• Что они отправляют первым: подписанный FinalizeInit — это первое сообщение раунда. В этом проекте нет отдельного «избранного лидера»: первый действительный FinalizeInit, который принимают хосты для (escrow_id, round) в соответствии с правилами дедупликации/блокировки/разблокировки, открывает этот раунд. (Политика может позже добавить ротацию предлагающих; эта спецификация делает инициацию неразрешенной для честных хостов.)

• Раунд 1: FinalizeInit с round = 1 и отсутствием unlock_timeout_certificate (первая попытка завершения процесса условного депонирования).

• Раунд > 1: FinalizeInit должен включать действительный unlock_timeout_certificate, подтверждающий, что предыдущая попытка раунда (или раунд, указанный в сертификате) исчерпана без расчета — см. unlock_timeout_certificate в разделе FinalizeInit. Организаторы отклоняют более высокий раунд без соответствующего доказательства, если они все еще заблокированы из предыдущего раунда (см. Блокировка голосования и несколько раундов).

Порядок сообщений (один раунд, счастливый путь)

Для фиксированного (escrow_id, round):

• FinalizeInit — одно логическое предложение за раунд (может дублироваться слухами; дедупликация верификаторов осуществляется с помощью message_hash ).

• FinalizeVote — каждый участвующий хост отправляет не более одного голоса за (escrow_id, раунд) после проверки FinalizeInit (включая проверку маяка).

• VoteQC — производится только сборщиками после 2f+1 сопоставления AGREE с тем же Finalization_hash ; коллекторы передают компактный QC всем хостам (такой же транспорт, как и другие разветвления коллекторов).

• FinalizeCommit — каждый хост, который принимает VoteQC, отправляет не более одного коммита на каждый (escrow_id, раунд), ссылаясь на этот VoteQC (например, voice_qc_hash), только сборщикам (никаких слухов о фиксации между хостами; см. Транспорт).

• CommitQC — сборщики агрегированных коммитов, транслирующие компактный CommitQC.

• FinalizeSubmit — одна подписанная транзакция в mainnet, отправленная сборщиком (или резервным отправителем после таймаута сборщика), содержащая поля VoteQC, CommitQC и расчет.

Несчастливый путь: если шаг 3 никогда не дает результата VoteQC (недостаточно AGREE , все REJECT или тайм-аут) или шаг 5 никогда не дает CommitQC , в этом раунде не происходит отправки в основную сеть. Хосты ждут unlock_timeout_certificate (или участия локального таймаута в его формировании), затем новый FinalizeInit с round := round + 1 может начать следующую попытку.

Транспорт

Минимизация трафика коммитов: достаточно, чтобы FinalizeCommit отправлялся только сборщикам; это ограничивает разветвление фиксации до O(hosts ×collector_count) вместо лавинной рассылки между хостами. Никакого отдельного пути фиксации «все ко всем» не требуется.

Полезные данные доказательств: большие триггер_evidence_items ДОЛЖНЫ использовать хэш + выборку после первого объявления; FinalizeInit содержит корни и дополнительные ссылки, соответствующие минимизации связи.

Протокольные сообщения

Эти сообщения реализуют этапы 3–5 раздела «Важно учитывать» (после соглашения о совместном использовании состояний и случайности). Они не определяют разделение штатов или церемонии вручения маяков.

Все сообщения должны содержать:

escrow_id

круглый (монотонный uint64)

отправитель_слот

sender_sig

тип_сообщения

message_hash

Финализеинит

Поля:

escrow_id

круглый

• randomness_source (enum): объявляет, как проверить коллектор_randomness_beacon (см. «Маяк случайности коллектора»).

• Collector_randomness_beacon (байты): материал, специфичный для источника, смешанный с начальным числом коллектора. Хосты отклоняют FinalizeInit, если проверка объявленного источника не удалась или если значение маяка отличается от локально проверенного значения для этой попытки депонирования (если политика не допускает определенного допуска). Коллекторы для раунда получаются из FinalizationHash, этого поля и randomness_source (Детерминированные коллекторы).

• randomness_evidence (необязательно): доказательства, специфичные для источника (например, LightBlock с синхронизацией по высоте, вступительные расшифровки Педерсена), если их нельзя вывести из состояния кэшированного сеанса.

триггер_причина

триггер_evidence_root

триггер_evidence_items (или получить ссылки)

nonce_merkle_root

терминал_нонсе

Settlement_payload_hash

Finalization_hash

• unlock_timeout_certificate: Пропустить round = 1. В раунде > 1 требуется (см. Точный протокол — Инициатор): подписанное кворумом (или определенное политикой) доказательство того, что предыдущий раунд завершился без успешного расчета, чтобы можно было начать этот раунд. Должно охватывать как минимум: (a) раунд r не получил CommitQC и/или (b) раунд r не получил действительный VoteQC к крайнему сроку (этап голосования не пройден). Точная кодировка подлежит уточнению; функционально сертификат «раунда исчерпан».

Продвижение раундов: чтобы открыть round = r_new > 1, инициатор включает unlock_timeout_certificate для предыдущей попытки (обычно r_new - 1), если политика цепочки не определяет другое сопоставление. Хосты проверяют сертификат перед принятием нового FinalizeInit, если они удерживают блокировку из предыдущего раунда.

Псевдоним синхронизации высоты: когда randomness_source = HEIGHT_SYNC_ALIGNED_HEIGHT, Collector_randomness_beacon равен uint64_be(aligned_mainnet_height) из протокола синхронизации высоты (https://github.com/gonka-ai/gonka/discussions/1340). В более старых черновиках это поле в сообщении называлось Align_mainnet_height; байты маяка представляют собой каноническую кодировку.

Завершить голосование

Поля:

escrow_id

круглый

Finalization_hash

голосовать ( СОГЛАСЕН / ОТКЛОНЕН )

код_отклонения (необязательно)

ignore_evidence_hash (необязательно)

ГолосоватьQC

Произведено коллекционерами после 2f+1 совпадения голосов AGREE. Распространен на все хосты после агрегации. Включено в FinalizeSubmit в основную сеть.

Поля:

escrow_id

круглый

Finalization_hash

voice_signers_bitmap

агрегированный_vote_signature (или список явных подписей)

voice_count

Завершить фиксацию

Отправляется хостами сборщикам только после проверки VoteQC (не передается между хостами; см. Точный протокол — Транспорт).

Поля:

escrow_id

круглый

Finalization_hash

voice_qc_hash

зафиксировать (СОВЕРШИТЬ)

CommitQC

Создается сборщиками после достижения порога фиксации.

Поля:

escrow_id

круглый

Finalization_hash

voice_qc_hash

commit_signers_bitmap

агрегированный_commit_signature (или список явных подписей)

commit_count

FinalizeSubmit (в основную сеть)

Поля:

escrow_id

круглый

случайный_источник

• Collector_randomness_beacon: должен соответствовать принятому FinalizeInit для этого (escrow_id, round), чтобы хранитель (и аудиторы) могли повторно получить набор сборщиков с помощью FinalizationHash.

• randomness_evidence (необязательно): та же роль, что и FinalizeInit, если основная сеть не может полагаться на кеш предыдущего сеанса.

триггер_причина

триггер_evidence_root

nonce_merkle_root

терминал_нонсе

Settlement_payload

Finalization_hash

voice_qc

commit_qc

Блокировка голосования и несколько туров

Правило:

• Хост, отправивший FinalizeVote AGREE в раунде r для Finalization_hash H, заблокирован (r, H) .

• Хост не должен отправлять второй конфликтующий FinalizeVote для одного и того же (escrow_id, r) .

• Хост может принять FinalizeInit для r_new > r и проголосовать снова, только если unlock_timeout_certificate (и любая более строгая политика цепочки) показывает, что раунд r исчерпан без урегулирования - поэтому продвижение раунда оправдано, а не произвольное переворачивание представления.

Изменение Finalization_hash в более позднем раунде: Реализации ДОЛЖНЫ требовать unlock_timeout_certificate перед принятием FinalizeInit с другим Finalization_hash, отличным от хеша, за который хост ранее проголосовал AGREE, поэтому нечестный инициатор не может перенаправлять честных избирателей между конфликтующими предложениями без истечения времени ожидания или неудачного предыдущего раунда.

Практическое состояние каждого хоста:

• lock_round , lock_hash после голосования СОГЛАСИЕ до разблокировки или успешного расчета в основной сети для условного депонирования.

• В FinalizeInit(r_new) : если r_new > lock_round , требуется действительный unlock_timeout_certificate, охватывающий остановленные раунды для каждой политики; затем обновите блокировку при голосовании в r_new.

Повторить попытку без повторного раунда (необязательная оптимизация): если VoteQC существует, но CommitQC никогда не формируется, реализация МОЖЕТ повторно передать VoteQC и запустить еще одну волну FinalizeCommit в том же раунде вместо увеличения round . По умолчанию в этом документе используется круглая монотонность + новый FinalizeInit с unlock_timeout_certificate, поэтому каждая повторная попытка явно открывается.

Нет двойной финализации (идемпотентность)

Сплетни в подсети могут доставлять один и тот же материал FinalizeSubmit много раз, и нескольким сборщикам разрешено транслировать/отправлять его. Расчет по-прежнему должен происходить не более одного раза за каждое условное депонирование в основной сети.

Гарантии исходят из правил уровня приложения в keeper , а не только из протокола голосования/фиксации:

• Состояние терминала условного депонирования: цепочка хранит каждый escrow_id в жизненном цикле (например, АКТИВ → УСТАНОВЛЕНО / ЗАКРЫТО). Обработчик отклоняет любое сообщение завершения, если это условное депонирование уже оплачено (или уже прервано по определенному пути спора). Это основные ворота «никогда дважды».

Состояние условного депонирования терминала: цепочка хранит каждый escrow_id в жизненном цикле (например, АКТИВ → УСТАНОВЛЕНО / ЗАКРЫТО). Обработчик отклоняет любое сообщение завершения, если это условное депонирование уже оплачено (или уже прервано по определенному пути спора). Это основные ворота «никогда дважды».

• Необязательная привязка дайджеста: хранитель МОЖЕТ записать Last_finalization_hash (или Settled_terminal_nonce + обязательство по полезной нагрузке) для условного депонирования и отклонить вторую отправку, которая отличается (конфликтующая повторная попытка). Байт-идентичное воспроизведение одной и той же действительной отправки должно быть отклонено как дубликат или рассматриваться как недействующее (идемпотентный успех), чтобы сборщики, участвующие в гонках с одними и теми же сертификатами, не применяли эффекты дважды.

Необязательная привязка дайджеста: хранитель МОЖЕТ записать Last_finalization_hash (или Settled_terminal_nonce + обязательство по полезной нагрузке) для условного депонирования и отклонить вторую отправку, которая отличается (конфликтующая повторная попытка). Байт-идентичное воспроизведение одной и той же действительной отправки должно быть отклонено как дубликат или рассматриваться как недействующее (идемпотентный успех), чтобы сборщики, участвующие в гонках с одними и теми же сертификатами, не применяли эффекты дважды.

• Те же сертификаты, один эффект: VoteQC и CommitQC связывают отправку с одним Finalization_hash. Честные хозяева подписывают только один гарантированный результат за успешный раунд; для двух разных результатов потребуются разные хеши, и они не смогут пройти оба, если цепочка не разрешит второй раунд, который все равно должен соблюдать (1).

Те же сертификаты, один эффект: VoteQC и CommitQC связывают отправку с одним Finalization_hash. Честные хозяева подписывают только один гарантированный результат за успешный раунд; для двух разных результатов потребуются разные хеши, и они не смогут пройти оба, если цепочка не разрешит второй раунд, который все равно должен соблюдать (1).

• Дедупликация на уровне передачи: дедупликация последовательности/пула памяти Cosmos SDK предотвращает двукратное выполнение одной и той же подписанной передачи; отдельные транзакции, повторяющие один и тот же расчет, все равно должны завершиться неудачей в (1)–(2).

Дедупликация на уровне передачи: дедупликация последовательности/пула памяти Cosmos SDK предотвращает двукратное выполнение одной и той же подписанной передачи; отдельные транзакции, повторяющие один и тот же расчет, все равно должны завершиться неудачей в (1)–(2).

Фаза фиксации предотвращает подписание кворумом конфликтующих финалов без нового раунда и правил разблокировки; Идемпотентность основной сети предотвращает повторное применение расчетов для одного и того же условного депонирования.

Взаимодействие с основной сетью: одиночный проход туда и обратно

Фазы голосования и фиксации выполняются только на уровне devshard-local. FinalizeInit и контроль качества, созданные сборщиком, используют слухи о подсети; FinalizeCommit управляется только сборщиком (см. Транспорт). Во время выполнения этих этапов в основную сеть не поступает никаких сообщений — нет «отчета о голосовании по контролю качества» или «отчета о подтверждении контроля качества» как отдельных транзакций цепочки.

Одно цепное взаимодействие: когда подсеть завершена, сборщик (или резервный отправитель) передает одну подписанную транзакцию FinalizeSubmit, которая включает в себя полезную нагрузку расчета, поля случайности, VoteQC, CommitQC и все поля, необходимые для повторного вычисления Finalization_hash. Узел возвращает успешную передачу (расчет применен) или неудачу (ошибка проверки → отклонено).

Почему бы не увеличить количество шагов в основной сети: промежуточные события «голосование подтверждено» / «проверено подтверждение» будут подразумевать дополнительный трафик devshard↔ в основной сети и не повышать безопасность, если хранитель применяет состояние только к окончательному принятому сообщению. Проверка VoteQC и CommitQC происходит внутри этого одного обработчика.

События (для хостов devshard, а не дополнительные круговые обходы): хранитель должен генерировать события Cosmos по результатам, чтобы каждый хост devshard мог узнать результат, наблюдая за цепочкой, даже если отправляющий сборщик выйдет из строя, прежде чем сообщить об успехе:

• Finalization_settled — включает escrow_id, Finalization_hash и любые поля индекса, необходимые для кошельков/индексаторов.

• Finalization_rejected — включает escrow_id, Finalization_hash (если анализируемый) и код причины/класс ошибки.

Необязательно: один общий Finalization_outcome с перечислением SETLED | REJECTED вместо двух типов событий. Не создавайте отдельные события цепочки, которые отражают внутренние проверки голосования и фиксации, если только потребность продукта не требует аудита (который может оставаться в журналах, а не через p2p в основную сеть).

Изменения проверки в основной сети

Обработчик основной сети должен отклонять отправки финализации, если:

• Finalization_hash пересчитывает точно на основе полезных данных и доказательств.

• присутствуют случайный_источник и коллектор_рандомность_маяк; маяк проверяет заявленный источник; необязательная строгая проверка того, что подписывающие лица в VoteQC/CommitQC являются именно набором сборщиков из H(FinalizationHash || randomness_source || Collector_randomness_beacon || "collectors"), если цепочка проверяет членство сборщика.

• Триггерные доказательства действительны по заявленной причине (независимые проверки — например, Разделы синхронизации высоты USER_TIMEOUT, подтверждение заголовка EPOCH_CHANGE_IMMINENT).

• Голосование действительно и соответствует порогу 2f+1.

• CommitQC действителен, ссылается на VoteQC и соответствует порогу 2f+1 (или настроенному порогу фиксации).

• Проверки раундов и повторов проходят (escrow_id, монотонность раунда, отсутствие дублирующего хеша финализации).

• Идемпотентность: условное депонирование еще не урегулировано в соответствии с отсутствием двойной финализации, указанной выше; применяются повторяющиеся или противоречивые правила повторной отправки.

Пункты 4–5 — это проверки в памяти внутри одного tx, а не отдельных сообщений основной сети.

Минимизация связи

• Хосты отправляют FinalizeVote коллекторам (направленная ретрансляция или ретрансляция с адресом коллектора); FinalizeCommit предназначен только для сборщиков — никаких слухов о коммитах между хостами (достаточно для ограничения трафика коммитов).

• Коллекторы агрегируют и транслируют только компактные VoteQC/CommitQC.

• Большие двоичные объекты доказательств передаются по ссылке (хэш+выборка) после первого распространения.

• Дедупликация (escrow_id, round, message_hash).

Открытые вопросы

сообщить о совместном использовании до того, как будет принято окончательное предложение,

• Церемония обязательства Педерсена: точная фаза публикации, агрегация, правила открытия и проверка основной сети для randomness_source = PEDERSEN_COMMITMENT ,

• источник случайности по умолчанию для каждого параметра условного депонирования/цепочки (синхронизация по высоте против Педерсена против гибрида),

агрегированные BLS,

продолжительность хранения доказательств и гарантии сокращения,

• должен ли путь REJECT также создавать сертификаты фиксации для детерминированного урегулирования по умолчанию.