Controlled v0 launch lanes and secure compute intake#270
Merged
Conversation
a1ef2a3 to
93f3c4c
Compare
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.
Summary
Adds a controlled Cathedral v0 launch path across three lanes:
This PR intentionally separates two launch profiles:
controlled-v0: launchable at 91/100 with real secure-compute proof gates deferred. Secure Compute is intake/waitlist/operator-gated only.full: not ready until a real TEE GPU machine completes verifier acceptance plus bad-evidence rejection, provider listing, health, and usage/revenue receipts.Important boundary
Do not ask miners broadly to buy or rent hardware from this PR alone.
The controlled v0 can launch without the real GPU proof loop only because the missing gates are explicit and deferred:
compute_real_verifier_testedcompute_provider_listing_verifiedcompute_health_and_revenue_verifiedThe miner-facing announcement says Secure Compute is controlled only and that miners should not buy/rent compute unless Cathedral publishes an exact accepted profile and opens the lane.
Main changes
scaffold/launch_readiness.pypluslaunch_readiness_report.pyandlaunch_readiness_verify.py.CATHEDRAL_TEE_GPU_REAL_VERIFIER_DIGESTS; fixture verifier receipts do not count as production launch evidence unless the command digest is allowlisted.capacity.jsoninto the TEE/GPU verifier and requiresgpu_claims_matchor equivalent GPU model/count checks.eval_runs,lane_challenge_solves,per_miner_solves, and emissions.row_score_recentwith an explicit task-type allowlist and visible proportional fallback metadata.Claude review
Claude reviewed the branch for launch blockers and found no critical/high/medium issues. Four low hardening notes were addressed:
Validation
Passed locally:
python3 launch_readiness_verify.py— 19 checkspython3 launch_readiness_report.py --profile controlled-v0 --require-ready— READY, 91/100, three compute gates deferredpython3 launch_readiness_report.py --require-ready— expected nonzero, full profile NOT READY at 91/100python3 weights_verify.py— 16 checkspython3 tee_gpu_verify.pypython3 attest_verify.pypython3 audit_arena_verify.py— 27 checkspython3 distillation_verify.py— 15 checkspython3 arena_runner_verify.py— 8 checkspython3 rc_verify.py— 37 checks, one expected skip for missing real solverpython3 -m py_compile scaffold/publisher/app.py scaffold/publisher/attest.py scaffold/publisher/tee_gpu.py scaffold/publisher/weights.py scaffold/launch_readiness.py scaffold/distillation.py scaffold/lanes/audit_arena.py launch_readiness_report.pygit diff --checkAttempted but environment-blocked:
python3 publisher_verify.pyfails becausebittensor_walletis not installed in this local WSL runtime.python3 postgres_verify.pyrequires a realDATABASE_URL.Operator launch command
Controlled v0 readiness:
Full hardware launch readiness:
Hardening update after Claude review loop
Additional Claude review passes found and the branch now fixes:
row_score_recentnow only consumesattested=1rows and preserves coldkey-collapse splitting./v1/attest/noncefails closed on missing/emptyminer_pubkey_b64.node_idplus payload digest; unbound fallback shapes are not accepted for mutating compute intake.cryptographically_verified.{0}, return structured 400s.OSErrorpaths become structuredlist_failedevents instead of unhandled 500s.listingclaim, and stale claims can only be reclaimed after provider CLI timeout plus margin.sat,audit,pm) so arbitrary ids containing-t2-do not change emissions.Latest validation after hardening:
python3 tee_gpu_verify.pypython3 weights_verify.py— 18 checkspython3 attest_verify.pypython3 launch_readiness_verify.py— 19 checkspython3 launch_readiness_report.py --profile controlled-v0 --require-ready— READY, 91/100python3 launch_readiness_report.py --require-ready— expected failure, full profile NOT READYpython3 audit_arena_verify.py— 27 checkspython3 distillation_verify.py— 15 checkspython3 arena_runner_verify.py— 8 checkspython3 rc_verify.py— 37 checks, one expected real-solver skippython3 -m py_compile ...git diff --checkDashboard wording update
The operator dashboard copy now mirrors the stricter code gate: Cathedral preflights capacity, requires cryptographic TEE/GPU evidence, and only then emits provider handoff commands. Blocked, non-consented, or unverified rows are explicitly described as commandless.
Additional validation:
python3 tee_gpu_verify.pypython3 -m py_compile scaffold/publisher/tee_gpu.pypython3 launch_readiness_report.py --profile controlled-v0 --require-readygit diff --checkNo-hardware launch update
Latest commits add the explicit
no-hardware-v0/intake-v0readiness path. It aliases tocontrolled-v0: Audit Arena and distillation can launch, while Secure Compute remains intake/waitlist/operator-gated until real verifier/provider/health/revenue evidence exists.CI hardening added in this update:
httpx2>=2is now included in the publisher extra for FastAPI/Starlette TestClient compatibility.publisher_verify.pynow starts tuple-cursor pagination from an explicit old cursor instead of asking the feed for newest-first rows.postgres_verify.pynow asserts provider listing is blocked before cryptographic evidence, then verifies the successful crypto-evidenced dry-run path on Postgres.Current GitHub Actions status on
da20f44:launch-readiness / verifypassed on the PR run.launch-readiness / verifypassed on the branch push run.Required-checks update
The branch now includes
.github/workflows/required-checks.ymlso the repo ruleset-required contexts exist and run on PRs:CodeQLAnalyze Pythonleak-guardCurrent merge state on
6a5553a:MERGEABLE/CLEAN; all required checks and launch-readiness checks pass.Claude review loop update
Claude reviewed the current branch for no-hardware-v0 launch blockers. It raised one high concern that provider execution might run without cryptographic evidence. The cited path was rechecked against the code:
list_capacity_on_chutes()starts with blockers fromchutes_manifest_item(), andchutes_manifest_item()already addscryptographic_attestation_requiredunless evidence iscryptographically_verified.Follow-up changes from the review:
tee_gpu_verify.pyto prove thatexecute=Trueremains blocked without cryptographic evidence even whenCATHEDRAL_TEE_GPU_CHUTES_EXECUTE_ENABLED=1is set.Current status on
a1ef2a3:launch-readiness / verifypassed.CodeQLpassed.Analyze Pythonpassed.leak-guardpassed.