refactor(testing): type proof_setting as an IntEnum and fix its derivation - #907
Merged
tcoratger merged 1 commit intoJun 10, 2026
Merged
Conversation
…ation proof_setting was a bare int (0 mocked / 1 real-verify / 2 real-fail) whose meaning lived only in a re-explaining inline comment block at the one place it was assigned. Introduce a self-documenting ProofSetting IntEnum, where each member carries its own meaning, and retype the fixture field to it. The enum serializes to the same integer, so emitted vectors are unchanged. Fix the derivation bug: proof_setting was set to 2 (real proof must fail verification) for any vector carrying an expected rejection, even when the rejection was non-crypto (for example an unknown parent) and the proof was perfectly valid. Only a rejection whose direct cause is the proof failing verification (INVALID_SIGNATURE or INVALID_BLOCK_PROOF) now maps to REAL_AND_INVALID; every other rejection keeps its valid proof and maps to REAL_AND_VALID. The default mocked lane is unaffected (every vector is MOCKED), so generated vectors do not churn; only the real-crypto authoritative set is corrected. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
Motivation
The emitted
proof_settingfield was a bareintwith three magic values, documented only by a re-explaining inline comment block at the single place it was assigned:Two problems:
proof_settingwas set to2("real proof must fail verification") for any vector carrying an expected rejection, even when the rejection is non-crypto (e.g. an unknown parent, a slot mismatch) and the proof is perfectly valid. A client that verifies such a proof (and it passes) then rejects for the real reason is behaving correctly, yet contradictsproof_setting=2.What this does
Self-documenting
IntEnum. Each member carries its own meaning:The fixture field is retyped to
ProofSetting. Because it is anIntEnum, it serializes to the same integer (0/1/2) — emitted vectors are byte-identical — andProofSetting.MOCKED == 0still holds for any consumer comparing against integers.Fixed derivation.
REAL_AND_INVALIDis now reserved for rejections whose direct cause is the proof failing verification:Every other rejection keeps its valid proof and maps to
REAL_AND_VALID.The default mocked lane is unaffected (every vector is
MOCKED), so generated vectors do not churn; only the real-crypto authoritative set is corrected for non-crypto negative vectors.Testing
just checkpasses (lint, format, ty, codespell, mdformat).int(0/1/2) for every member, andProofSetting.MOCKED == 0.UNKNOWN_PARENT_BLOCKis not a proof failure;INVALID_SIGNATURE/INVALID_BLOCK_PROOFare.proofSetting: 0.🤖 Generated with Claude Code