On-chain proof challenge game for commitment verification

[merklefruit]

Currently, it's easier and more efficient to use a single-shot challenge for verifying constraints:

1. A challenger (ideally permissioless, so anyone holding a signed BOLT proposer commitment) creates a new Challenge
2. When an event is emitted, the targeted BOLT proposer (via its sidecar) should respond by sending a transaction to prove the inclusion in his committed block. We can set a 7 day deadline to this response.

• Challengers will need to post a small ETH bond, so that there is no incentive to spam the network with challenges as the proposers get refunds for the gas required for responding to these challenges truthfully.
• Failure to respond in time to the challenge will be considered the same as a fault.
• For now, there is no slashing implemented, but an event can be emitted to signal a proposer fault.

Challenge game overview

• alice: user that creates a challenge
• bob: proposer opted in BOLT as a preconfirmer

1. alice submits a challenge with: bob's signed preconfirmation commitment as well as the unsigned message containing the transaction hash over which the commitment was made (depending on what the exact commitment will look like, TBD)
2. the challenge() function will:
   1. verify that the signed commitment resolves back to bob's pubkey via ECDSA recovery
   2. verify that bob is registered in BOLT's on-chain registry (On-chain registry #15)
   3. verify that bob was scheduled as proposer for the slot specified in the signed preconfirmation
   4. emit an event
3. at this point bob needs to defend by calling resolveChallenge():
   1. verify that there is an active challenge against him
   2. verify the the actual inclusion commitment

In terms of the commitment verification step, there are a few dependencies:

1. we need an oracle for historical transactions roots. After Dencun this is possible thanks to the BEACON_ROOTS contract. Relic Protocol have already done the work to provide an oracle for all block header contents that's easily provable on-chain.
2. ideally the transactions-root and beacon-root of the target block should be stored in the challenge contract's storage, so they don't get wiped after a while. The beacons root contract only keeps the 8191 most recent roots in a buffer (about 1 day).
3. once we have this info, bob will still need to provide 3 things: the hash_tree_root of the included transaction, the index in the block of the transaction, and the ssz proof. Verification will entail checking that the proof + the given hash tree root hash to the correct transactions_root saved in the contract beforehand.
4. additionally, the hash_tree_root will also need to be checked against the raw RLP signed transaction that was preconfirmed