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

[Feature]: Add a "heartbeat" for bridge contract chain events #11334

Closed
wwestgarth opened this issue May 29, 2024 · 0 comments · Fixed by #11411
Closed

[Feature]: Add a "heartbeat" for bridge contract chain events #11334

wwestgarth opened this issue May 29, 2024 · 0 comments · Fixed by #11411
Assignees
Labels
bridges ethereum feature new feature to be developed

Comments

@wwestgarth
Copy link
Contributor

wwestgarth commented May 29, 2024

Feature Overview

In order for validator nodes to catch up Arbitrum events after a protocol-upgrade
We will add a "heartbeat" to the forwarder
So that the "last seen" block for inactive bridge contracts (e.g the multisig) remains recent

When a node is started from a snapshot it will use the block height of the last-seen event for a bridge contract as the block to start reading logs from. This is so that no events are missed during any down-time. For bridge contracts where there is not much activity the last-seen event could be a very long time ago, for example on the Ethereum bridge the multisig control contract's last signer event was 190 days ago.

What this means is that a validator node starting from a snapshot today would have to read the logs for 190 days worth of ethereum blocks, and this can take some time.

On Arbitrum the problem is much worse since the block time is very low and 5 blocks are created per second. Also the maximum block interval that some Arbitrum Archival nodes allow to be queried at once is very small at 500 blocks. So to be able to read logs from the "last-seen" even could take a very long time.

What we need is to periodically send in a dummy heartbeat transaction that says to the network "there were no events, but we've checked logs up to block N", so that on snapshot restore the validators can simply check for new events from block N instead.

Note that this will will be similar to the heartbeat added to the eth-call engine here #10872

Specs

  • Link to spec or section within a spec

Tasks

A checklist of the tasks that are needed to develop the feature and meet the acceptance criteria and feature test scenarios.

  • [ ]
  • [ ]

Feature test scenarios

Detailed scenarios that can be executed as feature tests to verify that the feature has been implemented as expected.

GIVEN (setup/context)
WHEN (action)
THEN (assertion) For example...
See here for more format information and examples.

Additional Details (optional)

Any additional information that provides context or gives information that will help us develop the feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bridges ethereum feature new feature to be developed
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

1 participant