JWT Auth

[realbigsean]

How will MEV-boost handle auth for CL<>EL communication? https://github.com/ethereum/execution-apis/blob/main/src/engine/authentication.md

Seems like most requests could just be forwarded, but engine_forkchoiceUpdatedV1 will need to be sent to the relay. So I think MEV-boost will need to accept a jwt-secret to let it decrypt engine_forkchoiceUpdatedV1 before sending it to the relay.

[realbigsean]

Ok, so if I'm following the changes in this repo correctly, with #53 being merged, the idea is to completely remove mev-boost <> local execution engine communication? If that's the case then it seems fine not to worry about JWT with mev-boost because the purpose of JWT as I understand it is to make sure only a trusted CL controls the forkchoice of an execution engine. And the engine_forkchoiceUpdatedV1 here is being forwarded to the relay only to inform it of a proposer's fork

[lightclient]

@realbigsean I think mev-boost will still need to deal with JWT. Lighthouse does not support unauthenticated communication with EL any longer, so if users want mev-boost to drive it, there will need to be support for authenticated communication.

[realbigsean]

Thanks for the response @lightclient !

That's what I was thinking when I opened this issue. But all the calls from mev-boost to the execution layer were removed here, so mev-boost won't drive any communication to a local execution layer. I think limiting mev-boost's role to only payload construction (and not payload verification) is good, which that PR achieves.

The updates to the diagram here I think make the changes clear: https://github.com/flashbots/mev-boost/pull/57/files

The engine_forkchoiceUpdatedV1 call is still communicated to the relay through mev-boost, though. I would guess the relay just build payloads on top of whatever it is given, but I have no idea how it's being implemented (maybe the flashbots team can shed some light here). Maybe the threat of tampering with these calls warrants JWT for consensus layer <> mev-boost communication?

[lightclient]

Right, my mistake. Thanks for the correction. In that case, it does seem like authenticating the API is unnecessary as it can't be used to i) disrupt the fork choice or ii) cause the client to sign a block from an untrusted builder.

[metachris]

engine_forkchoiceUpdatedV1 is no longer communicated to the relay. Is JWT auth still needed for the current v0.2 spec?

[lightclient]

I don't think it is.

[metachris]

Closing this for now. Let's reopen if needed 🙏