**GitHub Issue from [QuipNetwork/quip-protocol](https://github.com/QuipNetwork/quip-protocol/issues/14)** **Author:** @doomhammerhell **Created:** 2026-05-04 21:16:59+00:00 **State:** open --- ### Affected components - `shared/block_synchronizer.py:284-287` - sync enqueues blocks with `force_reorg=True` - `shared/node.py:417-423` - `check_block(..., force_reorg=False)` documents bypass behavior - `shared/node.py:456-469` - timestamp/tie-break checks skipped under force reorg - `shared/node.py:476-479` - old-block rejection skipped under force reorg - `shared/node.py:487-502` - forced ancestor search truncates local chain - `shared/node.py:572-583` - `receive_block` resets chain slice before appending ### Severity High. This is a fork-choice and sync safety issue. It can become critical when combined with producer-controlled requirements or topology substitution because an adversary can more cheaply construct an alternative valid branch. ### Protocol invariant violated Deterministic fork choice. Network sync may acquire data from peers, but it must not bypass the same validity and fork-choice rules that govern normal block acceptance. ### Summary The synchronizer explicitly marks downloaded sync blocks as `force_reorg=True`, with the comment that sync blocks should always be accepted because "longest chain wins." In `check_block`, that flag skips timestamp preference, skips old-block rejection, and allows the node to search for an ancestor and truncate the local chain. This conflates data acquisition with fork-choice transition. ### Technical root cause The sync path sets the bypass flag: - `shared/block_synchronizer.py:284-287` puts `(block, dummy_future, True, "sync")` into the receive queue. `check_block()` changes semantics under that flag: - `shared/node.py:456-469` skips existing-block timestamp/tie-break preference. - `shared/node.py:476-479` skips rejection of blocks older than the local head by more than six blocks. - `shared/node.py:487-502` searches the full chain for an ancestor and truncates local state if found. `receive_block()` then performs local chain reset: - `shared/node.py:579-583` slices the chain before appending the accepted block. ### Adversarial scenario An adversarial peer presents an alternative branch during sync. Each block may be individually valid under the current validation function, but the branch may not be preferred under a deterministic fork-choice rule that accounts for cumulative work, finalized checkpoints, or total difficulty. Because the sync path uses `force_reorg=True`, the peer can steer the victim into deep reorganization semantics that normal block propagation would not allow. ### Reproduction / PoC Deterministic trace: 1. Victim chain: ```text G -> A1 -> A2 -> ... -> A20 ``` 2. Attacker has alternative valid branch: ```text G -> B1 -> B2 -> ... -> B21 ``` 3. Victim receives blocks through sync, not normal gossip. 4. `BlockSynchronizer` enqueues `B1..B21` with `force_reorg=True`. 5. When a previous-hash mismatch is encountered, `check_block()` searches for common ancestor `G`. 6. The victim truncates the local chain to `G` and appends attacker branch blocks. The transition is peer-triggered through sync semantics rather than a single deterministic fork-choice function. ### Expected behavior Sync should download candidate blocks into a staging area. After acquisition, all blocks should pass the same validation rules, and a deterministic fork-choice rule should decide whether to reorganize. ### Actual behavior The sync path passes a force flag into block acceptance and thereby bypasses normal fork protection. ### Impact Adversarial peers can influence reorg behavior and chain truncation. The issue is especially risky because other current gaps make it easier to produce apparently valid alternative chains. Even if all blocks are valid, the absence of an explicit cumulative-work or finalized-checkpoint rule means reorg decisions are not protocol-clean. ### Mitigation - Remove peer-triggered `force_reorg` from normal sync. - Separate block fetching from block adoption. - Maintain candidate forks separately from the canonical chain. - Define fork choice explicitly, e.g. cumulative work, finalized checkpoint, height with work tie-break, or Substrate finality if Rust becomes authoritative. - Restrict any force mode to trusted local recovery tooling, never remote peer input. - Add maximum reorg depth unless finality/fork-choice rules justify deeper reorgs. ### Suggested patch direction Introduce: ```text fetch_block(peer, hash) -> CandidateBlock validate_candidate(candidate, parent_state) -> ValidCandidate fork_choice(current_head, candidate_head) -> Adopt/Reject ``` and remove `force_reorg` from network-driven receive paths. ### Recommended tests - Unit test: sync-delivered block follows the same rejection rules as gossip-delivered block. - Reorg test: older or lower-work branch is not adopted through sync. - Deep fork test: ancestor search does not mutate canonical chain before full branch validation. - Adversarial peer test: invalid or lower-preference branch remains staged and is not adopted. - Regression test: local recovery mode is not reachable through peer messages. ### Maintainer-facing wording The sync code currently uses `force_reorg=True` as a practical recovery mechanism, but that makes the sync path part of consensus behavior. I would suggest splitting these responsibilities: peers can help us acquire missing blocks, but they should not select the fork-choice transition by causing forced acceptance. Candidate branches should be validated into a staging structure and adopted only through the same deterministic fork-choice rule used everywhere else.