Skip to content

fix crash during apply_proof with DAG level 0 blocks referencing origin#43

Merged
0xA001113 merged 1 commit into
spectre-project:mainfrom
x100111010:origincrash
Jun 27, 2025
Merged

fix crash during apply_proof with DAG level 0 blocks referencing origin#43
0xA001113 merged 1 commit into
spectre-project:mainfrom
x100111010:origincrash

Conversation

@x100111010
Copy link
Copy Markdown
Member

Fixes a crash that occurs at let calculated_gd = self.ghostdag_manager.ghostdag(&parents) when processing the first block in proof[0] (DAG level 0).

2025-06-18 21:39:18.547+02:00 [ERROR] thread 'tokio-runtime-worker' panicked at consensus\src\processes\ghostdag\protocol.rs:103:110: called Result::unwrap()on anErr value: KeyNotFound(GhostdagCompact/0/fefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefe)

The crash happens during apply_proof when processing DAG level 0 blocks. The root cause is in the parent filtering logic using level ancestors:

.filter(|parent| level_ancestors.contains(parent))

When this filtering removes all parents (because they're not in the level ancestors set) it code falls back to using [ORIGIN] as parents via .push_if_empty(ORIGIN).

For the first block in level 0 this results in parents containing only [ORIGIN]. When ghostdag() is called, it invokes find_selected_parent() which tries to read ORIGIN's blue work from the ghostdag store via get_blue_work(parent).unwrap(). But ORIGIN's ghostdag data was never inserted into the store, causing KeyNotFound(GhostdagCompact/0/fefe...) panic.

https://gist.github.com/x100111010/2189956eacc3559bae9da889422a1b87

ORIGIN is a special virtual genesis block:

pub const ORIGIN: Hash = Hash::from_bytes([0xfe; HASH_SIZE]);

Spectre has significantly more dag level 0 blocks (stems from large hashrate spikes that the Difficulty Adjustment Algorithm (DAA) cannot respond to quickly enough) blocks at DAG level 0 (98,969 blocks vs Kaspa's typically empty level 0), making proof[0] non-empty.

Found sufficient root for level 0 after 0 tries: 93544d1ec38f6c8ebc84ed24f10fe39392b2fc55a053e3951191dd568ac97d04

2025-06-19 16:48:54.683+02:00 [INFO ] Block 93544d1ec38f6c8ebc84ed24f10fe39392b2fc55a053e3951191dd568ac97d04 got fefe (ORIGIN)

2025-06-19 16:48:54.683+02:00 [INFO ] Is first block in level 0: true

2025-06-19 00:06:22.358+02:00 [INFO ] Level: 1 | Hash: 93544d1ec38f6c8ebc84ed24f10fe39392b2fc55a053e3951191dd568ac97d04 | Parents: [af623d9853b88ff737ad163d2f7d2199d38c30091297e196bff110dc65317af5]
2025-06-19 00:06:22.360+02:00 [INFO ] Parent: af623d9853b88ff737ad163d2f7d2199d38c30091297e196bff110dc65317af5 => dag level 1

2025-06-18 21:39:18.547+02:00 [ERROR] thread 'tokio-runtime-worker' panicked at consensus\src\processes\ghostdag\protocol.rs:103:110: called `Result::unwrap()` on an `Err` value: KeyNotFound(GhostdagCompact/0/fefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefe)

fix a crash that occurs at `let calculated_gd = self.ghostdag_manager.ghostdag(&parents)` when processing the first block in `proof[0]` (dag level 0). When parents contain [ORIGIN] so `ghostdag()` calls `find_selected_parent` which tries to read the ORIGIN's blue work from the ghostdag store via `get_blue_work(parent).unwrap()`, but `origin_ghostdag_data` was never inserted so it crashes with KeyNotFound. This also reverts 032fda1
@0xA001113 0xA001113 merged commit fb877ea into spectre-project:main Jun 27, 2025
3 of 6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants