`devshard` Height-sync protocol

Протокол синхронизации по высоте

Конверты пользователя ↔ хоста содержат дополнительный HeightSyncSection, который подтверждает тройку основной сети (height,block_hash,block_timestamp). Этот раздел является единственным вводом для межузлового выравнивания времени, принятия решений о тайм-ауте и предиката IsStrictlyConfirmed(h), который выносит вердикт нисходящим протоколам (cPoC, финализация). Block_hash может быть источником детерменистической случайности, которая заранее неизвестна, может использоваться VALIDATION_PROTOCOL_PROPOSAL.md (https://github.com/a-kuprin/gonka/blob/devshard-testenv/devshard/docs/proposals/VALIDATION_PROTOCOL_PROPOSAL.md). Существуют и другие варианты источника случайности, которые необходимо обсудить.

block_timestamp может быть детерминированным временем, которое будет использоваться в devshard для таймаутов.

Этот документ является канонической спецификацией одной версии. Реализация в дереве соответствует этому документу; в каталоге тестов (height-sync-tests.md (https://github.com/a-kuprin/gonka/blob/devshard-testenv/devshard/docs/height-sync-tests.md)) указано, что уже доказано и что планируется.

Связанные документы: height-sync-tests.md (https://github.com/a-kuprin/gonka/blob/devshard-testenv/devshard/docs/height-sync-tests.md) (каталог тестов — реализован и запланирован), протокол CPOC для devshard (https://github.com/gonka-ai/gonka/discussions/1384), протокол финализации (https://github.com/gonka-ai/gonka/discussions/1369), VALIDATION_PROTOCOL_PROPOSAL.md (https://github.com/a-kuprin/gonka/blob/devshard-testenv/devshard/docs/proposals/VALIDATION_PROTOCOL_PROPOSAL.md).

Оглавление

Резюме (#1-резюме)

Проблема (№2-проблема)

Общий обзор протокола (#3-высокоуровневый обзор протокола)

Голы (#4-голы)

Глоссарий (#5-глоссарий)

Обзор архитектуры (#6-обзор архитектуры)

Формат провода (#7-формат провода)

Режимы синхронизации (Omit / Anchor / Strong) (#8-sync-modes-omit--anchor--strong)

Каденция (синхронизация поворотов, K, slots_num, принудительные повороты) (#9-каденция)

Правила производителя (#10-producer-rules)

Приемный конвейер (№ 11-приемник-конвейер)

Модель доверия и подписи (#12-trust-model-and-signatures)

Перенос, происхождение, атрибуция (# 13-перенос-происхождение-атрибуция)

API подтверждения ( IsStrictlyConfirmed ) (#14-confirmation-api)

Интеграция cPoC — полный API (#15-cpoc-integration-api)

Модель атаки и меры по ее устранению (#16-модель атаки)

Значения по умолчанию и конфигурация (#17-defaults-and-configuration)

Статус и вехи (#18-статус-и-вехи)

1. Резюме

Трафик вывода пользователь-хост содержит тело HTTP, состоящее из двух разделов:

• HeightSyncSection — дополнительная аттестация основной сети: подписанная пара (mainnet_height, mainnet_block_hash), а также метаданные кадрирования и происхождения.

• message_body — полезная нагрузка приложения (непрозрачна для синхронизации по высоте).

Раздел 1 выдается только при необходимости:

• Синхронизация хода — стандартная каденция: каждые K одноразовых номеров, окно последовательных одноразовых номеров slots_num несет в себе Anchor; между ними, Омит.

• Принудительный поворот синхронизации — MsgForceHeightSyncTurn в любой момент открывает диапазон привязки slot_num (открывается спор cPoC, принудительное вмешательство оператора).

• |Δ| > D — когда заявленная высота отправителя отличается от выровненной высоты получателя более чем на D, отправитель ДОЛЖЕН использовать Strong ( LightBlock + VerifyCommit ); в противном случае получатель отклоняет.

Хосты подписывают якоря ответной ветви своим ключом подписывающего лица secp256k1; пользователи-курьеры переносят эти подписанные BLOB-объекты вперед, проверяя при приеме и используя их в качестве доказательства невиновности по требованию. Якорям ветки запроса доверяют хосты (без встроенной подписи) — в случае спора пользователь доказывает происхождение позже.

Одиночный предикат IsStrictlyConfirmed(h) предоставляет нижестоящим потребителям дискретный ответ {подтвержденный, ожидающий, устаревший}.

2. Проблема

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

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

3. Общий обзор протокола

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

Итак, основные дизайнерские решения приняты:

• Синхронизация высоты происходит не при каждом nonce, а только в специализированных окнах, где мы добавляем только к запросу/ответу (height,block_hash) и подпись отправителя (хоста, отвечающего на запрос), чтобы доказать происхождение этих данных для возможных споров. Пользователь переносит (высоту, block_hash) при следующих запросах для распространения этих данных на другие хосты.

• Мы доверяем высотам в будущем без дополнительных доказательств в сети, если высота близка к той, которая, как мы знаем, является текущей. Если между хостами существуют большие разногласия по высоте ( height_in_the_future -known_height = |Δ| > D ), мы используем полные данные из основной сети (хэш блока и подписи валидаторов) для проверки высоты.

• Если мы обнаружим, что ранее предоставленная каким-либо хостом высота не соответствует оракулу block_hash, мы начинаем спор.

В результате мы предоставляем API для devshardd и devshardctl, который выдает последнюю высоту, хэш блока и информацию, если с этим согласны большинство участников сети devshard.

4. Цели

• Дешевое периодическое выравнивание — Anchor (без LightBlock ) по расписанию синхронизации позволяет каждому хосту видеть время основной сети в ограниченном окне без накладных расходов на проверку каждого сообщения.

• Сильная эскалация разногласий — однажды |Δ| > D или финализация требует этого, доказательство с привязкой к кворуму валидатора ( LightBlock ) является обязательным.

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

• Устойчивость к повторному воспроизведению — бюджет актуальности F по временной метке отправителя + учет последней распространенной информации для каждого получателя не позволяет оператору повторно использовать устаревшие или уже доставленные чаевые.

• Контракт подтверждения для последующих потребителей — дискретный предикат IsStrictlyConfirmed(h) ∈ {confirmed, pending, stale}, поэтому cPoC/финализация не изобретают собственную логику кворума.

• Развертывание только через курьера — пользователи, у которых нет собственных последователей в основной сети, по-прежнему могут передавать подписанные подсказки хоста между хостами в циклическом переборе и подтверждении охвата (C-quorum).

5. Глоссарий

6. Обзор архитектуры

блок-схема LR основная сеть подграфа [основная сеть Gonka] BC[Консенсус CometBFT] end BC -- "заголовки блоков + фиксации" --> HSD[heightsyncd /blockoracle] хост подграфа [время выполнения хоста] HSD --> SCH_H[AnchorScheduler<br/>локальный источник Oracle] SCH_H --> TX_H[transport.Server<br/>подписывает ответную часть] TX_H -- «HeightSyncSection<br/>входящий запрос» --> RX_H[Конвейер получателя<br/>D-диапазон, актуальность, классификация] RX_H --> AUD_H[AuditRing + ConfirmationIndex] AUD_H -- «IsStrictlyConfirmed» --> CPOC_H[потребитель cPoC] конечный пользователь подграфа [Courier user / devshardctl] TIPS[HeightSyncPeerTips<br/>дословно подписанные BLOB-объекты] --> SCH_U[AnchorScheduler<br/>источник одноранговых подсказок] SCH_U --> TX_U[transport.HTTPClient<br/>Перенести, снять подпись по запросу] TX_U -- "входящий ответ<br/>проверить + кэш" --> RX_U[Проверить ответ Anchor<br/>RecordOriginWithBlob] RX_U --> TIPS TIPS -- "IsStrictlyConfirmed" --> CPOC_U[потребитель cPoC] end TX_U -- "ветвь запроса<br/>HeightSyncSection" --> RX_H TX_H -- "ветвь ответа<br/>HeightSyncSection (подписанная)" --> RX_U

Ключевые инварианты:

• У каждого хоста есть собственный подписчик в основной сети (heightsyncd /blockoracle); это канонический источник local_aligned.

• У пользователя нет подписчиков (режим курьера); он извлекает local_aligned из проверенного однорангового кэша, заполненного подписанными ответами хоста.

• HeightSyncSection — единственная поверхность проводов, связанная с основной сетью, на конвертах вывода; приемный трубопровод – однопоточный.

7. Формат провода

HeightSyncSection передается как поле protobuf в конверте вывода и зеркально отображается в формате JSON для инструментов. Номера полей стабильны.

Примечания:

• Деградированный якорь (тихая подача). Если локальный оракул не получил новый блок в StaleAfter, но Latest() по-прежнему возвращает кэшированный заголовок, хосты выдают обычный Anchor (поля 1–8) плюс поле 10. Это позволяет избежать реакции синхронизации-поворота. Пропустить во время длинных промежутков между блоками; консенсус среди хостов по-прежнему исправляет меньшинство устаревшим советом. Пропустить остается обязательным, если нет кэшированной подсказки (канал никогда не запускался), происходит сбой Latest() (канал недоступен) или кеш одноранговых подсказок курьера пуст.

• Подписи, привязанные к направлению. Поле 8 устанавливается хостами только в ответах. Carry() очищает поле 8 перед отправкой части запроса; Проверка входящего запроса не требует встроенной подписи.

• Канонический ввод подписи. CanonicalOriginBytes(sec) = "heightsync.origin.v1" || прото.Маршал(поля 1..7) . Поле 8 не является частью входных данных для подписи.

• Резервирование на уровне проводов. origin_attestation (встроенный исходный объект) зарезервирован для будущих встроенных развертываний; текущий протокол использует асимметричную модель (подписанный ответ, доверенный запрос, оправдание по требованию).

Зеркало JSON:

{ "height_sync": { "proof_type": "height-anchor-v1", "mainnet_height": 42, "mainnet_block_hash_hex": "abc... ", "timestamp_unix_ms": 1700000000000, "направление": "ответ", "originator_sender_id": " gonka1host... ", "originator_timestamp_unix_ms": 1700000000000, "sender_signature": "base64... " , "light_block" : " base64... ", "tip_stale_after_ms": 12000 } }

( Tip_stale_after_ms опускается, если кэшированная подсказка свежая.)

8. Режимы синхронизации (пропустить/привязать/сильный)

stateDiagram-v2 направление LR [*] --> Пропустить Пропустить --> Привязка: одноразовый номер при синхронном повороте/принудительном повороте/ленивом переносе Привязка --> Пропустить: следующий одноразовый номер за пределами окна Привязка --> Строгая: \|H − local_aligned\| > D ИЛИ принудительное (StrongRequired) Сильное --> Привязка: партнеры перестроены, снова внутри D Привязка --> Привязка: частота шагов на следующем ходу Сильная --> Сильная: неподвижно > D

Периодическое выравнивание использует только Anchor. Сильный – это не шаг по умолчанию, а путь разногласий/споров.

Тихий канал против мертвого канала (хосты):

9. Каденс

Синхронно-поворотные окна

Для направления сеанса для исходящего nonce n:

• Начальный ход синхронизации: 1 ≤ n ≤ slots_num → Anchor (или Strong, см. §10).

• Периодические циклы синхронизации: для каждого i ≥ 1 i·K ≤ n ≤ i·K + slot_num − 1 → Anchor.

• Все остальные одноразовые номера → Опустить, если не применяется принудительная директива или отложенный перенос.

Ограничение: K ≥ slot_num, чтобы окна никогда не перекрывались.

Gantt title Частота синхро-поворотов (K=8, slot_num=4) dateFormat X axisFormat %s раздел Каденция Начальный синхро-поворот (Привязка) :a1, 1, 4 Пропустить :a2, 5, 7 Периодический синхро-поворот 1 :a3, 8, 11 Пропустить :a4, 12, 15 Периодический синхро-поворот 2 :a5, 16, 19

Принудительный поворот синхронизации

MsgForceHeightSyncTurn(trigger_nonce, slots_num, Reason,strong_required?) открывает диапазон ActiveForcedTurn{start, end}:

• Оба направления ДОЛЖНЫ излучать Anchor для каждого конверта в [start, end] . Пропустить внутри принудительного поворота НЕДЕЙСТВИТЕЛЬНО.

• Strong_required = true обновляет окно до Strong.

• Вторая директива, пока ход активен, молча игнорируется.

• Принудительное окно, которое перекрывает следующее окно каденции, поглощает его (нет двойной привязки на границе).

• После n > end каденция возобновляется по стандартному правилу.

Отложенный перенос (курьерские развертывания)

За пределами любого окна синхронизации-поворота пользователь-курьер МОЖЕТ выдать Anchor на этапе запроса iff:

• Одноранговый кеш содержит новый раздел отправителя ( MaxFresh(now, F) возвращает ненулевое значение).

• кэшированная_максимальная_высота > Last_propagated[получатель] .

Получатель классифицирует это как VALID_LAZY_ANCHOR (тег аудита lazy ); он не открывает обязательство синхронизации-поворота.

10. Правила продюсера

Хосты (есть собственный оракул)

• При каждом исходящем ответе: обратитесь к местному оракулу; если применяется синхронный или принудительный поворот, выдайте Anchor с OriginatorSenderID = host_address , OriginatorTimestampMs = now и подпишите раздел (поле 8). Если оракул молчит (нет нового блока внутри StaleAfter), но существует кэшированный совет, все равно выдайте этот Anchor и установите для Tip_stale_after_ms возраст последнего принятого блока (поле 10 устанавливается после подписания полей ввода 1–7). Пропускайте только в том случае, если нет полезной кэшированной подсказки или происходит сбой Latest().

• Если установлен Force.StrongRequired ИЛИ значение Peer_aligned_height получателя отличается от локального наконечника на > D: создайте Strong, присоединив кэшированный LightBlock для H (поле 9).

• По входящим запросам: ничего не подписывайте; классифицировать через приемный конвейер (§11).

Пользователь-курьер (нет собственного оракула)

• Поддерживайте HeightSyncPeerTips с ключом OriginatorSenderID .

• Проверка ответов хоста при приеме ( VerifyOrigin ); в случае неудачи отбросьте подсказку и увеличьте origin_sig_invalid_total.

• По исходящим запросам: обратитесь к планировщику; ленивый перенос только тогда, когда в кеше есть подсказка, еще не переданная получателю. Перед отправкой очистите поле 8 (sender_signature).

• Производитель никогда не устанавливает OriginatorSenderID = user_address; это поле отражает хост, подписавший кэшированный большой двоичный объект.

11. Ресиверный конвейер

блок-схема TD A[конверт прибывает] --> B{HeightSyncSection<br/>присутствует?} B -- нет --> O{nonce в синхронном повороте /<br/>активный принудительный поворот?} O -- да --> O1[INVALID<br/>sync_turn_anchor_missing] O -- нет --> O2[VALID_OMIT] B -- да --> C{Привязка или сильная?} C -- Привязка --> D {"|H − local_aligned| > D?"} D -- да --> D1[НЕВЕРНО<br/>strong_required] D -- нет --> E{перенести<br/>набор исходного источника?} E -- да --> F{оригинатор в F?} F -- нет --> F1[НЕВЕРНО<br/>stale_required] F -- да --> G[классифицировать каденцию / ленивый<br/>по nonce vs синхронизировать поворот] E -- нет --> G C -- Strong --> H[StrongVerifier.VerifyLightBlock] H -- ok --> I[VALID_STRONG] H -- неудачно --> H1[INVALID<br/>strong_proof_invalid] G --> J{блок H локальный И<br/>хеш совпадает?} J -- да/совпадение --> K[VALID_ANCHOR или<br/>VALID_LAZY_ANCHOR] J -- нет/local-missing --> L[поставить в очередь отложенную проверку] J -- локальное И несоответствие --> M{присутствует отправитель?} M -- да --> M1[DISPUTE_ORIGINATOR] M -- нет --> M2[DISPUTE_CARRIER]

Нормативные шаги для конверта без пропуска:

• Парсинг + кадрирование (прото/JSON).

• Сначала проверьте вынужденный поворот. Если ActiveForcedTurn[start..end] установлен и start ≤ nonce ≤ end, конверт ДОЛЖЕН быть Anchor (или Strong, если StrongRequired). Пропустить ⇒ НЕДЕЙСТВИТЕЛЬНО.

• Группа Д. Еслиproof_type == "height-anchor-v1" и |H − local_aligned| > D: НЕВЕРНО (strong_required).

• Сильный путь. Еслиproof_type == "cometbft-light-block-v1": запустите StrongVerifier.VerifyLightBlock (идентификатор цепочки, заголовок против утверждений, validators_hash, необязательный шаг 3b с привязкой к эпохе, BlockID, фиксация > 2/3); неудача ⇒ НЕДЕЙСТВИТЕЛЬНО (strong_proof_invalid).

• Наличие оригинатора и свежесть. Если OriginatorSenderID != "" : Если now_ms − OriginatorTimestampMs > F ⇒ НЕДЕЙСТВИТЕЛЬНО (stale_origin); доверие аудита = TrustDisputeCarrier . Остальное продолжайте.

• Если now_ms – OriginatorTimestampMs > F ⇒ НЕДЕЙСТВИТЕЛЬНО (stale_origin); доверие аудита = TrustDisputeCarrier .

• Остальное продолжайте.

• Каденция/ленивая классификация. Внутренняя синхронизация-поворот (каденция/начальная/принудительная): VALID_ANCHOR (каденция тега). Внешняя синхронизация-поворот + присутствует отправитель (курьер): VALID_LAZY_ANCHOR (тег lazy ). Внешняя синхронизация + отправитель отсутствует + Привязка: самоаттестация устаревшего хоста; VALID_ANCHOR .

• Внутренняя синхронизация-поворот (каденция/начальная/принудительная): VALID_ANCHOR (каденция тега).

• Внешняя синхронизация-поворот + присутствует отправитель (курьер): VALID_LAZY_ANCHOR (тег lazy ).

• Внешняя синхронизация + отправитель отсутствует + Привязка: самоаттестация устаревшего хоста; VALID_ANCHOR .

• Согласование местного оракула. Если блок H локальный и хэш совпадает → подтверждается немедленно; фид ConfirmationIndex. Если H еще не является локальным → поставить в очередь отложенную проверку по (оригинатор, H, хеш); не увеличивайте height_seen_max. Если H является локальным и хеш-код отличается → DISPUTE_ORIGINATOR (присутствуют метаданные отправителя) или DISPUTE_CARRIER (отсутствует отправитель или подпись не удалась); сохранить оскорбительный подписанный BLOB-объект.

• Если блок H локальный и хэш совпадает → подтверждается немедленно; фид ConfirmationIndex.

• Если H еще не является локальным → поставить в очередь отложенную проверку по (оригинатор, H, хеш); не увеличивайте height_seen_max.

• Если H является локальным и хеш-код отличается → DISPUTE_ORIGINATOR (присутствуют метаданные отправителя) или DISPUTE_CARRIER (отсутствует отправитель или подпись не удалась); сохранить оскорбительный подписанный BLOB-объект.

• Аудит + метрики. Добавьте AnchorAttestation (с Tag , Trust , OriginatorSenderID , OriginSignedBlobAvailable ) к одноранговому кольцу; выдавать счетчики.

• Обработать message_body, если оно не INVALID.

Классы результатов

12. Модель доверия и подписи

Протокол асимметричен: ответы подписываются, запросы доверяются, оправдание происходит по требованию.

Участник SequenceDiagram U как пользователь (курьер) Участник H как хост A Участник H2 как хост B U->>H: запрос (участок запроса, без подписи) H->>U: ответ Привязка [подписанная хостом A] Примечание над U: VerifyOrigin OK<br/>RecordOriginWithBlob(host_A, H, blob, sig) U->>H2: привязка запроса (перенос вперед, без встроенной подписи) Примечание через H2: доверяет несущему<br/>применяется шлюз свежести F. Примечание над H2: позже ведомый продвигается<br/>сравнивает хэш с каноническим H2 -->>U: DEFERRED_FAIL? открытый спор против пользователя U->>U: HeightSyncEvidenceFor(host_A, H) → blob + sig U-->>H2: Signed_blob доказывает отправителя = хост A<br/>⇒ DISPUTE_ORIGINATOR против хоста A

Этап ответа (хост → пользователь)

• Хост заполняет OriginatorSenderID, OriginatorTimestampMs, создает CanonicalOriginBytes (поля 1–7 + домен heightsync.origin.v1).

• Подписывается ключом secp256k1 хоста, устанавливает поле 8.

• Пользователь проверяет поле 8 при приеме. Ошибка ⇒ удаление, нет кэша, нет распространения; origin_sig_invalid_total увеличивается.

• В случае успеха: RecordOriginWithBlob(originator, sec, blob, sig) .

Ветка запроса (пользователь → хост)

• Перенос копирует поля отправителя (6, 7) из кэшированного большого двоичного объекта.

• Carry() удаляет поле 8 перед отправкой.

• Хост принимает раздел, соответствующий конвейеру-получателю (§11). Никакая встроенная подпись не требуется и не проверяется.

Оправдание

Если позже хост открывает спор против пользователя-перевозчика, пользователь вызывает HTTPClient.HeightSyncEvidenceFor(originator, H) для создания кэшированного (blob, sig) . Средство проверки спора повторно запускает VerifyOrigin ; успех ⇒ вина переносится на исходный хост ( DISPUTE_ORIGINATOR ); неудача ⇒ вина остается на перевозчике ( DISPUTE_CARRIER ).

Сильное доказательство

Когда Strong находится на связи (light_block не пуст), проверка является криптографической по отношению к закрепленному набору валидаторов:

• Декодируйте байты как эквивалент LightBlock (blockoracle.Header).

• Проверьте «chain_id», «height», «block_hash» на соответствие требованиям.

• Убедитесь, что validators_hash соответствует корню Меркла закрепленного набора.

• (Необязательно) Шаг 3b — сверка с набором участников для каждой эпохи.

• Проверьте BlockID == hdr.BlockID .

• Запустите VerifyCommit: каждая подпись фиксации передается закрепленному валидатору, дубликатов нет, накопленная мощность строго > 2/3 от общей суммы.

• (Необязательно) Периодичность: h ≥ local_tip − max_lag_blocks else VALID_STALE .

13. Перенос, происхождение, атрибуция

Правила

• Поля отправителя являются неизменяемыми для всех переходов. Оператор НЕ ДОЛЖЕН перезаписывать OriginatorSenderID или OriginatorTimestampMs.

• D привязан к переносу. Перенос привязки с |H − local_aligned| > D НЕДЕЙСТВИТЕЛЬНО; Вместо этого оператор связи ДОЛЖЕН перейти на уровень «Сильный». (Это более строгая форма Strong_required.)

• Подпись отправителя удалена по запросу. Исходящий запрос пользователя никогда не содержит поле 8. Хост доверяет запросу на основе правил свежести и частоты; криптографическое доказательство находится в кэшированном большом двоичном объекте пользователя.

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

последняя_пропагированная дисциплина

HeightSyncPeerTips.ShouldPropagateTo(recipient, h) возвращает true, если h > last_propagated[recipient] . При успешной отправке MarkPropagated(recipient, h) поднимает верхнюю отметку. Для достижения кворума на позднем хосте требуется лестница строго возрастающей высоты (верная в производстве), а не три ленивых переноса на одном и том же H .

14. API подтверждения

Контракт

// devshard/heightsync/confirmation.go type ConfirmState int const ( ConfirmPending ConfirmState = iota ConfirmConfirmed ConfirmStale ) type ConfirmationView интерфейс { IsStrictlyConfirmed ( h uint64 ) ConfirmState }

Семантика:

• подтверждено — h очистил настроенное правило подтверждения. Нижестоящие протоколы МОГУТ рассматривать (h, hash) как авторитетные.

• в ожидании — у функции синхронизации высоты есть данные для h, но правило еще не очищено. Нижестоящие компании НЕ ДОЛЖНЫ выносить состязательные вердикты; cPoC возвращает неопределенный результат ( C6 ).

• stale — h не может быть вычислен, поскольку оракул устарел/отключен. Нижестоящая компания считает вердикты неубедительными до тех пор, пока они не будут восстановлены.

Монотонность: однажды подтвержденная высота остается подтвержденной. ожидание → подтверждено — единственный переход вперед.

Правила подтверждения

Настраивается во время развертывания:

Развертывания PoC без Strong run (C-quorum). При развертывании производственного класса СЛЕДУЕТ выбрать (C-гибрид) после включения Strong.

Память подтверждений и обрезка

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

• При продвижении кончика: компактный ( max_height < Tip − W_conf или Observe_at Past F ).

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

Индивидуальный просмотр, а не глобальный

IsStrictlyConfirmed вычисляется по собственному кольцу и часам аудита вызывающего абонента. Два верификатора могут временно не согласиться (ожидание или подтверждение); Срезка на основе кворума cPoC допускает это.

15. Интеграция cPoC — полный API

Следующие API Go представляют собой стабильную поверхность, которую используют cPoC и финализация. Пути реализации указаны в скобках.

15.1 Дискретный предикат подтверждения

// На стороне пользователя (курьера): func (c * Transport. HTTPClient) ConfirmationView() heightsync. ConfirmationView // На стороне хоста (собственный оракул): func (s * Transport. Сервер) ConfirmationView() heightsync. Просмотр подтверждения

Оба предоставляют ConfirmationView.IsStrictlyConfirmed(h uint64) ConfirmState . cPoC §C6 / §C14 / §Вердикт, шаг 5, позвоните напрямую.

Пример использования (вердикт cPoC):

просмотр := сервер . ConfirmationView() переключение вида. IsStrictlyConfirmed (h) {case heightsync. ConfirmConfirmed: // регистр вердикта фиксации heightsync. ConfirmPending: возвращает InconclusivePendingHeight(h) в случае heightsync. ConfirmStale: return InconclusiveStaleOracle() }

15.2 Наблюдаемая высота (пульс курьера)

func ( c * транспорт. HTTPClient) ObservedHeightNow() (uint64, bool)

Возвращает (h, true), где h — самая высокая свежая подсказка в кэше одноранговых подсказок курьера; (0, ложь), когда нет свежего наконечника или синхронизация высоты не настроена. Используется пульсом cPoC C14 — ложный возврат означает «Неубедительно — нет свежей высоты».

15.3 Доказательства, оправдывающие вину (уровень спора)

// На стороне пользователя: создать подписанный BLOB-объект отправителя для (originator, h). func ( c * транспорт. HTTPClient) HeightSyncEvidenceFor (строка источника, h int64,) (blob, sig [] байт, ok bool)

Возвращается кэшем курьера ( HeightSyncPeerTips.OriginSignedBlobFor ). Можно проверить с помощью heightsync.VerifyOriginDetached(verifier, sec, blob, sig) без доступа к пользователю.

15.4 Доказательства сильной степени (сильный режим)

// Хост-сторона: вернуть кэшированный LightBlock для h, если он доступен. func(s *transport. Сервер) LightBlockFor (h int64) (доказательство [] байт, ок bool)

Когда ведомый получателя прошел мимо спорного H , спорный пакет может содержать обе половины:

• Подписанный BLOB-объект отправителя из HeightSyncEvidenceFor (виновник).

• LightBlock получателя из LightBlockFor (каноническая пара).

Верификатор ложного спора возвращает DISPUTE_ORIGINATOR, когда оба пройдены.

15.5 Семена холодного запуска (опция)

// Опция сервера: транспорт. WithHeightSyncSeedRPC ( true ) // Вызов клиента: func ( c * Transport. HTTPClient) SeedHeightSync (ctx context. Контекст) (uint64, bool, ошибка)

Согласие POST /sessions/:id/height-sync : хост возвращает принудительную привязку (подписанную отправителем). Курьер проверяет + кэширует его перед выдачей первого вывода — полезно для кратковременных сеансов, когда первый вывод не выполняется в ходе синхронизации.

15.6 Принудительный синхронный поворот

// Оператор/спор/триггер cPoC: состояние. SendMsgForceHeightSyncTurn ( триггерНонсе , slotsNum , причина , StrongRequired )

Открывает ActiveForcedTurn в следующем диффе; каждый конверт в [trigger, Trigger + slots_num − 1] ДОЛЖЕН быть Anchor (или Strong, если StrongRequired = true ).

15.7 Аудит и споры с потребителями

тип AuditRing интерфейс { List ( строка PeerID ) [] AnchorAttestation ListPeers () [] строка ConfirmationView () ConfirmationView } func ( c * Transport. HTTPClient) HeightSyncAuditRing () * heightsync. Функция AuditRing (s*transport. Сервер) HeightSyncAuditRing () * heightsync. АудитРинг

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

16. Модель атаки

Каждая строка отображает действия противника на защиту протокола и на тестовый сценарий, который это доказывает (полный каталог в height-sync-tests.md (https://github.com/a-kuprin/gonka/blob/devshard-testenv/devshard/docs/height-sync-tests.md)).

Внешние противники:

• Злоумышленник, который контролирует > 2/3 валидаторов основной сети — вне защиты этого протокола; то же, что и любое консенсусное предположение L1.

• Злоумышленник, который отравляет локальный оракул блока хоста — оракул блока имеет собственный закрепленный верификатор набора валидаторов (blockoracle/verifier); синхронизация высоты не проверяется повторно.

17. Значения по умолчанию и конфигурация

Порядок чтения для участников

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

• §8 — три режима синхронизации и диаграмма состояний.

• §11 — блок-схема конвейера приемника; это нормативный раздел по несущей способности.

• §12 — асимметричная модель подписи.

• §14 + §15 — что на самом деле потребляет cPoC.

• height-sync-tests.md (https://github.com/a-kuprin/gonka/blob/devshard-testenv/devshard/docs/height-sync-tests.md) — каждое приведенное выше поведение привязано как минимум к одному именованному тесту.

Важным моментом в соответствии с этим предложением является то, что часть консенсуса выходит за рамки и должна быть здесь: Протокол финализации (https://github.com/gonka-ai/gonka/discussions/1369).

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

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

Случайные комментарии, часть 1.

• Я бы предложил подробно описать «неоптимистический путь». Насколько я понимаю, этот путь ведет к раунду консенсуса, но, возможно, это следует описать лучше. В частности, «Сильный (LightBlock + VerifyCommit)» — либо необходимы ссылки на протокол, либо должно быть предоставлено его описание. Существующее описание слишком схематично (по крайней мере, на мой посторонний взгляд).

Также я бы предложил более подробно описать использование height/block_hash: возможно, после этого станут очевидными некоторые улучшения алгоритма.

• Несколько случайных вопросов и идей по поводу D (максимального интервала между соседними высотами):

... Мы доверяем высотам в будущем без дополнительных доказательств в сети, если высота близка к той, которая, как мы знаем, является текущей. Если между хостами существуют большие разногласия по высоте (height_in_the_future -known_height = |Δ| > D), мы используем полные данные из основной сети (хэш блока и подписи валидаторов) для проверки высоты...

Что, если разница во времени между одноразовыми номерами достаточно велика? Например, 1 минута? Это приведет к большим разногласиям и раунду консенсуса (даже несмотря на то, что нет реальной причины для спора: модель атаки 13, длительное время между блоками (подача тихая, кешированный совет все еще действителен)). Представьте, что запросы на вывод приходят с интервалом в 1 минуту: каждый будет сопровождаться консенсусом.

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

Здесь у нас могут быть следующие предложения:

а) (Может быть, это неправильно), но основное использование высоты — это обнаружение фазы PoC: если пользователь запрашивает вывод, но узел отвечает «отклонено из-за PoC». В этом случае пользователь немедленно отправляет запрос следующему узлу, и ответ приходит немедленно, и D важен. Таким образом, проверка на D может быть активирована только в некоторых случаях. В противном случае мы всегда доверяем прогрессу высоты, если только предыдущая высота не была раньше нашей.

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

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

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

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

Я думаю, мы начнем еще одну дискуссию в зависимости от источника случайности.

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

Важная информация о D: элементарный анализ показывает, что на границе периода неактивности 30 секунд/1 минуты требуется значительное увеличение количества раундов консенсуса.

Очень приблизительные фактические данные: в эпоху 263 было 590 000 запросов на вывод на 44 пользователя, что дает T = 0,15 запросов в секунду. Мы можем считать (в качестве первого предположения), что запросы на вывод следуют распределению Пуассона, это дает e^(-0,15 * 60) = 0,0001 вероятность 60-секундного бездействия; и e^(-0,15 * 30) = 0,01 вероятность 30-секундного бездействия.

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

D здесь не связан с одноразовыми номерами/блоками, он связан с высотой блока основной сети.

Если мы находимся на разнице высот > D, нам следует запустить раунд консенсуса, и время приращения блока в основной сети довольно стабильно, около 5 секунд, но при высокой нагрузке зимой мы наблюдали медленное построение блоков, когда один блок увеличивался примерно за 30-45 секунд.

Вопрос: Существует вектор атаки, модель атаки 13, Длительное время между блоками (отключение канала, кэшированная подсказка все еще действительна). Однако есть ли какая-либо конкретная атака/случай длительного бездействия пользователя?

Это было описано отдельно в предложении протокола cPoC. На него есть ссылка в этом документе в репозиториях GitHub, но я только что опубликовал его как обсуждение: # 1384 (https://github.com/gonka-ai/gonka/discussions/1384).

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

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

Генерация случайных чисел

Генерация случайных чисел из хеша блокчейна самого последнего блока основной сети имеет много преимуществ, однако имеет следующие проблемы:

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

он не позволяет генерировать номер "на месте" --- требует задержки до прибытия нового блока основной сети.

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

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

Обе проблемы можно решить, но за это приходится платить, поэтому рекомендуется рассмотреть разные подходы.

Альтернативный подход

В качестве простого альтернативного подхода мы предлагаем использовать стандартную схему обязательств. Возьмем какую-нибудь надежную хеш-функцию (например, sha256) --- назовем ее F(x), где x — двоичная строка.

Тогда генерация случайных чисел (для пользователя U и хоста H) может следовать следующей схеме:

• Каждая сторона (U и H) генерирует одно случайное число --- пусть это будут R_U и R_H. Это должно быть длинное число, например. 128 или 256 бит, чтобы предотвратить угадывание числа.

Каждая сторона (U и H) генерирует одно случайное число --- пусть это будут R_U и R_H. Это должно быть длинное число, например. 128 или 256 бит, чтобы предотвратить угадывание числа.

• Затем стороны обмениваются хэшами числа --- H отправляет F(R_H) в U, а U отправляет F(R_U) в H.

Затем стороны обмениваются хэшами числа --- H отправляет F(R_H) в U, а U отправляет F(R_U) в H.

• После обмена значениями стороны обмениваются исходными случайными числами: таким образом, каждая из сторон знает R_U, R_H, F(R_U) и F(R_H).

После обмена значениями стороны обмениваются исходными случайными числами: таким образом, каждая из сторон знает R_U, R_H, F(R_U) и F(R_H).

• Значение Xor(R_U,R_H) является желаемым случайным значением.

Значение Xor(R_U,R_H) является желаемым случайным значением.

Каковы свойства этого протокола, анализ его безопасности

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

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

• Значения F(R_U) и F(R_H) не раскрывают никакой информации о R_U, R_H, хотя в случае коротких чисел возможен перебор (поэтому у нас есть требование 128 или 256 бит).

Значения F(R_U) и F(R_H) не раскрывают никакой информации о R_U, R_H, хотя в случае коротких чисел возможен перебор (поэтому у нас есть требование 128 или 256 бит).

• Стороны не могут изменить свое решение после обмена хэшами.

Стороны не могут изменить свое решение после обмена хэшами.

Хэш-коллизии

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

Например, у вас есть пара чисел, которые имеют один и тот же хэш, но разные значения: A,B такие, что F(A) = F(B). Таким образом, в момент раскрытия чисел у противника может быть выбор (либо А, либо Б), что может привести к некоторому контролю над полученным случайным числом.

Чтобы предотвратить это, можно добавить к схеме обмен одноразовыми номерами:

• Стороны обмениваются двумя случайными числами (N_U и N_U соответственно), и случайные числа, генерируемые на шаге 1, должны включать эти числа в качестве префиксов: R'_U = N_H++R_U и R'_H = N_U++R_H, где ++ — объединение двоичных строк.

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

Общий анализ

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

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

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

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

• Однако он не сопротивляется совместной случайной генерации: когда и U, и H вместе пытаются подделать желаемое число. Хэш-схема блокчейна также в некоторой степени имеет эту проблему.

Однако он не сопротивляется совместной случайной генерации: когда и U, и H вместе пытаются подделать желаемое число. Хэш-схема блокчейна также в некоторой степени имеет эту проблему.

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

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

Чтобы этого не произошло, предлагается следующая идея.

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

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

• Хост и верификатор для данного вывода определяются путем генерации случайных чисел.

Хост и верификатор для данного вывода определяются путем генерации случайных чисел.

• Затем верификатор запрашивает у хоста вывода его прошлую задачу (одну из 32) и выполняет необходимую проверку. Если случайное число не всегда генерируется противниками, а хотя бы иногда (фактически в 2/3 случаев) действительно случайно, это дает хорошую гарантию от мошенничества.

Затем верификатор запрашивает у хоста вывода его прошлую задачу (одну из 32) и выполняет необходимую проверку. Если случайное число не всегда генерируется противниками, а хотя бы иногда (фактически в 2/3 случаев) действительно случайно, это дает хорошую гарантию от мошенничества.

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

Главный вопрос здесь — как генерировать случайные числа. Текст ниже объясняет это.

Генерация случайных чисел

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

Представьте себе, пользователь U с хостом H генерирует число, и это число определяет верификатора (и они злоупотребляют протоколом, чтобы выбрать верификатора из своей команды). Это приводит нас к выводу, что число должно генерироваться всеми остальными хостами в devshard. Например, это может быть последовательная генерация: для первого вывода H_0 число генерируется U и H_1. Для второго вывода H_0 — по U и H_2 и так далее. Таким образом, после 32 раундов (или 32 выводов каждого хоста) по крайней мере 20 из них будут случайно выбраны несотрудничающей стороной.

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

Конкретные детали еще предстоит определить, но основная идея в том, что этот цикл должен сознательно идти с разной скоростью (по сравнению с циклом вывода). Чтобы в течение одного цикла вывода (чтобы вывод, начиная с H_0, возвращался обратно в H_0), хосты цикла проверки должны быть сдвинуты (verificatoin.H_0 с inference.H0 -- они начинаются на одном и том же хосте, но в момент возврата обратно в H_0 проверка должна быть в H_k с k/= 0).

Так как в сети 2/3 честных хостов, то за 2 из 3 циклов хост окажется в паре с хостом, которого нет в его команде противника. И после 11 циклов у каждого хоста будет хотя бы одна проверка, контролируемая независимым хостом.

Цикл вывода может быть облегченным (то есть он может не иметь независимого блокчейна), и все транзакции могут быть добавлены в одну и ту же последовательность различий; эти два цикла могут быть переплетены в одном блокчейне devshard детерменистическим образом.

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

Я думаю, что этот стиль обязательства Педерсона для источника случайности является лучшим вариантом для финализации (https://github.com/gonka-ai/gonka/discussions/1369) выбора сборщика для обязательства.

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