node: Add Transfer Verifier mechanism

[johnsaigle]

Transfer Verifier

This PR is a joint effort between myself, @pleasew8t, and @mdulin2.

Overview

This PR introduces the Transfer Verifier, a mechanism to improve Token
Bridge security by validating transaction receipts that correspond to Publish
Message events emitted from the Core Bridge.

When the core bridge emits a Publish Message event, the Transfer Verifier does
the following:

• Fetches the transaction artifacts corresponding to the Publish Message event
  (e.g. an Ethereum receipt transaction)
• Checks whether the publish message corresponds to a token transfer and is
  emitted by the Token Bridge contract
• Cross-references the data in the publish message against actual deposits or
  transfers into the token bridge
• If there is publish message with no valid corresponding deposit or transfers
  into the Token Bridge, the program emits an error to signal to the node that
  there is a security incident.

This provides protection in the event that an attacker devises a way to emit
arbitrary publish message events from the core contract or else somehow tricks
the Token Bridge into making token transfer calls without any backing tokens.
While existing Integrity Checks (Governor and Accountant) would help mitigate
this attack, Transfer Verifier acts as another layer of protection.

What this PR contains

This PR contains two initial implementations for Ethereum and Sui.

Both implementations are bundled into a Transfer Verifier package. This package
is used by a new transfer-verifier binary that exists as a subcommand within
guardiand. This binary can be configured to monitor the mainnet token bridge and core
bridge contracts for this chain.

Testing

Both implementations contain a large number of unit tests. They can be invoked
as a normal part of testing the node via make test.

The Ethereum implementation has integration tests built into the Tilt set-up:

• After the eth-devnet container is set-up, the transfer-verifier binary is
  invoked to monitor the Ethereum devnet
• A shell script invokes a malicious call to the core contract via cast (part
  of the Foundry toolset)
• The transfer-verifier binary logs an error when detecting the malicious call
• A separate monitoring container looks for the presence of this error log and
  returns a success when it appears

In order to impersonate a call from the Token Bridge to the Core Bridge, the
--auto-impersonate flag was added to the anvil invocation in eth-devnet.

Future Work

The Transfer Verifier package is used here as a standalone binary. Its
fundamental output are logs that can be monitored and manually acted upon.

The next iteration of this project will be to integrate the package directly in
the Ethereum and Sui watchers

Integration into the Ethereum watcher

Ethereum has an advantage over the Sui implementation due to the robust logging
and tooling present in the EVM and its ecosystem. We can validate the relevant
information for Transfer Verification in a highly robust way and detect
violations of its invariants with certainty.

As a result, we can use the logic in the Transfer Verifier to block
transactions at the level of the Ethereum watcher so that malicious message
publications will not be processed by the network.

Integration into the Sui watcher

The nature of Sui makes it relatively difficult to provide guarantees about the
state of the core bridge relative to the token bridge. The Sui implementation
cannot provide the same guarantees as the Ethereum implementation due to limits
inherent in the chain.

It is still possible to integrate this protection into the Sui watcher but it
would be better to delay messages for e.g. 24h in this case rather than reject
them outright.

Additional implementations for other chains

This is an abstract algorithm that can in theory be applied to any chain supported by the Token Bridge.
Designing a Solana implementation of this script would be a fruitful choice
given that it is one of the chains that makes the most use of the Token Bridge.