Open merklefruit opened 2 months ago
We have this in reth: https://github.com/paradigmxyz/reth/blob/main/bin/reth-bench/src/authenticated_transport.rs
and we also have this: https://github.com/paradigmxyz/reth/blob/main/crates/rpc/rpc-layer/src/auth_client_layer.rs
ideally these should be upstreamed in alloy but the reth versions can be used for now
I'm actually not sure if we have engine_signalSuperchainV1
yet, need to check
Awesome, yeah I've seen it's the case even for the regular rollup RPC in #7. Nice 🙂
yeah I think the first step for this would be defining rpc types for each of the unimplemented APIs
I don't quite understand. Op-reth should have implemented these APIs. Can't we just reuse this code?
The rollup node is going to need to communicate with an L2 execution client through its exposed engine-api. The connection should happen with JWT authentication from a jwt secret file.
The engine API RPC client methods are (as described in the specs):
engine_forkchoiceUpdatedV2
/V3
engine_newPayloadV2
/V3
engine_getPayloadV2
/V3
engine_signalSuperchainV1
Ideally, 99% of the types necessary for this communication should be usable out of the box from
reth
.In terms of downstream usage (out of scope of this issue), the engine API communication will happen in the attributes processing step to signal the new presence of a new chain and have the engine validate the payload. Additionally, it will be needed during happy-case sync.