implement request log crawler for consolidation & withdrawal request transactions #141
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
skylenet
reviewed
Oct 16, 2024
pk910
force-pushed
the
pk910/pectra-log-crawler
branch
from
6db6d73 to
ca6a836
Compare
skylenet
approved these changes
Oct 28, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds log crawlers and matchers for the pectra consolidation & withdrawal system contracts.
Both system contracts emit basic log events before queuing incoming operations.
Operations are then dequeued and passed to the beacon chain where they get included in a block as consolidation & withdrawal requests.
Consolidation & withdrawal requests are already tracked by dora.
This PR aims to extend the available request information with further transaction details coming from the execution layer.
So dora can not only show the operation details, but also the origin (tx hash, sender, etc.) on the execution chain.
To achieve this, I've implemented two routines for each request type:
This routine crawls the system contract logs from the execution layer.
The emitted events are processed in order starting from the deploy block, to keep track of the contract queue length internally.
For each event, dora persists the transaction details, including the operation details, sender + target addresses and the dequeue block number (calculated based on queue length & static dequeue rate).
transaction details are stored in a separate database entity as they may exist before the corresponding beacon operation gets added to the database and vice versa.
This routine tries to match up the separate request transaction & request operation entities.
It uses the calculated dequeue block number from the transaction entities and loads the corresponding request operations from the slot that includes the el block with that number.
The matcher routine tries to match each transaction once, ensuring only synchronized block ranges are processed.
This might leave some late orphaned operations unmatched, but it's an acceptable trade-off compared to processing all unmatched beacon operations over and over again, as some transaction details for orphaned blocks might just not be available anymore.
For matching requests, the transaction hash is added to the beacon operation entity.
I've also extended the consolidations & withdrawal requests pages to display the matched tx hash (and link it to an el explorer if available).
Additional transaction details are available via a popover: