ethereum-optimism / design-docs

MIT License
26 stars 20 forks source link

Add Holocene design doc #72

Closed sebastianst closed 1 month ago

sebastianst commented 2 months ago

Description

Holocene design doc, to align on open questions.

Additional context

After getting alignment, the specs can be completed. They are currently in draft at https://github.com/ethereum-optimism/specs/pull/357

This has been reviewed in a public design review session on 2024-09-11, with a public recording.

tynes commented 2 months ago

One thing to consider here is that we have generally assumed that the batcher will not be malicious and submit batches that are expensive for derivation to process. This assumption can work well for a single chain that has a single sequencer, but in the world of interop the finality of a single chain becomes tied to the finality of another chain. This means that it could be possible for a batcher of a remote chain to influence the cost of proof generation for the local chain. This means that we need to start thinking about untrusted batchers in the context of interop.

There will be some reputation at play since the interop set will be managed by governance, but we should generally strive to minimize the amount of reputation required for security. This just means that we don't need to ship the absolute most denial of service proof thing in the world as the first iteration.

sebastianst commented 2 months ago

Further public discussion in Discord made us reconsider the idea of deriving invalid batches as empty batches. The new proposal is to simply drop invalid, and future, batches, and instead only derive invalid payloads at the engine stage as deposit-only payloads. An invalid payload wouldn't trigger the generation of future empty batches, but instead just forward-invalidate any remaining batches and the origin channel.

sebastianst commented 2 months ago

I think this design doc is now is "good-enough" state and that we can merge it, so we can move towards the actual development work for holocene.

@BlocksOnAChain The design changed significantly due to the async discussions after the design session. I want to first finish the spec, then adapt the design doc so it can serve as a historical reference, before we merge it.

BlocksOnAChain commented 2 months ago

I think this design doc is now is "good-enough" state and that we can merge it, so we can move towards the actual development work for holocene.

@BlocksOnAChain The design changed significantly due to the async discussions after the design session. I want to first finish the spec, then adapt the design doc so it can serve as a historical reference, before we merge it.

@sebastianst Got it, made sense to me. I was just reviewing the current state, before the last edits and after we chatted on discord. fully agree.