feat(protocol): enforce an invocation delay for bridged messages

[dantaik]

Brecht previously proposed enhancing the Bridge's security by implementing a mandatory delay before message invocation. In this draft implementation, by default, the invocation delay is set to 0, allowing the Bridge to operate as usual. However, when configured with a non-zero delay, each message requires a two-step process (true for both processMessage and recallMessage). The first step verifies the message with a Merkel proof and timestamps it, while the second step is responsible for the actual message invocation. A challange is that the previous message.fee is designed for a one-step process, now with a two-step process, in theory we need two fees, one for each step, but this is not implemented in this PR as it will have data incompatibility issue.

We should deploy a bridge watchdog software which always monitors all MessageReceived events, ensuring that messages scheduled for invocation exist on their source chain. If a discrepancy is detected, the watchdog will use pauseMessages to halt the invocation of these messages and initiate an investigation.

Tests specific to the non-zero invocation delay feature will be added once we decide to adopt this enhancement.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
bridge-ui-v2-a6	✅ Ready (Inspect)	Visit Preview	Feb 5, 2024 11:46am

[adaki2004]

@KorbinianK @cyberhorsey if you have any questions let me know.
TLDR here so we can refer to later:
This will require some (ui/relayer) changes like:

• delay enabled or not ? (L2 most probably not, L1 i guess will have it)
• if delay enabled calling "claim" (aka processMessage) twice and in the right time window, etc.