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

protocol/platforms: project Greenlandian, archiving pre-Holocene blocks #213

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

protolambda
Copy link
Contributor

Description

Design-doc to start archiving L2 block data, to unblock the OP-Stack by removing pre-Holocene tech-debt.

Copy link
Member

@clabby clabby left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Big fan of this proposal.

fwiw - we do already have all pre-Holocene logic implemented over in kona, save for some of the in-progress work on the engine in the rollup node. So although giving the pre-holocene features a viking funeral would be super nice, not having this probably won't slow us down.

A blocker to this proposal might be the lack of universal support for the era1 format, though. iiuc, reth + op-reth doesn't support it. cc @mattsse

Copy link
Contributor

@ajsutton ajsutton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely makes sense and makes a lot of sense for an L2 given that deriving from L1 requires a separate archive anyway (due to blob expiry) so it makes a lot more sense for that archive to just be the result of derivation instead of the inputs.

I think we just need to flesh out the details of how we determine the correct block to use for bootstrapping - once the proofs incident response improvements are deployed, the AnchorStateRegistry would only update after the air-gap and would make a good reference but only provides a single value that will be at minimum 7 days old. It can be arbitrarily old (if there are no valid proposals) but it becomes challenging for fault proofs if it's more than 30 days old. In the worst case with an exorbitantly expensive DOS attack delaying games resolving it could be forced out to about 20 days old. That's probably still quite reasonable.

In terms of storing the era files, we will need to be careful they are being redundantly stored, particularly for smaller chains. It would be easy to wind up with only the chain operator storing the era files and accidentally losing them. That's not the end of the world but isn't ideal.
And if there's manual steps required to create the era files we need to think about how to manage that rollout, but it should just be writing up a runbook so not likely to be a blocker.

@protolambda
Copy link
Contributor Author

L1 era-store archives, and some lesser known file formats, for state-snapshots: https://eth-clients.github.io/history-endpoints/
Something like that can be done for L2s also.

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

Successfully merging this pull request may close these issues.

3 participants