DC-PROD-03
DC derived enforcedProducer chain-forward continuity + replay. The GREEN ChainEvolution linear typestate threads each forge's post-state (post-ledger, post-chain_dep, new tip) into the next forge's base; forging against a stale base is structurally unrepresentable (advance consumes self). advance obtains the post-state from BLUE block_validity and the AcceptedBlock token from BLUE self_accept against identical inputs (same pre-forge base, forged bytes, era_schedule, ledger_view); if the two authorities disagree it returns ChainEvolutionError::AuthorityMismatch and does not advance. ChainEvolution never constructs AcceptedBlock directly. For a fixed (bootstrap seed, canonical slot-sequence, KES/VRF/cold keys) the chain-evolution series (block_number, prev_hash, post-ledger fingerprint, post-chain_dep) and the forged block bytes are byte-identical across runs (in-memory two-run; no on-disk replay corpus — durability deferred to N-U).
- Source
docs/planning/phase4-n-t-invariants.md §3, §4 (R1, R3); docs/clusters/PHASE4-N-T/cluster.md §1.5, §7
- Cluster
- PHASE4-N-T
- Introduced in
- PHASE4-N-T
Enforcement trace
Tests 8
- advance_threads_post_state_forward
- advance_two_runs_byte_identical
- advance_rejects_invalid_bytes
- reconcile_verdicts_both_valid_ok
- reconcile_verdicts_both_invalid_ok
- reconcile_verdicts_valid_vs_reject_mismatches
- reconcile_verdicts_reject_vs_valid_mismatches
- served_snapshot_two_run_replay_byte_identical
CI 0
no CI script — gap