docs: plan to upgrade Aggregation Mode to SP1 v6 and use Succinct's Hoodi gateway

[JuArce]

Summary

Adds docs/0_internal/sp1_v6_upgrade_plan.md, the plan for two related changes. This PR contains no code changes; the implementation will follow in separate PRs.

1. Hoodi: switch AlignedProofAggregationService.sp1VerifierAddress from our own SP1 gateway (0xe1D19B93…e9ef) to Succinct's Hoodi Groth16 gateway (0x7DA83eC4af493081500Ecd36d1a72c23F8fc2abd).
2. Upgrade Aggregation Mode to SP1 6.8.1 (circuit v6.1.0): Hoodi first, then mainnet via the Safe (5/8).

Why

On 2026-10-09 06:13 UTC, Succinct froze the v5.0.0 (0xa4594c59) and v6.0.0 (0x0e78f4db) Groth16 routes on its gateways (freeze tx). Our aggregator produces v5.0.0 Groth16 proofs, so verifyAggregationSP1 on mainnet (0xD0696d3e…8BC0) now reverts with RouteIsFrozen. The only active route is v6.1.0 (0x4388a21c), which is what sp1-sdk 6.8.1 targets.

What the plan covers

• Code (Part A):
  • sp1-sdk/zkvm/build bump to 6.8.1 and the async SDK API migration
  • v6 sp1-patches tags; a pinned Docker build tag so VKs are reproducible
  • regenerated program VKs
  • sp1-contracts bump to v6.1.1
  • owner-ops Makefile targets with a MULTISIG calldata mode
  • a new failed task status for queued v5 proofs that can no longer be aggregated
  • v6 fixtures, CI/infra sp1up pins, and docs
• Hoodi rollout (Part B): EOA owner, so direct cast send:
  • setSP1VerifierAddress
  • allowVerifyingProgram(NEW_VK, 1)
  • disallowVerifyingProgram(old VK, 1)
• Mainnet rollout (Part C):
  • a single Safe batch (allowVerifyingProgram + disallowVerifyingProgram); no setSP1VerifierAddress and no contract upgrade needed
  • an independent VK reproduction step before signing
  • a mainnet-fork rehearsal before signing that reuses the Hoodi proof
• Verification steps and the out-of-scope items. The deprecated Verification Layer stays on v5.

Breaking change for users

v6 guests cannot verify v5 proofs, so SP1 users must re-prove with sp1-sdk ≥ 6.1.0 and upgrade agg_mode_sdk. v5 tasks queued before the cutover will be marked failed.

🤖 Generated with Claude Code

[claude]

Review: this PR only adds an internal plan doc, so there is no executable code to check for security issues. No blocking problems found.

Notes on the plan:

• Low: the TryFrom<u16> mapping bug in aggregation_mode/sdk/src/blockchain/types.rs:71-81 is listed as 'noticed but not fixed'. Since it mixes up SP1 and RISC0, open a tracking issue or fix it in the same PR.
• Low: the mainnet Safe batch disallows the old VK before the cutover. That is safe only because the v5 route is already frozen. The fork rehearsal (C.2) should check that this ordering has no side effects. It should also check that verifyAggregationSP1 with NEW_VK succeeds on the fork before any signing.
• Low: mark_sp1_v5_tasks_failed.sql filters on inserted_at < :cutover_ts. Run it only after the gateway no longer accepts v5 proofs, or v5 tasks inserted between deploy and the run could be missed. The plan's step order already does this, so keep it that way.

🤖 Generated with Claude Code

[github-actions]

Codex Code Review

• Medium — Cutover can permanently fail valid v6 submissions. sp1_v6_upgrade_plan.md:122 records CUTOVER_TS after the gateway deployment finishes, while the cleanup SQL fails every pending/processing SP1 task inserted before that timestamp. The new gateway can accept valid v6 proofs before deployment finishes, so those tasks will also become terminally failed. Pause submissions and drain in-flight requests before recording the boundary, then deploy, clean up, and reopen submissions; alternatively, identify v5 tasks by proof version rather than insertion time. Apply the same fix to the mainnet cutover.