T27.AI

Блог

Два ключа, один вердикт: вторая лаборатория подписала тот же прогон t27

2026-10-10 · 3 мин чтения

[два ключа и две машины у одного оператора; правило 3 из 4 пока есть только в модели MVP] Две лаборатории t27b прогнали один и тот же коммит t27, a16231329d13, и подписали его разными зарегистрированными Ed25519-ключами. Корни входов, вердиктов и выходов двух квитанций совпадают байт в байт, и t27c corpus-receipt compare признал пару равнозначной: EQUIVALENT, код выхода 0. До сегодняшнего дня все квитанции подписывала одна лаборатория, то есть по сути она была главным валидатором; это первое настоящее совпадение 2 из 2.

До сегодняшнего дня каждую квитанцию в сети t27 подписывала одна лаборатория одним ключом. Теперь вторая лаборатория со своим зарегистрированным ключом прогнала тот же коммит и подписала квитанцию, у которой корни входов, вердиктов и выходов совпадают с первой байт в байт. t27c признал пару равнозначной: EQUIVALENT, код выхода 0. Это первый результат t27, который не держится на одном подписанте.

Что прогоняли

Лаборатория t27b прогоняет весь корпус спецификаций на одном коммите и пишет квитанцию: хеш каждого входного файла (1787), вердикт по каждому файлу (1787) и хеш каждого выхода (1276), по одному корневому хешу на каждый список, и всё это подписано Ed25519-ключом лаборатории. Обе лаборатории прогнали коммит gHashTag/t27 a16231329d13 одними и теми же сборками t27b и t27c: в обеих квитанциях записан один и тот же SHA-256 для каждой.

Прогон сравнения

t27c corpus-receipt compare читает две квитанции, сообщает про каждую, подписана ли она и привязаны ли её листья к её корням, а затем сравнивает итоги, входы, вердикты и выходы. На t27b-lab, для её собственной квитанции и квитанции, скачанной с t27b-lab-2, команда напечатала:

base "a16231329d134aaaf8922cd7b65ef8890084ac77" AUTH_MISSING_NONE AUTHOR leaves-bound true
head "a16231329d134aaaf8922cd7b65ef8890084ac77" AUTH_MISSING_NONE AUTHOR leaves-bound true
totals true inputs true verdicts true outputs true: EQUIVALENT
exit=0

t27c corpus-receipt compare · two labs, two keys, one verdict

Почему важен второй подписант

Белая книга GOLDEN CHAIN (golden-chain-international#140) открывает свои правила пунктом S1: никаких главных валидаторов; власть — у протокола, а не у человека. В сети, где каждую квитанцию подписывает одна лаборатория, главный валидатор есть, что бы ни было написано в документах: если этот единственный ключ ошибается, утерян или нечестен, никто этого не заметит. Второй ключ, который на своей машине приходит к тем же корням, — самый маленький шаг прочь от этого.

MVP сети, specs/network/mvp.t27 (t27#8638), описывает следующий шаг: прогон принимается только при совпадающих квитанциях 3 подписантов из 4, а подписанта, чья квитанция расходится, штрафуют (slashing). До сих пор такое совпадение было только в модели. Это первое настоящее, 2 из 2.

Чего это не показывает

Обе лаборатории работают под одним аккаунтом Railway и у одного оператора, так что это два ключа и две машины, а не два оператора. Обе прогоняли одни и те же сборки t27b и t27c, поэтому совпадение показывает, что прогон воспроизводится на второй машине, а не что инструменты правы. И в квитанции второй лаборатории нет одноразового запроса (nonce), поэтому она показывает, что было подписано, но не когда.

Дальше: внешний оператор, который запустит тот же образ (contrib/railway/t27b-lab в gHashTag/t27) под своим аккаунтом, правило k из n, проверяемое на настоящих квитанциях, а не в модели, и привязка дайджестов квитанций к журналу прозрачности (Rekor), чтобы подписанную квитанцию нельзя было тихо подменить. Все три пункта открыты в t27#8606.

Поработаем вместе

Хотите так же проверить собственный дизайн?

Я аудирую RTL и строю независимые побитово точные модели, затем провожу результат через синтез и, когда это полезно, проверяю на плате Artix-7. Первый модуль проверки — бесплатно.

Обсудить задачуУслуга верификации