feat(rotocol): proposal 0014 - raiko2 v0.2 zk digests

[smtmfft]

No description provided.

[github-actions]

🐋 DeepSeek Code Review

🔴 Critical Issues

No critical code defects found. However, the proposal’s entire security rests on the accuracy of the 12 bytes32 constants and the SP1_SHASTA_VERIFIER address. Any error will permanently enable the wrong ZK proofs or remove legitimate ones, potentially causing chain halts or proof invalidation. This is a governance-action risk, not a code bug, but it must be explicitly called out.

🟡 Warnings

1. Constant values must be independently verified.
   The four ENABLE digests must match a reproducible build of raiko2 v0.2.0 exactly. The eight DISABLE digests must match the historical registrations from Proposal0009 and Proposal0010. A single wrong bytes32 will break ZK acceptance for the new version or accidentally re‑enable a legacy program. The review cannot confirm these values without building raiko2, so a second technical reviewer must validate them against the release artifacts.

2. Calldata accuracy (Proposal0014.action.md).
   The high‑entropy calldata was checked in but not regenerated on‑chain by this review. If it was hand‑edited or generated from a different version of Proposal0014.s.sol, the DAO transaction will not execute the intended actions. Run P=0014 pnpm proposal and commit the output immediately before the governance vote.

3. SetProgramTrusted access control assumption.
   The proposal calls SP1Verifier.setProgramTrusted via the DAO Controller. It assumes the DAO Controller has the necessary permission (owner or authorized role). If the SP1 verifier’s ownership is not assigned to the controller, the entire bundle will revert. Verify on‑chain that SP1_SHASTA_VERIFIER.owner() equals the DAO Controller address used in the proposal.

🔵 Suggestions

• Constant naming inconsistency.
  SP1_PROPOSAL_VKEY_BN256 and similar use “BN256”, but the release page labels the same value as “vk_bn254”. The discrepancy is cosmetic but may cause confusion during audits. Consider aligning the suffix with BN254.

• Add a simple static check.
  Inside a test (or the BuildProposal dry‑run) decode the generated calldata and assert that the actions array matches the constants defined in the solidity file. This would catch any mismatch before submission.

• Clarify verbatim: The spec file says “(Proposal0014.s.sol L1 ZK actions 4–9)” for Proposal0009, but the actual actions are indices 4–7 in the disable block (Proposal0009 had 4 SP1 actions). The comment could be sharper to avoid confusion.

🟢 What Looks Good

• Atomic enable‑before‑disable ordering: all 12 actions execute in one DAO Execute call, with new keys trusted before the old ones are removed. This leaves no window where both sets are untrusted.
• Clean separation of concerns: only SP1 verifier is touched, no RISC0 or SGX attestations are altered. Constants are clearly marked and sourced.
• Documentation is thorough: the spec includes canonical release links, YAML‑style digests, verification gates, and post‑execution cast commands for on‑chain sanity checks.

---

Automatically triggered on PR update • model: deepseek-v4-pro

[ggonzalez94]

LGTM. Thanks!