Remove contract dependencies

[merklefruit]

We currently rely on the following dependencies:

• Relic SDK

It would be nice if the Challenger didn't have any third party dependency in Bolt, as it means it's more ergonomic to deploy on devnets and testnets. This issue is to keep track of dependencies and eventually decide on the best strategy to remove them.

[thedevbirb]

I think it is doable but some work is needed as well as some extra calldata on the prover side. At the moment we use Relic in two ways:

1. deriving block header information
2. deriving account information

Let's tackle both one at a time.

Block header

For the block header we could leverage once again the BEACON_ROOT_CONTRACT. The prover sends all the raw block header data along with the rest of beacon block information to reconstruct a beacon root hash. If valid, then the provided block header is valid as well. This will get easier if EIP-2935 will be included in the future, since we could check it against historical block hashes directly.

Account information

Let's consider this picture of Ethereum MPTs:

We need to prove that a certain account state was valid at a specific block height. To do that, the prover needs to send the raw account state data along with a MPT proof of inclusion, that needs to be checked on-chain. For this we could take a look at this library https://github.com/polytope-labs/solidity-merkle-trees which seems promising and maintained. Once we verify that account data is valid and associated to a certain state_root, then we can check the state_root itself is valid by providing the rest of the header data, and checking the latter against the beacon root as done above.

[merklefruit]

Looks solid, thanks!

[merklefruit]

Some updates on this:

It looks like Relic isn't easy to run on our devnet, if even at all, because it relies on their online prover (which only runs on mainnet and is run by them. You can see the API used here in their client SDK). This issue is now higher priority if we want to have working fault proofs.

As next steps, here I outline the data that we need proven (for now, this isn't a definitive list):

1. block header info:
   • block number
   • base fee
   • block timestamp
   • transactions root
2. arbitrary account info:
   • nonce
   • balance

---

Other relevant info / questions to keep in mind:

• With EIP-4788 we can only prove information inside the BeaconBlock, not any arbitrary execution layer data.
• Will EIP-2935 solve all of our problems? It would introduce commitments to historical ExecutionPayloads.
• If we do need EIP-2935, can we run the kurtosis devnet on an early version of Pectra-supporting clients? This would require checking if geth and lighthouse (what we're using in the devnet right now) have unstable releases for it.
• the already existing BLOCKHASH EVM Opcode already returns the hashes for the 256 most recent blocks. It's a rather short window, but can we use it anyway?

[mempirate]

Part of #206