feat(contracts): new challenger

[merklefruit]

Overview

This iteration of the BoltChallenger implements the new Commitment Challenge game.
The challenge resolution flow consists of the following steps:

1. identify the challengeID you want to solve, based on the event emitted upon new challenge creation
2. provide a blockHash from a trusted source. For recent blocks, this can be the EVM directly. For historical blocks, this can come from a number of sources like blockhash accumulators, zk-coprocessors, or other proving systems.
3. provide a proof consisting of:
   • RLP-encoded block header (hashing to the provided blockHash)
   • Account merkle trie proof
   • Transaction merkle trie proof

Tasks

• decode block header, given a trusted block hash
• prove existence of an account and decode its contents from RLP, given a proof and a trusted state root
• prove inclusion of a transaction and decode its contents from RLP, given a proof and a trusted tx root
• add unit tests for opening challenges
• build an end2end test with the challenge resolution proof flow
• build out the functionality to open a new challenge
• build out the first challenge resolution logic
• add more unit tests for fault resolution logic
• add extensive documentation

RLP transaction decoder

•  implement decoding for EIP-2718 transaction envelopes of type 0, 1, 2, 3
• test decoding & preimages with ethers-js test vectors

Extra (out of scope):

• write a Rust library and CLI tool to generate all the required proofs for resolving a challenge
• write a challenger agent binary that monitors the chain for newly opened challenges

Meta

• closes Challenger implementation V1 #199

[thedevbirb]

Stunning work. Just left some comments on the dispute logic since I've trouble understanding to what data the account proofs points to: before transactions or after transactions?

[thedevbirb]

I'm not sure about this check:

• Suppose my account before sending the preconf has nonce $n$. As such, the nonce of the tx is $n$ as well. After it has been included my account will have nonce $n+1$. Since the proof.accountMerkleProof is performed against the blockHeader.stateRoot after all its transaction I'm worried we might always enter this if condition is always satisfied
• What if I send multiple preconfirmations for the same slot? According to the reasoning of the previous point, can we encounter some edge cases?

[mempirate]

Good points! A simple fix is using the previous blocks' state root to do these checks right?

[notion-workspace]

Restaking Protocol - Eigenlayer

[notion-workspace]

Challenger