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

Toward an Ultralight execution client #732

Open
acolytec3 opened this issue Feb 12, 2025 · 2 comments
Open

Toward an Ultralight execution client #732

acolytec3 opened this issue Feb 12, 2025 · 2 comments

Comments

@acolytec3
Copy link
Collaborator

acolytec3 commented Feb 12, 2025

With the History Network close to something looking like fully implemented, the build out of support for both era and era1 files within our various monorepos, and the existence of similar efforts status-im/nimbus-eth1#2910, it's time we also think through what would be a useful implementation of an Ultralight EL client.

Things we could do

  • Implement full forward sync from chainstart (kind of boring and already done by Trin Execution)
  • Implement an EL client that uses checkpoint sync to quickly sync to the head of the chain
    This is interesting in that it allows for an "execution" client to quickly sync to the head of the chain without depending on the Beacon Chain (at least not directly as long as the Beacon Network bridges are operational)
  • A personalized EL client that takes something like the above checkpoint sync client plus a mobile app that stays in sync via UnifiedPush to provide a personalized EL experience that lets a user specify a wallet address and monitor it over time. Is this actually that interesting to anybody other than decentralization maxis since it only applies to mainnet?
    What else?

Options 1 and 2 should be relatively straightforward to implement. Just pick a sync strategy (forward sync/checkpoint sync) and then start fetching blocks monotonically or in batches. The structure of a client should be really simple, basically just an @ethereumjs/vm with a portalnetwork module in back pulling in the blocks for execution. There's probably more here since the vm expects a blockchain and other niceties that we'd have to account for but this should still probably be step one.
I'm not sure what else to put here but want to get this conversation started.

@ScottyPoi
Copy link
Collaborator

I have put a lot of thought into this concept as we have built Ultralight, and I'm eager to begin implementing it. Do you think this work should be done within the CLI package, or would this warrant its own package?

@acolytec3
Copy link
Collaborator Author

My initial instinct is a clean package without all the dross of our CLI tooling that's built so specifically to be hive compliant. The core portalnetwork module works pretty cleanly and I think the interesting bits are what we wrap it in that distinguish us from trin.

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

2 participants