Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce executed_block_by_hash #10552

Closed
Tracked by #10570
Rjected opened this issue Aug 26, 2024 · 1 comment
Closed
Tracked by #10570

Introduce executed_block_by_hash #10552

Rjected opened this issue Aug 26, 2024 · 1 comment
Assignees
Labels
A-blockchain-tree Related to sidechains, reorgs and pending blocks C-enhancement New feature or request

Comments

@Rjected
Copy link
Member

Rjected commented Aug 26, 2024

If we want to be able to send these notifications for reorgs that extend to data on disk:

/// Non-empty chain of blocks.
#[derive(Debug)]
pub enum NewCanonicalChain {
/// A simple append to the current canonical head
Commit {
/// all blocks that lead back to the canonical head
new: Vec<ExecutedBlock>,
},
/// A reorged chain consists of two chains that trace back to a shared ancestor block at which
/// point they diverge.
Reorg {
/// All blocks of the _new_ chain
new: Vec<ExecutedBlock>,
/// All blocks of the _old_ chain
old: Vec<ExecutedBlock>,
},
}

For example in #10551 we need to be able to walk back the canonical chain, even on disk, and populate this data. So we need to be able to fetch ExecutedBlock by hash in the EngineApiTreeHandler.

We basically want to be able to produce executed blocks in the following reorg case:
Screenshot 2024-08-26 at 3 49 54 PM

@Rjected
Copy link
Member Author

Rjected commented Sep 3, 2024

done

@Rjected Rjected closed this as completed Sep 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-blockchain-tree Related to sidechains, reorgs and pending blocks C-enhancement New feature or request
Projects
Archived in project
Development

No branches or pull requests

1 participant