Make Linera easier to verify on other blockchains

[deuszx]

We want to make bridges with other chains. While Linera has special features that allow its validators to verify other chains (built-in Oracles), bridges work both ways and other chains will need to verify Linera as well. There are different types of bridges:

• Guardian-based
• ZK-based
• Light-client based

Both Guardian-based and ZK-based bridges add a layer of indirection/interpretation on top of Linera blocks/messages and Linera state is not directly verified on chain. For light-client type bridges, smart contracts (on the recipient chains) need to verify:

1. block chain
2. smart contract state

Block verification

Recipient chains will have to verify Linera's chain of block. They'll need to:

1. (de)serialise Linera blocks and check that hashes match.
2. Verify that the new block follows from the previous one(s).
3. Verify finalisation of the incoming block.
4. Track Linera validator rotation

Smart contract state verification

Once the light client is capable of following the Linera chains, specific apps will want to be able to act on Linera Application specific events. The occurrence of the event needs to be cryptographically verifiable.

Tasks

Block structure

• Add new Block and BlockHeader structs #3077
• Use block header's version number to choose deserialization logic #3078

Crypto

• Switch hashing to Keccak #3125
• Support for Ethereum signing algorithm #3126

Ethereum

• Solidity deserializers for Linera types #3127

• Linera light client in Solidity #3128

• Relayer

Sui

• Move deserializers for Linera types #3130
• Verify Linera blocks in Move #3131
• • Remember about following committee changes
• Verify inclusion of an element in Linera block header #3132
• Relayer

[ma2bd]

Couple of ideas how to break down this task (@afck may have more inputs):

1. Cryptographic compatibility is probably the first thing to look into:

   • We may have to switch some or all Linera crypto-hashes to Keccak256 (for Ethereum) --> switching all of them is going to break tests that hardcode chainIDs etc but it might be the simplest thing to do in the long term.
   • We may want the public key of a Linera validator to be in fact a tuple of public keys (one in each supported signing scheme).
   • By default, all blocks should still be multi-signed using the current curve (which I believe is faster to sign and verify). However, certain blocks containing external events directed at an external chain will need to be additionally multi-signed by other signing schemes. I guess this make each Linera signatures potentially a tuple? We probably want Linera validators (and initially clients) to verify all the signature components of a certificate before storage. (Fortunately, few blocks will require these additional slower schemes)

2. Most likely, external chains only want to consume the events directed to them in a Linera block, so they should not have to process entire blocks. This requires changing the block format and introduce a notion of block headers (basically, a small handcoded Merkle tree).

3. BCS-deserialization of block headers should be easy enough to write by hand. However, in the long run, we could also invest in code-generation for solidity