feat(tri): L-TRI-3 W2 — V2 integration in POST /prove + Solana (Closes #607)#608
Open
gHashTag wants to merge 2 commits into
Open
feat(tri): L-TRI-3 W2 — V2 integration in POST /prove + Solana (Closes #607)#608gHashTag wants to merge 2 commits into
gHashTag wants to merge 2 commits into
Conversation
Adds `version: u8` field to ProveRequest (serde default = 1). Handler dispatches on version: - v1: 4-byte gf16_dot4 response (unchanged) - v2: 32-byte SHA256(pack(CHAMPION_WEIGHTS * derive_v2(epoch,node))) V1 clients keep working without code change (additive change). Ed25519 signature domain separator switches to TRI_PROVE_V2 for v2. For v2, next_challenge is the packed 128-byte (256 hex) matrix. Tests (cli/tri): - test_v2_e2e_valid_proof — full 16x16 matmul roundtrip via HTTP - test_v2_e2e_invalid_response_flipped_bit — single-bit flip rejected - test_v2_e2e_wrong_response_length — 4-byte response on v2 rejected - test_v2_e2e_unsupported_version — version != 1|2 rejected - test_v2_kat_pinned_response — pinned (epoch=42, node=[1..32]) KAT Result: tri 30/30 (was 25/25 + 5 new v2). Closes #607
Adds new instruction submit_proof_v2(phi_response: [u8; 32], ...) that runs the V2 verification fully on-chain: 1. derive_phi_challenge_v2(epoch, miner.key) → 16x16 GF(2^4) matrix 2. gf16_matmul_v2(CHAMPION_WEIGHTS, challenge) → 16x16 product 3. SHA256(pack_gf16_matrix(product)) → 32-byte expected response 4. constant-time compare with submitted phi_response Existing submit_proof (V1) instruction left untouched — no IDL break, existing clients keep working. New account NodeProofV2 (separate PDA seed "proof_v2") and new event ProofSubmittedV2. Polynomial 0x3 (x^4 + x + 1), CHAMPION_WEIGHTS, and pack order are verified identical to cli/tri reference impl via cross-impl KAT tests. Tests (tri-mining lib, native host build): - test_onchain_v2_response_deterministic - test_onchain_v2_wrong_epoch_differs - test_onchain_v2_wrong_node_differs - test_onchain_v2_pinned_kat — pinned (epoch=42, node=[1..32]) - test_onchain_v2_champion_first_row_matches_cli_tri — parity row 0 - test_onchain_v2_gf16_mul_matches_cli_tri — parity 4 mul KATs TS Anchor test (contrib/solana/tests/tri-mining.ts) adds: - "V2: node submits valid SHA256 response and earns tokens" - "V2: rejects invalid SHA256 response (flipped bit)" Anchor test requires solana-test-validator (not run in CI sandbox); host-side Rust tests provide ground-truth parity. Result: tri-mining lib 7/7 (was 1/1 + 6 new v2 including 2 parity). Closes #607
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
This was referenced May 14, 2026
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
L-TRI-3 Week 2: wires the V2 GF16 matmul module (landed Week 1,
cf951b2c) into the live entry points.cli/tri): accepts V1 (4-byte) and V2 (32-byte SHA256) responses; dispatches on newversion: u8field (default 1).contrib/solana/programs/tri-mining): newsubmit_proof_v2instruction performs the full V2 verification fully on-chain (derive 16×16 challenge → GF(2⁴) matmul againstCHAMPION_WEIGHTS→ SHA256 packed product → constant-time compare).Both changes are purely additive. V1 clients keep working without code change; existing IDL methods untouched.
V2 spec (recap)
x⁴ + x + 1(0x3)SHA256("TRI_PHI_CHALLENGE_V2" || epoch_le8 || node_id || row_byte)× 16 rows; high nibble of bytes 0..32 → 16×16 matrixSHA256(pack_gf16_matrix(CHAMPION_WEIGHTS × challenge))— 32 bytes (2^256 security; random-guess prob ≤ 2^−64 after birthday)Test results
cargo test -p tricargo test --lib(tri-mining, native host)tri-mining.ts)solana-test-validator, not run in sandbox)Cross-impl parity verified between
cli/triandtri-mining(Solana program) via:test_onchain_v2_champion_first_row_matches_cli_tri— first row ofCHAMPION_WEIGHTStest_onchain_v2_gf16_mul_matches_cli_tri—gf16_mul(0x3,0x7)=0x9,gf16_mul(0xF,0xF)=0xA,gf16_mul(0x0,0xA)=0x0,gf16_mul(0x1,0xB)=0xBcargo checkfor the Solana program: ✅ exit 0 (onlycfg(feature="anchor-debug")warnings from the macro, no errors).cargo build-sbfnot run — toolchain not present in sandbox.anchor testnot run for the same reason; the on-chain GF(2⁴) matmul + SHA256 path is covered by host-side Rust unit tests.Files changed
Compliance checklist
Closes #607.shor.pyunsafeoutsiderusb(none added)unwrap()in handler — all conversions via match/?patterns, helpererr()for early returns--no-verifycli/dlc10/,fpga/,.github/workflows/vivado-build.yml— untouchedTest plan
cargo test -p tri→ expect 30/30cargo test -p tri-mining --lib→ expect 7/7anchor teston a machine withsolana-test-validator+ Anchor CLI installedcargo build-sbf(oranchor build) to produce the deployable program and confirm CU budget is sufficient for full 16×16 GF(2⁴) matmul (~4096gf16_mulcalls per instruction)Notes for the user
cargo-build-sbfnot installed), so the on-chain BPF build wasn't validated. Nativecargo checkand host-side Rust unit tests pass; the only thing left to verify is CU budget when deployed.643892c6,0fa1cb7f,cf951b2c) are onorigin/main; this PR targetsmainper the user's Option-A decision.🤖 Generated with Claude Code