Repository navigation
Conversation
Requests to Private (TeeML) models are sealed by the 0G gateway before they reach the Router, so the Router never sets tee_verified on them, even with verify_tee: true. The page read this as "verification was not requested", which led a heavy user to report it as a bug. The check actually runs in the gateway: a failed signature blocks a non-streaming response, and ends a stream with an error event. Document that, the X-0G-E2EE / X-Provider / ZG-Res-Key headers, and the limit of independent verification for sealed responses (the provider signs hashes of the encrypted exchange). Also stop claiming every provider runs in a TEE, and fix the privacy page's Auditing bullet that pointed Private-model users at verify_tee. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
A heavy PC user reported
tee_verifiedcoming back null onglm-5.3and filed it as a P0, because the page said a missing value means "verification was not requested".That isn't what happens. Requests to Private (TeeML) models are sealed by the 0G gateway before they reach the Router, so the Router sees ciphertext and never sets
tee_verified, even withverify_tee: true(routerbackend/pkg/inference/handler.go,SealedRequestskip). The signature check runs in the gateway instead (ZG_GATEWAY_VERIFY_RESPONSES=truein0g-pc/deploy/phala/docker-compose.yml):[DONE](0g-pc/client/core/stream.go,client/openaiproxy/proxy.go).Changes:
verifiable-execution.md: new Private models section covering the above, theX-0G-E2EE/X-Provider/ZG-Res-Keyheaders, and why step 4 of independent verification doesn't apply (the provider signs hashes of the encrypted exchange); the "absent" row now lists all three causes; the intro no longer claims every provider runs in a TEE (thestandardtier signs nothing).privacy.md: the Auditing bullet pointed Private-model users atverify_tee, which gives them no verdict. It now points to the new section.Checked on mainnet today:
glm-5.3withverify_tee: true, both streaming and non-streaming, returns 200 withX-0G-E2EE: sealed,X-ProviderandZG-Res-Key, andx_0g_tracehas notee_verified.Type of Change
Testing
pnpm build#private-models,#without-the-sdk,../routing#trust-modes) resolve in the built HTML🤖 Generated with Claude Code
This change is