Espresso 2a: derivation pipeline, kona#449
Closed
QuentinI wants to merge 1 commit into
Closed
Conversation
…henticator Companion to celo-org#445 (which lands the equivalent op-node changes against celo-rebase-17). Introduces an L1-origin-timestamp hardfork (espresso_time) gating all post-fork derivation semantics. Pre-fork, derivation behaves exactly as upstream Optimism: batches are accepted based on the L1 transaction sender matching the SystemConfig batcher address. Post-fork, batches are authenticated via BatchInfoAuthenticated(bytes32) events emitted by the BatchAuthenticator contract, and sender-based authorization is rejected. The pipeline scans L1 receipts over a configurable lookback window (DEFAULT_BATCH_AUTH_LOOKBACK_WINDOW = 100 blocks) to build the set of authenticated batch commitment hashes for each L1 block being derived. Results are cached in two reorg-safe (block-hash-keyed) LRU caches: one for receipt-derived event sets, one for header parent-hash resolution. For consecutive L1 blocks the lookback windows overlap, so only one new block's receipts need to be fetched on each call. New RollupConfig fields: - batch_authenticator_address: Option<Address> - batch_auth_lookback_window: Option<u64> New HardForkConfig field: - espresso_time: Option<u64> New RollupConfig methods: - is_batch_auth_enabled - batch_auth_lookback_window (with DEFAULT_BATCH_AUTH_LOOKBACK_WINDOW fallback) - is_espresso_active (gated on L1 origin timestamp at the data-source layer) Calldata and blob data sources gain a BatchAuthConfig and an 'espresso_active' branch that requires an event-based authentication match; pre-fork their behaviour is unchanged. Unit tests cover the event scanner, calldata/blob hash semantics, post-fork authentication across calldata, blob, and altda data sources, and pre-fork passthrough. Co-authored-by: OpenCode <noreply@opencode.ai>
QuentinI
changed the title
|
Hi @QuentinI these changes should be made in https://github.com/celo-org/celo-kona. Our approach to modifications for the rust stuff is to wrap elements from the upstream repos. For instance inside celo-kona we have the celo-reth implementation that depends on components from op-reth and reth but we don't actually modify those components at source, we wrap them or duplicate them (if we have to) in celo-kona. |
|
Hi @QuentinI ! Just a friendly reminder about #449 (comment). We'd appreciate it if you could move these changes over to https://github.com/celo-org/celo-kona and reopen the corresponding PR. Thanks! |
Author
QuentinI
added a commit
to EspressoSystems/celo-kona
that referenced
this pull request
Jun 4, 2026
Add the `celo-derive` crate implementing the Rust (kona) companion to the op-node Espresso batch-authentication changes (celo-org/optimism#445), relocated from the vendored-kona PR celo-org/optimism#449 to follow celo-kona's wrap/duplicate-don't-patch model. Post-fork, batches are authorized by scanning L1 receipts for `BatchInfoAuthenticated` events from the configured `BatchAuthenticator` contract within a lookback window, instead of by transaction sender. Pre-fork (or when the fork is not yet active) derivation is byte-identical to upstream OP Stack. - `CeloEthereumDataSource` / `CeloCalldataSource` / `CeloBlobSource`: duplicates of kona's data sources with the auth branch folded in (kona's `CalldataSource`/`BlobSource`/`BlobData` internals are `pub(crate)` and cannot be wrapped). - `BatchAuthConfig` bundles the authenticator address, fork time and lookback window so the "fork scheduled but no authenticator" state is unrepresentable; `CeloRollupConfig::batch_auth_params` validates it and hard-errors on misconfiguration (otherwise derivation would silently stall at the fork boundary). - `CeloRollupConfig` gains the Espresso settings (parsed from the same rollup.json) and `CeloBootInfo` carries them through boot. - Point the hokulea git dep at celo-org/hokulea fccc98c (celo-org/hokulea#2), which generalizes `EigenDADataSource` over `DataAvailabilityProvider` so the eigenda path can wrap `CeloEthereumDataSource`. Co-authored-by: OpenCode <noreply@opencode.ai>
Author
|
@piersy @seolaoh Opened a PR at celo-org/celo-kona#206 |
Yep, that's unfortunately the price we pay for the modularity. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Companion PR to #445: adds derivation pipeline scanning for batch authentication events, gated by Espresso hardfork.