search

ethpandaops / dora

Dora the Explorer is a lightweight slot explorer for the ethereum beaconchain
https://beaconlight.ephemery.dev/
GNU General Public License v3.0
83 stars 26 forks source link

implement request log crawler for consolidation & withdrawal request transactions #141

Closed pk910 closed 1 month ago

pk910 commented 1 month ago

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:

  1. consolidation/withdrawal tx indexer: 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.

  1. consolidation/withdrawal matcher: 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: image

pk910 commented 1 month ago

@skylenet I've fixed the review comments and updated the contract addresses for devnet 4 :) build is currently failing due to #159