Add tests that validate the cross-circuit chaining behavior: (1) a valid chain of proofs still passes all checks, and (2) tampering with a commitment across circuits causes the verifier to mark the sender dishonest and emit the expected failure events.
Tasks:
- Positive: Integration or unit test that runs a full (or minimal) flow where C0→C3, C3→C4, C4→C6, and C1→C5 are all consistent; assert no party is marked dishonest and verification completes.
- Negative (C0→C3): Provide a C3 proof whose
expected_pk_commitment does not match the receiver’s C0; assert the sender is marked dishonest and the failure event references the C3 proof.
- Negative (C4→C6): Provide valid C4 proofs, then a C6 proof with wrong
expected_sk_commitment or expected_e_sm_commitment; assert the sender is marked dishonest and the failure references the C6 proof.
- Negative (C1→C5): If feasible in the test setup, provide a C5 proof built with a wrong pk commitment; assert the aggregator does not accept it (or equivalent).
- Ensure existing tests (e.g.
crates/zk-prover/tests/local_e2e_tests.rs, slashing/integration tests) still pass.
Acceptance criteria:
- At least one positive and two negative tests as above; CI green.
- Tests are stable and do not depend on flaky timing or external services where avoidable.
Add tests that validate the cross-circuit chaining behavior: (1) a valid chain of proofs still passes all checks, and (2) tampering with a commitment across circuits causes the verifier to mark the sender dishonest and emit the expected failure events.
Tasks:
expected_pk_commitmentdoes not match the receiver’s C0; assert the sender is marked dishonest and the failure event references the C3 proof.expected_sk_commitmentorexpected_e_sm_commitment; assert the sender is marked dishonest and the failure references the C6 proof.crates/zk-prover/tests/local_e2e_tests.rs, slashing/integration tests) still pass.Acceptance criteria: