-
Notifications
You must be signed in to change notification settings - Fork 2.2k
feat(taiko-client): add checks to ensure preconfirmation blocks are based on canonical chain #19379
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR adds a check to ensure that preconfirmation blocks belong to the canonical chain by fetching the canonical parent block and validating its hash against the provided executable data.
- Fetch the canonical parent block via the L2 header API.
- Compare the canonical parent's hash with that of the executable data and return an error if they do not match.
packages/taiko-client/driver/chain_syncer/event/blocks_inserter/pacaya.go
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR adds validations to ensure that preconfirmation blocks are part of the canonical chain. It introduces stricter error messages in the preconfirmation check and implements a new helper function (IsInCanonicalChain) to traverse and verify the chain linkage.
packages/taiko-client/driver/chain_syncer/event/blocks_inserter/pacaya.go
Show resolved
Hide resolved
packages/taiko-client/driver/chain_syncer/event/blocks_inserter/pacaya.go
Show resolved
Hide resolved
Codecov ReportAttention: Patch coverage is
Additional details and impacted files
... and 1 file with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
This will introduce an O(n) search through RPC calls when the preconf block is in another (valid / invalid) fork, we can optimize it by moving the search to a new
taiko-geth
RPC method later.