Investigate using the Lighthouse codebase for interacting with the consensus chain in Steel

[linear[bot]]

WEB3-70 Investigate using the Lighthouse codebase for interacting with the consensus chain in Steel

[nategraf]

After discussion with @Wollac, I'm going to close this issue. He pointed out the following:

• Lighthouse does not implement a client for the beacon API, so we would need to build this from reqwest and the corresponding consensus types.
• More importantly, it does not have support to create Merkle inclusion proofs, but only the tree root. This is the very nice and crucial feature of the current crate to be able to say .prove(&["body", "execution_payload", "block_hash"]) to create the inclusion proof of the the block_hash is in the ExecutionPayload in the BeaconBlockBody in the BeaconBlock. So we would have to reimplement all the Merkle proof logic (preferably in a similar generic way).
• ethereum-consensus has a nicer and more modular API.
• We only use those libraries to create the proof. As such even insecure libraries do not pose a security risk as in the worst case they fail to create a valid proof (similar to a faulty RPC or client implementation) but it is not possible to prove the wrong data.

Because of the last point in particular, that the guest verifier logic does not use these crates, it is acceptable to use a pinned reference to the https://github.com/ralexstokes/ethereum-consensus repo until a more actively maintained API client is available.