DC-NODE-35
DC derived enforcedBLUE-safe candidate construction (PHASE4-N-AO). A CandidateFragment fed to the BLUE fork-choice authority select_best_chain (DC-CONS-03) MUST be derived ONLY from Ade's own validated headers (validate_and_apply_header output -- the chain_selector::process_header_arrival validate-then-fragment pattern), NEVER a peer-trusted minted ValidatedHeaderSummary (the ade_core_interop::follow shape, which MUST NOT cross into BLUE or any authority path) and NEVER a raw followed_peer_tip. Byte authority: hash-critical protocol paths use the preserved original wire bytes; internal candidate comparison/proof surfaces use project-canonical bytes. Peer identity (DC-NODE-34) is preserved on each candidate. Candidate-set ordering MUST be deterministic. Malformed / missing candidate data fails closed. No live select_best_chain call may be introduced until candidate construction proves these five properties (the cluster's load-bearing S2 entry gate). The aggregator's TCB color (GREEN vs BLUE-adjacent) is resolved by this proof -- the easier color MUST NOT be picked to dodge it.
- Source
docs/planning/phase4-select-multicandidate-fork-choice-invariants.md (FC-10; the BLUE-safety proof obligation) + docs/clusters/PHASE4-N-AO/cluster.md
- Introduced in
- PHASE4-N-AO
Enforcement trace
Tests 5
- build_candidate_fragment_assembles_from_validated_headers
- build_candidate_fragment_empty_headers_fails_closed
- build_candidate_fragment_rejects_invalid_header_fails_closed
- build_candidate_fragment_two_runs_byte_identical
- assemble_candidate_set_ordering_is_arrival_independent
Cross-references
Evidence notes
Declared at PHASE4-N-AO cluster-doc; enforced at S2 close (CE-AO-2) via ci_check_candidate_construction_validated.sh. THE load-bearing gate -- it keeps the cluster from becoming look-over-the-peers-shoulder. Resolves OQ-AO-2 (BLUE-safe construction + the fork-point chain_dep question) + OQ-AO-6 (aggregator color). Latent until S3 (DC-NODE-36) consumes it.