Первое, что я заметил: существовало доказательство, но оно ещё не было подтверждено.

Я проверял реестр после вызова инференса через OpenGradient Chat. ТЕЕ-аттестация была сгенерирована. Узел инференса отправил её в слой полных нод. Но доказательство ещё не было записано в блокчейн. Оно находилось в каком-то промежуточном состоянии.

Я предположил, что это задержка распространения по блокам. Пару секунд, возможно. Это казалось разумным.

Слишком легко.

Архитектура @OpenGradient намеренно разделяет инференс и верификацию. Пользователь получает ответ сразу — без подтверждения блока в критическом пути. Но доказательство “оседает” асинхронно: только после того, как полные ноды выполнят консенсус CometBFT и две трети валидаторов согласятся. У этого раунда консенсуса есть собственная тайминговая схема. Он не происходит мгновенно. В течение этого окна результат инференса существует. Доказательства — нет.

Пропускная способность — это не качество сервиса. Вот с этой мыслью я всё время оставался.

Цепочка зависимостей после инференса — это отдельная система. Узел инференса генерирует доказательство. Доказательство отправляется полным нодам. Полные ноды переходят в следующий раунд консенсуса. Должно согласиться две трети валидаторов. И только тогда реестр фиксирует это навсегда. Для больших ZKML-доказательств даже сами данные доказательства живут внечейн: на Walrus — как blob, и в реестр попадает лишь ссылка-идентификатор этого блоба.

То, что я пока не могу прояснить, — это размер набора валидаторов прямо сейчас. CometBFT требует согласия двух третей. Я не знаю, сколько полных нод в данный момент активно валидируют.

Если раунд консенсуса “подвисает” во время всплеска трафика и подтверждение доказательств начинает копиться, сколько невирифицированных инференсов одновременно “висит” в этом зазоре?

#OPG #opg $OPG

В чём же более крупная проблема для ИИ в ближайшие несколько лет?