Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

serving part of the engine API even when internalcl is enabled #12064

Open
errge opened this issue Sep 22, 2024 · 0 comments
Open

serving part of the engine API even when internalcl is enabled #12064

errge opened this issue Sep 22, 2024 · 0 comments

Comments

@errge
Copy link
Contributor

errge commented Sep 22, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant