erigontech / erigontech/erigon

serving part of the engine API even when internalcl is enabled

Open
#12,064 1 comment 0 reactions 0 assignees View on GitHub
RPC
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.