[Feature]: Check for block finality on Arbitrum

[wwestgarth]

Feature Overview

Currently on Ethereum blocks are finalized after two epochs (64 blocks) and we have a mechnism in core that will wait for this many confirmations before verifying a chain event. This is a reasonable thing to do.

Given that Arbitrum is a L2 chain, block finality is slightly different, and it comes in two flavours:

• soft-finality: when the Arbitrum sequencer orders the transactions into an Arbitrum block
• hard-finality: when the sequencer submits a "batch" to L1 Ethereum (this happens every ~4mins) and that batch reaches finality on Ethereum

As hard-finality requires checks on two different chains counting blocks for confirmations will not work here. Arbitrum even advise against this in their own documentation:
https://docs.arbitrum.io/for-devs/troubleshooting-building#how-many-block-numbers-must-we-wait-for-in-arbitrum-before-we-can-confidently-state-that-the-transaction-has-reached-finality

What Aribitrum suggest doing is to call eth_getBlockByNumber() with the string finalized to get the latest Arbitrum block number which exists in a batch that is finalised on Ethereum. Then we check that the event we care about happened on an Arbitrum block <= the last finalized block.

As it so happens we can (and should) be doing this same check on our L1 bridge and we can do so with the same RPC call:
https://ethereum.org/en/developers/docs/apis/json-rpc/#default-block

So what we need to do is to extend the current confirmation check so that a block is only considered confirmed if:

1. the given number of configured number of block's set in the network-parameter for the bridge has passed
2. the block of the event has been marked as finalized

Note that we only want this new check for events that came over the bridges to Vega and not for any chain-events that are the result of contract call's used as data-sources.

Also note that there is some hackery needed to call eth_getBlockByNumber() through the ethereum-client we use:
https://github.com/ethereum/go-ethereum/blob/04bf1c802ffe9dfc34c34b3e666ee15e96b4a203/eth/api_backend.go#L66-L94

and also that this ticket is blocked until we upgrade ganache to a version that supports finalized eth_getBlockByNumber() calls.

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.