You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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
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.
The text was updated successfully, but these errors were encountered: