Предложение: optional signed agent request envelope для Gonka inference
Оригинал: Proposal: optional signed agent request envelope for Gonka inference
Я думаю, что это предложение не полностью учитывает логику devshard.
Краткая история: Когда выводы были написаны непосредственно для цепочки, они даже теоретически не могли обслуживать большое количество выводов. Более того, можно было использовать только 10% реального оборудования (при текущем количестве млннод). Итак, были представлены devshards (уровень L2 для Gonka), но они в настоящее время не полностью находятся в производственном режиме, так как все еще есть нерешенные проблемы, такие как обработка cPoC, которая запланирована на следующие выпуски. Devshard создается одной учетной записью пользователя. Он помещает на условное депонирование GNK и платит комиссию за создание девшарда. И только этот разработчик аутентифицирован в текущем devshard. И это его обязанность — аутентифицировать других пользователей в своем devshard. Не должно быть в цепной логике проверки умозаключений. Devshard просто обрабатывает выводы, а затем при завершении определяет, сколько GNK следует снять с условного депонирования пользователя.
Я намерен сделать так, чтобы любые изменения и предложения по обработке устаревших выводов (не с помощью devshard) просто устарели. Мы должны разрабатывать вещи, которые будут использоваться в будущей инфраструктуре.
Понял. Переместим это на путь devshard и закроем #1232 (https://github.com/gonka-ai/gonka/pull/1232). Должен ли верификатор находиться внутри dl/devshards-gateway-to-main или в качестве вспомогательного устройства перед devshard?
Уже существует devshardctl, которым управляет разработчик, инициировавший депонирование devshard. dl/devshards-gateway-to-main — это просто ветка git
@gmorgachev (https://github.com/gmorgachev), взяв ваше предложение со стороны брокера из #1185 (https://github.com/gonka-ai/gonka/discussions/1185#discussioncomment-17004938) с конкретной схемой конверта и эталонной реализацией. Прежде чем открывать PR, я хотел бы получить информацию о размещении и объеме v1.
Предложение
Добавьте дополнительный подписанный конверт запроса агента в /v1/chat/completions и /v1/completions . Когда заголовок X-Agent-Passport отсутствует, поведение запроса идентично сегодняшнему состоянию. Конфигурация по умолчанию отключает этот слой. Конверт представляет собой аддитивные метаданные. Никакого изменения цепочки, никакого нового консенсусного сообщения.
Какой разрыв он закрывает
Gonka аутентифицирует участников сети: разработчика, агента передачи, исполнителя. MsgFinishInference записывает RequestedBy, TransferredBy, ExecutedBy. Цепочка подписи работает. Защита от повтора AuthKey работает. Делегирование горячих клавиш x/authz работает.
Более узкий разрыв — это контекст агент-субъект, когда автоматический агент вызывает Gonka от имени уже авторизованного принципала:
- Личность субпринципала невидима. RequestedBy разрешается как Разработчик или Получатель «теплой клавиши». фактический агент, совершающий вызов, не находится на проводе.
- x/authz имеет область действия типа сообщения, а не атрибута. Разработчик не может предоставить «горячему ключу» право на выполнение вывода только для модели X, только для цели Y, только до следующего вторника. Пользовательский тип InferenceAuthorization в x/authz решит эту проблему, но требует изменения цепочки.
- Нет бенефициара, отличного от плательщика. Когда агент A платит сети от имени клиента C, запись в цепочке идентифицирует A. Нет поля, в котором говорится, что работа была выполнена для C.
Что делает конверт
При наличии X-Agent-Passport верификатор проверяет, что:
- Конверт подписан ключом Cosmos secp256k1 разработчика через ADR-036 (совместимый с Keplr SignArbitrary). Основной открытый ключ встроен; верификатор получает адрес локально и утверждает равенство с основным адресом конверта. Никакого цепного запроса не требуется, что исключает поиск первого открытого ключа tx и связанную с ним поверхность DoS.
- Агент подписал конкретный запрос через Ed25519 через разделенную доменом привязку полезной нагрузки с префиксом длины, Chain_id , метод HTTP, полный URI запроса, канонизированный JCS-конверт и тело запроса.
- Срок действия конверта не истек, он не старше MaxEnvelopeTTL (по умолчанию 1 час, настраивается) и попадает в категорию not_before, если он присутствует.
- Если разрешенные_модели присутствуют, запрошенная модель должна быть указана. Если этот параметр опущен, конверт не ограничивает выбор модели.
- Основной адрес соответствует RequesterAddress или x/authz показывает активное отношение получателя к грантодателю для /inference.inference.MsgStartInference.
После успешного выполнения s.recorder.StartInference событие структурированной атрибуции генерируется асинхронно через ограниченную очередь. Капле-на-поле со счетчиком; никогда не блокирует путь запроса.
Композиция с существующими примитивами
Это соответствует существующим шаблонам Cosmos и не добавляет нового корня доверия:
- ADR-036 для подписи разработчика с произвольными данными в паспорте, тот же путь, который создает KeplrsignArbitrary.
- x/authz для разрешения горячих клавиш, когда запрос поступает от Грантополучателя, отличного от принципала. Использует существующий AuthzCache.GetPubKeyForSigner от Gonka напрямую.
- Ed25519 из стандартной библиотеки Go для подписи агента для каждого запроса.
- RFC 8785 JCS для канонизации, реализованный в схеме конверта. Числа и суррогатные регистры Юникода выходят за рамки; в схеме нет номеров JSON, а неизвестные поля отклоняются.
Конверт представляет собой расширение уровня запросов вне цепочки. Не консенсусное сообщение. Не цепное послание. Не новый уровень идентификации под ключом разработчика.
Почему уровень запросов в первую очередь
Версия для цепочки может в конечном итоге добавить необязательные поля AgentId и Beneficiary в MsgFinishInference , но это отдельная дискуссия по управлению. Для версии 1 промежуточное ПО на стороне брокера выглядит более безопасной отправной точкой:
никакого изменения консенсуса
нет нового цепного сообщения
никаких изменений в существующей аутентификации запроса
простая подписка и легкий откат
четкое место для тестирования схемы, прежде чем предлагать что-либо в цепочке
Если вы видите другое размещение, которое закрывает пробел с меньшей площадью поверхности, я бы предпочел услышать об этом сейчас, чем после того, как PR будет установлен.
Что остается неизменным
Явное перечисление поверхностных проблем, потому что именно на них естественным образом направляется внимание рецензента на любом предложении в конверте. Этот PR НЕ изменяет:
Подпись разработчика на AuthKey, защита от повтора AuthKey, вычисления.ValidateTimestamp или checkAndRecordAuthKey
Подписание агента по передаче или подписание исполнителя
- Схемы MsgStartInference или MsgFinishInference.
Эскроу, расчет, ценообразование, токеномика
Консенсус, обработчики ante, узел ML, PoC, проверка
Существующие брокеры, шлюзы или их семантика пересылки
Конфигурация по умолчанию включена: false. Операторы соглашаются.
Что может произойти позже
Стоит отметить одно направление Фазы 2: расширение MsgFinishInference с помощью дополнительных полей AgentId и Beneficiary, чтобы данные, которые конверт переносит за пределы цепочки в v1, стали доступными для запроса в цепочке. Это цепное изменение, требующее управления, и это не предполагается в настоящем PR. Если интерес есть, то это отдельное обсуждение.
Другие элементы, явно отложенные на этап 2: цепочки делегирования с ограниченной областью, квитанции об атрибуции с несколькими переходами, поддержка принципалов с несколькими подписями, интеграция демона devshard и отзыв за пределами короткого TTL. @a-kuprin (https://github.com/a-kuprin), часть аутентификации devshard, которую вы подняли в # 1185 (https://github.com/gonka-ai/gonka/discussions/1185), подпадает здесь под интеграцию демона devshard; Я думаю, что после того, как версия 1 будет урегулирована, потребуется отдельное обсуждение.
То, о чем я прошу
Две вещи перед открытием PR:
- Проверка размещения. Промежуточное программное обеспечение уровня запросов на стороне брокера в /v1/chat/completions и /v1/completions соответствует вашему предложению [Общественное рассмотрение] Дорожная карта развития сети Gonka № 1185 (https://github.com/gonka-ai/gonka/discussions/1185). Подтвердите или перенаправьте.
- Проверка объема. Является ли схема конверта (идентификатор субпринципала, область атрибутов и бенефициар, все необязательно и подписано существующим ключом разработчика) подходящей поверхностью v1 или предпочтительнее более узкая отправная точка?
Эталонная реализация готова: один PR, один новый пакет Internal/agentenvelope/, ~25 измененных строк в двух существующих файлах, включение через конфигурацию, обратная совместимость по конструкции. Я могу вскоре открыть его как связанный PR, но приведенные выше моменты дизайна составляют суть обсуждения. Код может подождать подтверждения размещения, если это более чистая последовательность.
Раскрытие информации
Я поддерживаю APS (систему паспортов агентов), открытый протокол Apache 2.0 для идентификации агентов ИИ. Формат конверта здесь APS-совместим. Интеграция полностью изолирована во внутреннем/agentenvelope/ , поэтому формат передачи можно менять без изменения архитектуры чего-либо еще. Принятие его на стороне Gonka не требует от Gonka внедрения APS во всей сети.
Связанный PR: #1232 (https://github.com/gonka-ai/gonka/pull/1232) — эталонная реализация, соответствующая приведенным выше пунктам дизайна.
Я думаю, что это предложение не полностью учитывает логику devshard.
Краткая история: Когда выводы были написаны непосредственно для цепочки, они даже теоретически не могли обслуживать большое количество выводов. Более того, можно было использовать только 10% реального оборудования (при текущем количестве млннод). Итак, были представлены devshards (уровень L2 для Gonka), но они в настоящее время не полностью находятся в производственном режиме, так как все еще есть нерешенные проблемы, такие как обработка cPoC, которая запланирована на следующие выпуски. Devshard создается одной учетной записью пользователя. Он помещает на условное депонирование GNK и платит комиссию за создание девшарда. И только этот разработчик аутентифицирован в текущем devshard. И это его обязанность — аутентифицировать других пользователей в своем devshard. Не должно быть в цепной логике проверки умозаключений. Devshard просто обрабатывает выводы, а затем при завершении определяет, сколько GNK следует снять с условного депонирования пользователя.
Я намерен сделать так, чтобы любые изменения и предложения по обработке устаревших выводов (не с помощью devshard) просто устарели. Мы должны разрабатывать вещи, которые будут использоваться в будущей инфраструктуре.
Понял. Переместим это на путь devshard и закроем #1232 (https://github.com/gonka-ai/gonka/pull/1232). Должен ли верификатор находиться внутри dl/devshards-gateway-to-main или в качестве вспомогательного устройства перед devshard?
Уже существует devshardctl, которым управляет разработчик, инициировавший депонирование devshard. dl/devshards-gateway-to-main — это просто ветка git
@gmorgachev (https://github.com/gmorgachev) , picking up your broker-side suggestion from #1185 (https://github.com/gonka-ai/gonka/discussions/1185#discussioncomment-17004938) with a concrete envelope schema and a reference implementation. I'd like input on placement and v1 scope before opening the PR.
Proposal
Add an optional signed agent request envelope on /v1/chat/completions and /v1/completions . When the X-Agent-Passport header is absent, request behavior is byte-identical to today. Default config disables the layer. The envelope is additive metadata. No chain change, no new consensus message.
What gap does it close
Gonka authenticates the network actors: Developer, Transfer Agent, Executor. MsgFinishInference records RequestedBy , TransferredBy , ExecutedBy . The signature chain works. AuthKey replay protection works. x/authz warm-key delegation works.
The narrower gap is agent-subject context when an automated agent calls Gonka under an already-authorized principal:
- Sub-principal identity is invisible. RequestedBy resolves to the Developer or warm-key Grantee; the actual agent making the call is not on the wire.
- x/authz is message-type scoped, not attribute scoped. A Developer cannot grant a warm key the right to run inference only for model X, only for purpose Y, only until next Tuesday. A custom InferenceAuthorization type in x/authz would address this but requires a chain change.
- No beneficiary distinct from payer. When agent A pays the network on behalf of customer C, the on-chain record identifies A. There is no field that says the work was done for C.
What the envelope does
When X-Agent-Passport is present, the verifier checks that:
- The envelope is signed by the Developer's Cosmos secp256k1 key via ADR-036 (Keplr signArbitrary compatible). The principal pubkey is embedded; the verifier derives the address locally and asserts equality with the envelope's principal address. No chain query needed, which eliminates the first-tx-pubkey lookup and the associated DoS surface.
- The agent signed the specific request via Ed25519 over a domain-separated, length-prefixed payload binding chain_id , HTTP method, full request URI, the JCS-canonicalized envelope, and the request body.
- The envelope is not expired, not older than MaxEnvelopeTTL (default 1h, configurable), and falls within not_before if present.
- If allowed_models is present, the requested model must be listed. If omitted, the envelope does not restrict model choice.
- The principal address matches RequesterAddress , or x/authz shows an active Grantee to Granter relationship for /inference.inference.MsgStartInference .
After s.recorder.StartInference succeeds, a structured attribution event is emitted asynchronously through a bounded queue. Drop-on-full with a counter; never blocks the request path.
Composition with existing primitives
This follows existing Cosmos patterns and adds no new root of trust:
- ADR-036 for the Developer's arbitrary-data signature on the passport, the same path Keplr signArbitrary produces.
- x/authz for warm-key resolution when the request comes from a Grantee distinct from the principal. Uses Gonka's existing AuthzCache.GetPubKeyForSigner directly.
- Ed25519 from the Go standard library for the agent's per-request signature.
- RFC 8785 JCS for canonicalization, vendored to the envelope schema. Numbers and Unicode surrogate cases are out of scope; the schema has no JSON numbers and unknown fields are rejected.
The envelope is an off-chain request-layer extension. Not a consensus message. Not a chain message. Not a new identity layer underneath the Developer key.
Why request-layer first
A chain-native version could eventually add optional AgentId and Beneficiary fields to MsgFinishInference , but that's a separate governance discussion. For v1, broker-side middleware looks like the safer starting point:
no consensus change
no new chain message
no change to existing request authentication
easy opt-in and easy rollback
clear place to test the schema before proposing anything on-chain
If you see a different placement that closes the gap with less surface area, I'd rather hear it now than after the PR is up.
What stays unchanged
Listing the surface concerns explicitly because that's where reviewer attention naturally goes on any envelope proposal. This PR does NOT modify:
Developer signature on AuthKey, AuthKey replay protection, calculations.ValidateTimestamp , or checkAndRecordAuthKey
Transfer Agent signing or Executor signing
MsgStartInference or MsgFinishInference schemas
Escrow, settlement, pricing, tokenomics
Consensus, ante handlers, ML node, PoC, validation
Existing brokers, gateways, or their forwarding semantics
Default config is enabled: false . Operators opt in.
What might come later
One Phase 2 direction worth flagging: extending MsgFinishInference with optional AgentId and Beneficiary fields so the data the envelope carries off-chain in v1 becomes queryable on-chain. That's a chain change requiring governance and is not assumed by this PR. If interest exists, it gets a separate Discussion.
Other items explicitly deferred to Phase 2: scoped delegation chains, multi-hop attribution receipts, multi-sig principal support, devshard daemon integration, and revocation beyond short TTL. @a-kuprin (https://github.com/a-kuprin) , the devshard authentication piece you raised in #1185 (https://github.com/gonka-ai/gonka/discussions/1185) falls under devshard daemon integration here; I think that wants its own Discussion once v1 settles.
What I'm asking for
Two things before opening the PR:
- Placement check. Broker-side request-layer middleware on /v1/chat/completions and /v1/completions matches your [Public Review] Gonka Network Development Roadmap #1185 (https://github.com/gonka-ai/gonka/discussions/1185) suggestion. Confirm or redirect.
- Scope check. Is the envelope schema (sub-principal identity, attribute scope, and beneficiary, all optional and signed by the existing Developer key) the right v1 surface, or is there a narrower starting point preferred?
The reference implementation is ready: single PR, single new package internal/agentenvelope/ , ~25 modified lines across two existing files, opt-in via config, backward compatible by construction. I can open it as a linked PR shortly, but the design points above are the substance of the Discussion. Code can wait on placement confirmation if that's the cleaner sequence.
Disclosure
I maintain APS (Agent Passport System), an Apache 2.0 open protocol for AI agent identity. The envelope format here is APS-compatible. The integration is fully isolated in internal/agentenvelope/ , so the wire format can be swapped without re-architecting anything else. Adopting it Gonka-side does not require Gonka to adopt APS network-wide.
Linked PR: #1232 (https://github.com/gonka-ai/gonka/pull/1232) — reference implementation matching the design points above.
I think the proposal doesn't completely take into account devshard logic.
Short story : When inferences was written directly to chain it even theoretically cannot serve large amount of inferences. Moreover only 10% of real hardware could be utilized (at current number of mlnodes). So devshards was introduced (L2 layer for Gonka), but they are not currently fully in production mode, as there are still unsolved problems, like handling cPoC, that is scheduled to next releases. Devshard is created by one user account. He puts the escrow GNK and pays fee for devshard creation. And only this developer is authenticated to current devshard. And this is his responsibility to authenticate other users to his devshard. It shouldn't be in chain logic to check inferences. Devshard just processes inferences and then on finalization provides to chain how many GNK shouyld be taken from users escrow balance.
My intention is that any changes and proposals for legacy inference handling (not with devshard) are just out of date. We should design things that will feat future infrastructure.
Got it. Moving this to the devshard path and closing #1232 (https://github.com/gonka-ai/gonka/pull/1232) . Should the verifier live inside dl/devshards-gateway-to-main, or as a sidecar in front of the devshard?
There is already devshardctl that is runned by dev who initiated devshard escrow. dl/devshards-gateway-to-main - is just a git branch
@gmorgachev (https://github.com/gmorgachev), взяв ваше предложение со стороны брокера из #1185 (https://github.com/gonka-ai/gonka/discussions/1185#discussioncomment-17004938) с конкретной схемой конверта и эталонной реализацией. Прежде чем открывать PR, я хотел бы получить информацию о размещении и объеме v1.
Предложение
Добавьте дополнительный подписанный конверт запроса агента в /v1/chat/completions и /v1/completions . Когда заголовок X-Agent-Passport отсутствует, поведение запроса идентично сегодняшнему состоянию. Конфигурация по умолчанию отключает этот слой. Конверт представляет собой аддитивные метаданные. Никакого изменения цепочки, никакого нового консенсусного сообщения.
Какой разрыв он закрывает
Gonka аутентифицирует участников сети: разработчика, агента передачи, исполнителя. MsgFinishInference записывает RequestedBy, TransferredBy, ExecutedBy. Цепочка подписи работает. Защита от повтора AuthKey работает. Делегирование горячих клавиш x/authz работает.
Более узкий разрыв — это контекст агент-субъект, когда автоматический агент вызывает Gonka от имени уже авторизованного принципала:
Что делает конверт
При наличии X-Agent-Passport верификатор проверяет, что:
После успешного выполнения s.recorder.StartInference событие структурированной атрибуции генерируется асинхронно через ограниченную очередь. Капле-на-поле со счетчиком; никогда не блокирует путь запроса.
Композиция с существующими примитивами
Это соответствует существующим шаблонам Cosmos и не добавляет нового корня доверия:
Конверт представляет собой расширение уровня запросов вне цепочки. Не консенсусное сообщение. Не цепное послание. Не новый уровень идентификации под ключом разработчика.
Почему уровень запросов в первую очередь
Версия для цепочки может в конечном итоге добавить необязательные поля AgentId и Beneficiary в MsgFinishInference , но это отдельная дискуссия по управлению. Для версии 1 промежуточное ПО на стороне брокера выглядит более безопасной отправной точкой:
никакого изменения консенсуса
нет нового цепного сообщения
никаких изменений в существующей аутентификации запроса
простая подписка и легкий откат
четкое место для тестирования схемы, прежде чем предлагать что-либо в цепочке
Если вы видите другое размещение, которое закрывает пробел с меньшей площадью поверхности, я бы предпочел услышать об этом сейчас, чем после того, как PR будет установлен.
Что остается неизменным
Явное перечисление поверхностных проблем, потому что именно на них естественным образом направляется внимание рецензента на любом предложении в конверте. Этот PR НЕ изменяет:
Подпись разработчика на AuthKey, защита от повтора AuthKey, вычисления.ValidateTimestamp или checkAndRecordAuthKey
Подписание агента по передаче или подписание исполнителя
Эскроу, расчет, ценообразование, токеномика
Консенсус, обработчики ante, узел ML, PoC, проверка
Существующие брокеры, шлюзы или их семантика пересылки
Конфигурация по умолчанию включена: false. Операторы соглашаются.
Что может произойти позже
Стоит отметить одно направление Фазы 2: расширение MsgFinishInference с помощью дополнительных полей AgentId и Beneficiary, чтобы данные, которые конверт переносит за пределы цепочки в v1, стали доступными для запроса в цепочке. Это цепное изменение, требующее управления, и это не предполагается в настоящем PR. Если интерес есть, то это отдельное обсуждение.
Другие элементы, явно отложенные на этап 2: цепочки делегирования с ограниченной областью, квитанции об атрибуции с несколькими переходами, поддержка принципалов с несколькими подписями, интеграция демона devshard и отзыв за пределами короткого TTL. @a-kuprin (https://github.com/a-kuprin), часть аутентификации devshard, которую вы подняли в # 1185 (https://github.com/gonka-ai/gonka/discussions/1185), подпадает здесь под интеграцию демона devshard; Я думаю, что после того, как версия 1 будет урегулирована, потребуется отдельное обсуждение.
То, о чем я прошу
Две вещи перед открытием PR:
Эталонная реализация готова: один PR, один новый пакет Internal/agentenvelope/, ~25 измененных строк в двух существующих файлах, включение через конфигурацию, обратная совместимость по конструкции. Я могу вскоре открыть его как связанный PR, но приведенные выше моменты дизайна составляют суть обсуждения. Код может подождать подтверждения размещения, если это более чистая последовательность.
Раскрытие информации
Я поддерживаю APS (систему паспортов агентов), открытый протокол Apache 2.0 для идентификации агентов ИИ. Формат конверта здесь APS-совместим. Интеграция полностью изолирована во внутреннем/agentenvelope/ , поэтому формат передачи можно менять без изменения архитектуры чего-либо еще. Принятие его на стороне Gonka не требует от Gonka внедрения APS во всей сети.
Связанный PR: #1232 (https://github.com/gonka-ai/gonka/pull/1232) — эталонная реализация, соответствующая приведенным выше пунктам дизайна.