erigontech / erigontech/erigon
serving part of the engine API even when internalcl is enabled
- Dominant language
- Go
- Stars
- 3.6k
- Forks
- 1.5k
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 455
Description
# Rationale
Geth has a very nice property: multiple CLs can connect to it, and everything just works. This was really great, when I was trying to figure out which CL matches my research requirements best, and I was able to sync them all up to head without running multiple ELs (as ELs consume terabytes on disk).
Unfortunately erigon doesn't have this functionality: "Caplin is enabled, so the engine API cannot be used. for external CL use --externalcl".
This is very inconvenient, because I already deleted the geth state from my disk (to make space for erigon), and now I find all kind of caplin rpc bugs, that I'm trying to fix, and there is no way to sync up a lighthouse or a prysm as an example, so I can see how other clients reply for an RPC that I'm considering bugged in caplin.
# Implementation
The implementation idea would be, that in a situation when caplin is enabled with `--internalcl` AND somebody is trying to use the Engine API with correct jwt credentials, then erigon EL should serve those parts of the Engine API that don't actually cause a state change inside erigon. We could call (and document) this as "read-only" engine api access.
All messages that somehow try to inform erigon about the current state of beaconchain, should be gracefully ignored.
Sorry for the vague explanation, I don't have the knowledge on the details of the Engine API and the CL+EL design to properply design this request.
The implementation should be considered successful, if prysm and lighthouse can sync with an erigon that is running with `--internalcl`.
Contributor guide
Assessment
This issue has not been assessed yet.