[Bridge] [Relayer] [Finality] Relay Events in finalised blocks only

[franck44]

Problem

Our bridge design relays event from Ethereum mainnet to our L2. These events are collected from logs, and logs are stored in blocks. A block is permanent (irreversible) when it finalised which takes on average ~15 minutes.

Warning

If we relay events that are in non-finalised blocks, we bear a risk of a re-org . A re-org results in recent (non-finalised) blocks being "removed" from the canonical chain and "replaced" by other blocks. Relaying events from non-finalised blocks may result in attacks e.g. with the following steps:

1. on L1, user1 sends a transaction $t$ to lock some assets in our bridge; $t$ is successful and it is included in a block $b$,
2. the relayer notices the corresponding emitted event on the L1 logs in the non-finalised block $b$B and relays it the L2 to complete the transfer,
3. we mint some assets on the L2 and send them to user1 (their account on L2),
4. the L1 block $b$ is invalidated because of a re-org; in the new block $b'$ that $t$ is included in, the transaction $t$ fails (no assets are transferred to the bridge on L1).
   Potential attack: This results in user1 receiving some assets on L2 without locking the corresponding amount in our bridge.

You may be interested in this post for a primer on Ethereum events.
For re-orgs, Alchemy has an explainer.

We may dismiss the previous scenario arguing that re-orgs are infrequent. However, since EIP-4844, re-orgs are more frequent according to this analysis.

Caution

It looks like re-orgs can occur at a rate of $0.3\%$, i.e. 3 blocks per 1000 blocks. A block is produced every ~12 seconds, so 1000 blocks correspond to $12 \times 1000 = 12000$ seconds which is roughly 3h 20mins. So we may have a re-org on average every 1h 6mins.

Unfortunately there is no clear results on how deep a re-org is, i.e. how many non-finalised blocks it can impact.

Note

The same issue exists when bridging from L2 to L1 and we need to make sure that L2 blocks ww relay events from are finalised.

Proposal

The proposal is to protect against the attack described above.

Important

In order to mitigate the previous attack, we need to relay events that are in finalised blocks only.

Implementation

It looks like the current implementation of the relayer relies on block confirmations to relay events. A block $b$ is k-confirmed if k blocks have been produced and appended to $b$, i.e. there is a chain of k blocks that are children of $b$.

Some exchanges rely on a confirmation of 20 or 30.
Etherscan displays the real status of blocks, "unfinalised/unfinalised(safe)/finalised".

If there is API to query the status of a block we may use it to verify that blocks we relay events from are finalised.

Validation

The implementation impacts the relayer and some new tests may be needed to validate the changes.

[franck44]

@musitdev

Here is a summary of our discussion on this issue:

1. we relay events from finalised blocks only on L1 and L2
2. this results in ~12 to 15mins for a bridge transfer L1 -> L2, and probably a similar time (depending on the policy we adopt) from L2 -> L1.

Important

So perhaps it needs some update in the UI so that the user can be informed on how long they have to wait.

To implement this solution we need to retrieve the status of a block (finalised or not).

• on the Eth side,

The call eth_getBlockByNumber with finalized tag allow to get the last finalized block.

• on the Mvnt side:

we open a Rest API port that only return finalized block with the same API. We just have to request block in finalized state.

The locations of the changes in the code base are:

• Eth side: protocol-units/bridge/service/src/chains/ethereum/event_monitoring.rs

• Mvnt Side: protocol-units/bridge/service/src/chains/movement/event_monitoring.rs