feat(rpc): Engine API - Githubissues

merklefruit commented 3 weeks ago

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.

Rjected commented 2 weeks 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

merklefruit commented 2 weeks ago

Awesome, yeah I've seen it's the case even for the regular rollup RPC in #7. Nice 🙂

Rjected commented 2 weeks ago

yeah I think the first step for this would be defining rpc types for each of the unimplemented APIs

GrapeBaBa commented 2 weeks ago

I don't quite understand. Op-reth should have implemented these APIs. Can't we just reuse this code?

paradigmxyz / op-rs

feat(rpc): Engine API #11