Repository navigation
Conversation
palango
changed the title
2d586c1 to
fa87d53
Compare
palango
changed the title
Adding funding.json file required to apply for retropgf
github: use step-security replacement for tj-actions/changed-files
04abb81 to
45aa0cc
Compare
9c3f043 to
baf9878
Compare
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
palango
changed the title
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: baf987875e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "Consider updating proxy to a more recent version that contains https://github.com/Layr-Labs/eigenda/pull/1736: "+ | ||
| "%w", err) | ||
| } | ||
| invalidCommitmentErr.Validate() |
There was a problem hiding this comment.
When the configured DA endpoint returns HTTP 418 with syntactically valid JSON whose StatusCode is missing or outside 1–4, this call panics instead of returning an error. Proxy version skew or a malformed upstream response can therefore terminate every op-node that derives the affected commitment and repeat the crash after restart; validate the decoded value by returning a normal error so derivation can retry rather than killing the process.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Confirmed, Validate() panics on a status code outside 1-4. Fixed separately in #555 so this PR stays a plain rebase: the malformed 418 becomes an ordinary error that derivation retries, and it can't be mistaken for a drop.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1df6883bad
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| rust-e2e-gate-skip: | ||
| when: << pipeline.parameters.c-run_rust_e2e_gate_skip >> | ||
| # celo disable unwanted jobs/workflows — nothing requires the required-rust-e2e status | ||
| when: false |
There was a problem hiding this comment.
Do not hard-disable this skip workflow while rust-e2e-ci is also fixed to when: false at line 450. The repository ruleset requires a check named required-rust-e2e, so with both producer workflows disabled every PR is left waiting for a status that can never be reported; keep this always-succeed skip path enabled even if all Rust E2E jobs themselves remain disabled.
AGENTS.md reference: .circleci/AGENTS.md:L101-L105
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Nothing requires required-rust-e2e in this repo. There are no branch rulesets, and the branch protection on celo-rebase-18 lists no required status checks, so no PR waits on it. That rule in .circleci/AGENTS.md describes the upstream setup. I'll keep the check off the required list when celo-rebase-19 gets its protection.
Setting `open-pull-requests-limit: 0` prevent version updates but should keep the security scans and updates according to https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/configuring-dependabot-security-updates#overriding-the-default-behavior-with-a-configuration-file > If you only require security updates and want to exclude version > updates, you can set open-pull-requests-limit to 0 in order to prevent > version updates for a given package-ecosystem.
…kchain-public (#395) * Build op-node using docker-bake and push to devopsre/celo-blockchain-public registry * Set-Tags
It needs a kona version and I'm not clear what this is, but we don't actually use op-challenger so simply disabling it seems to be a good solution.
* Test attest images * Trailing line * Another job * auth * Release workflow attestation job
The op config set this to a private URL that we couldn't access, instead we now set this to now be the MAINNET_RPC_URL which is defined as a project env var.
Currently we set this to celo-rebase-15-upstream, but once we've constructed celo-rebase-15 we will want to set the base branch to that.
ethereum-optimism/circleci-utils is private to Optimism's org. Point both continuation configs at the public karlb/circleci-utils@1.0.27 fork so celo-org CI can resolve the orb.
gomod: Fix build after op-geth update Remove fee currency context from call of NewEVMBlockContext
… support The fault proof program and the Rust rollup config (kona-node, kona-host, op-reth) have no Celo support: they cannot parse the cel2_time field in the RollupConfig, so the single-chain and interop fault-proof acceptance tests and the kona/rust e2e CI jobs are skipped until Celo support lands.
Port of 958f0ce (Use config from celo's fork of superchain registry (#426)) and e3d03df (Update to an op-geth with superchain config lacking the gingerbread block (#428)). The op-geth now embeds valid celo superchain config from our fork of the superchain registry, so we can remove the hardcoded config overrides in applyCeloHardforks(). The Cel2Time field is now read from the superchain registry's HardforkConfig.
Point op-core/superchain at celo-org/superchain-registry, which carries Celo's configs on top of upstream. Regenerated the superchain-configs.zip bundle (gitignored) and its committed .sha256.
Introduces the on-chain BatchAuthenticator, the first piece of the Espresso integration. Batchers authenticate batch commitments here; the contract emits BatchInfoAuthenticated events that the forthcoming derivation pipeline scans from L1 receipts to decide batch authenticity. Re-host of #443. Contract (src/L1/BatchAuthenticator.sol, semver 1.2.0): upgradeable L1 contract with two batcher modes selected by activeIsEspresso — an Espresso/TEE path (caller must be the active espressoBatcher AND the signature must verify against the EspressoTEEVerifier) and a fallback path (caller must be the SystemConfig batcher, no signature). Owner rotates the espressoBatcher; guardian-or-owner flips the active mode. The espressoBatcher history is an append-only OZ Checkpoints.Trace160 keyed by L1 block, with a same-block guard so rotations can't overwrite history. registerSigner is permissionless, delegating safety to the TEE verifier. Adds IBatchAuthenticator, ~1100 lines of unit/fork tests, and TEE verifier mocks. Deploy: DeployBatchAuthenticator (standalone) and DeployEspresso (also deploys the TEE/Nitro verifiers), both using the transient-admin → initialize → changeAdmin-to-shared-ProxyAdmin pattern. Dependencies: adds espresso-tee-contracts (v1.3.0) and openzeppelin-contracts-upgradeable-v5 submodules, plus OZ v5 remappings — the repo now carries OZ v4 and v5 side by side. Cross-cutting: OZ v5 ships its own proxy/Proxy.sol, so every "Proxy" artifact reference across deploy scripts and tests is path-qualified to "src/universal/Proxy.sol:Proxy", and the Go getCode cheatcode now resolves directory-qualified names. CI/tooling adjustments: BatchAuthenticator grandfathered into the floating-pragma allowlist, Espresso interfaces excluded from the interface-ABI check, justfile/CircleCI tweaks to avoid OOM and solc auto-detect issues, and regenerated ABI/storage/semver snapshots.
Add Espresso event-based batch authentication. Adds derivation-pipeline support for the Espresso BatchAuthenticator contract, gated by a new L2-timestamp hardfork, EspressoTime. Pre-fork, derivation is unchanged from upstream Optimism (batch accepted iff the L1 sender is the SystemConfig batcher). Post-fork, batches are authenticated against on-chain events instead. Authentication. A batch is accepted post-fork only if a BatchInfoAuthenticated(bytes32 commitment, address indexed caller) event for its commitment was emitted by the BatchAuthenticator within a 100-block backward lookback window, AND the batch tx's L1 sender equals that event's caller — binding each batch to the address that authenticated it. The commitment is keccak256(calldata) for calldata batches and keccak256(concat(blobHashes)) for blob batches. Using event scanning (not L1 state reads) keeps derivation compatible with the op-program fault-proof environment. CollectAuthenticatedBatches scans receipts over [ref-100, ref], walking backward by parent hash, so the result is a pure function of ref's hash (independent of L1 tip, timing, or cache state). The fork gate is evaluated against the L1 origin time of the enclosing block (mirroring ecotoneTime) to keep a stable decision per L2 epoch. Both the calldata and blob sources gate each batch through isBatchTxAuthorized; the altDA path is covered transparently as it wraps them. Config adds EspressoTime and BatchAuthenticatorAddress; Check() requires a non-zero authenticator address when EspressoTime is set.
… ecotone_time (#466) * refactor(derive): drop dead Espresso calldata authentication path The calldata data source is only reached pre-ecotone: OpenData routes to the blob source whenever ecotone is active (ref.Time >= ecotone_time). Every Celo chain sets ecotone_time = 0, and Espresso (espresso_time) activates strictly later, so the Espresso event-based batch-authentication branch that #457 folded into DataFromEVMTransactions could never fire on a real chain. Restore the calldata data source to its pre-Espresso form. calldata_source.go is byte-identical to before #457; #457 had split isValidBatchTx into a type/To-only check plus isAuthorizedBatchSender to serve the blob source's event-based path, which rippled a needless change into the calldata source. Reinstate the original 5-arg isValidBatchTx (composed from isBatchTxToInbox + isAuthorizedBatchSender) and point the blob source at isBatchTxToInbox. calldata_source_test.go is also restored except for one line: DataSourceConfig gained fields (rollupCfg, batchAuthCaches), so its literal must use named fields instead of positional. The blob source keeps Espresso event-based authentication and also handles plain calldata-carrying batcher txs post-ecotone, so no behaviour is lost. Delete the now-dead Espresso calldata test and move its shared mockAuthEvents helper into the blob data source test, its only user. Mirrors the celo-kona removal (drop CeloCalldataSource, use upstream CalldataSource). * feat(rollup): reject espresso_time scheduled before ecotone_time Dropping the Espresso-aware calldata source made "espresso_time >= ecotone_time" a silent correctness invariant: Espresso event-based authentication now lives only on the post-ecotone blob path, so a block in the [espresso_time, ecotone_time) window would route to the pre-ecotone calldata source and silently fall back to sender-based authorization. Guard the invariant in Config.Check(): error with ErrEspressoBeforeEcotone when espresso_time is set but ecotone_time is unset or scheduled later than espresso_time. Every real Celo chain sets ecotone_time = 0, so this only fires on a misconfiguration -- but now it fails fast instead of corrupting derivation. Mirrors the celo-kona validate_espresso guard (EspressoBeforeEcotone). * test(derive): restore multi-tx event-auth coverage; review cleanups - add mixed-block and multi-commitment subtests to TestDataAndHashesFromTxsEventAuth, restoring per-tx commitment matching coverage lost with espresso_calldata_source_test.go - drop stale comment reference to the deleted TestDataFromEVMTransactionsForkBoundary - reuse u64ptr instead of a local ptr closure in TestConfig_Check_EspressoBeforeEcotone --------- Co-authored-by: Paul Lange <palango@gmx.de>
Makes the fallback (non-TEE) batcher authenticate each batch through the BatchAuthenticator contract before posting it to the batch inbox, so the post-Espresso derivation pipeline (event-based authorization) accepts fallback batches. Builds on #445; re-hosted from #448. op-batcher (fallback auth): - Gate authentication behind EspressoTime and a configured BatchAuthenticatorAddress (espresso_fallback_gate.go); pre-fork behaviour is unchanged. - Compute the batch commitment reusing the verifier's derive.Compute*BatchHash helpers, submit authenticateBatchInfo(commitment, "") ahead of the batch tx, watch both receipts, verify the auth landed within BatchAuthLookbackWindow, and emit one synthetic receipt so any failure re-queues the frames (fallback_auth.go). Calldata pairs pipeline; blob pairs serialise (blob vs calldata mempool exclusivity). - Wire dispatch into sendTx, drain in-flight watchers at shutdown, and add fallback_auth_window_exceeded_total / fallback_auth_reverted_total metrics. op-service/txmgr (ordered tx-pair primitive): - Add TxManager.SendPairAsync / Queue.SendPair to submit two dependent txs with adjacent nonces (auth first), cancel the second leg if the first fails, and fill both nonces with no-ops on failure to avoid wedging the account (pair.go, leg.go, queue.go, txmgr.go). One queue slot per pair. op-node (derivation enforcement): - Add BatchAuthEnforcementDelaySecs: a grace window (~one lookback window) after EspressoTime during which sender-based auth is still accepted, after which the batch commitment must appear in a BatchInfoAuthenticated event within BatchAuthLookbackWindow and the batch sender must equal the event caller (data_source.go, blob_data_source.go, batch_authenticator.go, params.go). Replaces the earlier batcher-side lead-time flag. Other: - Include espresso/ in the op-stack-go Docker build context. - Tests: fallback-auth ordering/revert/window/boundary/commitment-parity, the fork-boundary gate, txmgr pair (success, first-leg failure, revert, parent cancel, pipelining), and the derivation enforcement boundary.
* Espresso: enforce calldata-only DA post-fork (Least Authority Suggestion 4) The Celo fault-proof host (celo-kona) does not implement the L1Blob preimage hint, so an authenticated blob batch — while accepted by full nodes — would stall fault-proof execution at its L1 block. The spec declares blob DA unsupported (DEC-op-026/n-026), but until now that was an operational restriction only. Enforce it in code, at two layers: - Derivation pipeline (consensus): from Espresso activation onward (including the auth-enforcement grace window), dataAndHashesFromTxs drops blob-carrying inbox transactions before any authorization check, so post-Espresso derivation never requires blob preimages. This covers op-node and the Go op-program alike, since they share the derive package. Pre-fork semantics are unchanged (upstream behavior). - Batcher startup (operational): refuse to start with a blob or auto data-availability type when EspressoTime is scheduled, instead of letting verifiers silently drop every blob batch after activation and stalling the safe head. This makes the existing blob-pair headroom check in checkFallbackAuthConfirmations unreachable in practice; it is kept as defense in depth. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * op-node: hoist the Espresso activation check out of the tx loop Espresso activation is a property of the scanned L1 block's origin time, so evaluate it once alongside the enforcement check rather than per transaction. * op-node: correct the dataAndHashesFromTxs doc comment The pre-enforcement paragraph claimed upstream Optimism semantics for the whole function, including the grace window, which the calldata-only rule below it contradicts. Scope it to authorization, state the inbox filter once, and order the rules as the code applies them. * op-node: note that the blob batch-hash arm is dead post-Espresso Blob txs only get past the calldata-only drop pre-Espresso, where authorization is sender-based and never reads the batch hash. Record why the arm stays rather than folding into the calldata one. * op-batcher: record that the fallback-auth blob path is unreachable checkEspressoDataAvailability runs first and rejects the only configuration checkFallbackAuthConfirmations bounds, so the check cannot fire and the serialized blob send path cannot run. Keep both, and say so in the code. * espresso: scope the blob-preimage guarantee to post-fork L1 blocks Derivation's drop only covers blocks at or after espresso_time; the pre-fork blocks a proof walks back through are covered by the batcher gate, which keys on espresso_time being set rather than active. Say why that asymmetry stays. * op-batcher: state what a dropped blob batch actually costs Not an indefinite safe-head stall: derivation forces empty batches once the sequence window expires, and the verifier reorgs the unsafe chain away. * op-node: correct what the batch hash helpers claim about the contract authenticateBatchInfo takes an opaque bytes32 and has no calldata or blob validation path; the encoding is agreed off-chain. Note that the blob helper has no live caller while calldata-only DA is enforced. * op-batcher: note sendFallbackAuthSerialized has no reachable caller * op-batcher: mark the tests that pin configurations the batcher won't start Three TestCheckFallbackAuthConfirmations cases, the five tests built on testBlobCandidate and the blob parity subtest all describe blob DA, which checkEspressoDataAvailability rejects. Keep them, but say so. * espresso: cover the factory blob path and a scheduled-but-inactive batcher TestOpenDataDropsBlobsPostEspresso drives NewDataSourceFactory through OpenData and Next with Espresso enforced, asserting a blob inbox tx triggers no blob fetch; the bare MockBlobsFetcher fails the test if one is issued. TestCheckEspressoDataAvailability gains a future espresso_time, the input that distinguishes the batcher's scheduled-or-active gate from an activation check. * op-node: put the blob tx first in the mixed-block sub-test With the calldata batch first, the sub-test passes whether the gate uses continue or break: the blob tx is last, so a whole-block short-circuit costs nothing observable. Putting the blob tx first makes break swallow the calldata batch behind it and fail. Matches the ordering celo-kona's mirror of this test uses. --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: Paul Lange <palango@gmx.de> Co-authored-by: Paul Lange <palango@users.noreply.github.com>
collect-params.sh piped the changed-file list into `grep -q` under pipefail. grep exits on the first hit, so once the list exceeds the pipe buffer the writer gets SIGPIPE (141) and the hit counts as a miss: every path pattern reports false and the docs-only check reports true, so the pipeline skips all test workflows and the gates pass. Feed grep a here-string instead.
Upstream switched op-e2e's default L2 EL to op-reth (3a7401b), but Celo's execution rules live in celo op-geth; this repo's op-reth is upstream's. Under op-reth, TestFees fails because base fees go to the BaseFeeVault instead of the FeeHandler. OP_E2E_L2_EL_KIND=op-reth still selects op-reth explicitly.
SP1, cannon, interop and the ZK dispute game have no Celo deployment, and the rust e2e release build and sysgo binaries only fed acceptance tests already disabled.
Upstream moved to shell-less chainguard/static, but Celo's charts and the node docker-compose start op-node, op-batcher and op-conductor through /bin/sh scripts.
Since v1.19.x the op-stack-go Dockerfile regenerates superchain-configs.zip from the submodule, which a plain checkout leaves empty.
The sequencer goroutine writes unsafeHead under e.mu while the driver event loop reads it unlocked. Same fix as #554 on celo-rebase-16.
Builder images run GOTOOLCHAIN=local, which ignores the toolchain line, so only the go line keeps a builder off Go releases without the GO-2026-4870/5037 fixes.
Upstream moved the proof action tests under rust/, which go-tests excludes, so Celo's FeeHandler/L1Block and the derivation assertions stopped running.
Images reported v0.0.0 in metrics, logs and healthz because no workflow set GIT_VERSION. Release builds now use the tag, branch and PR builds v0.0.0-<sha8>, and both add OCI version and revision labels. Manual release runs fail unless started from a tag.
1df6883 to
948bbd4
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 948bbd4d5c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - name: Resolve image digest | ||
| id: digest | ||
| run: | | ||
| digest="$(crane digest "${{ inputs.image_name }}:${{ inputs.image_tag }}")" |
There was a problem hiding this comment.
When a user able to dispatch this workflow supplies an image_name or image_tag containing shell syntax such as $(...) or a closing quote, GitHub substitutes it into this script before Bash parses it, allowing arbitrary commands to run after the job has obtained the GCP access token. Pass both inputs through env: and reference the quoted environment variables in this step; the later Echo step has the same interpolation problem.
AGENTS.md reference: .github/AGENTS.md:L231-L232
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
True, the inputs go straight into the script. This workflow isn't new though: the file is identical to the one on celo-rebase-18, and only people with write access can dispatch it, so it gives them nothing they don't already have. Passing the inputs through env: is still the right fix. It's on the infra list rather than in this rebase.
| attestations: write | ||
| artifact-metadata: write | ||
| steps: | ||
| - uses: 'google-github-actions/auth@v2' |
There was a problem hiding this comment.
This newly added job grants OIDC and attestation write permissions, then invokes the authentication action through the mutable v2 tag; moving or compromising that tag gives the replacement code the job's cloud credentials and registry access without any repository change. Pin this and the other third-party actions in the job to reviewed full commit SHAs.
AGENTS.md reference: .github/AGENTS.md:L228-L230
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Same as above, the file is unchanged from celo-rebase-18. The mutable tags are in all three Celo Docker workflows, so pinning them to SHAs is one job across backfill-attest.yaml, docker-build-scan.yaml and docker-publish-release.yaml. Also on the infra list, not changing it here.
karlb
left a comment
karlb
left a comment
There was a problem hiding this comment.
Looks good. The open codex comments refer to pre-existing issues AFAICS and should not block the rebase.
No acceptance job ran on this branch. op-geth is the only L2 EL here with Celo's changes; the devstack skips Karst chains on it, so only tests pinned up to Jovian run. The kona-sp1-proposer tests are skipped: no Celo support.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1cb6f332fc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| espressoTEEVerifier = _espressoTEEVerifier; | ||
| systemConfig = _systemConfig; | ||
| activeIsEspresso = _activeIsEspresso; |
There was a problem hiding this comment.
When a future implementation bumps initVersion(), initialize becomes callable again during an upgrade and these assignments overwrite the live verifier, SystemConfig, and active mode; the preceding __OwnableWithGuardians_init can likewise reset ownership and emit another ownership event. Only the batcher history is protected, so stale upgrade parameters can silently change who is allowed to authorize batches. Preserve the operational state on reinitialization or add the required @notice explaining why every overwrite and repeated initializer side effect is safe.
AGENTS.md reference: packages/contracts-bedrock/AGENTS.md:L30-L32
Useful? React with 👍 / 👎.
| func (f *finalized) L1BlockRefByNumber(ctx context.Context, num uint64) (eth.L1BlockRef, error) { | ||
| l1Finalized := f.l1Finalized() | ||
| if num == 0 || num <= l1Finalized.Number { | ||
| return f.L1Fetcher.L1BlockRefByNumber(ctx, num) |
There was a problem hiding this comment.
When --sequencer.use-finalized is enabled after the chain already has an unsafe head on a non-finalized origin, or the initial finalized-head RPC request fails, L1OriginSelector.CurrentAndNextOrigin resolves that current origin through L1BlockRefByHash. This wrapper only overrides the number lookup, so the embedded fetcher's hash lookup bypasses the finalized-height guard and the sequencer keeps producing blocks on the non-finalized origin until it needs a successor. Override the hash lookup and reject references above the tracked finalized height, or fail startup until finality is known.
Useful? React with 👍 / 👎.
| c.TxFailed(id) | ||
| if failoverToEthDA { | ||
| // We failover to calldata txs because in altda mode the channel and channelManager | ||
| // are configured to use a calldataConfigManager, as opposed to DynamicEthChannelConfig | ||
| // which can use both calldata and blobs. Failover should happen extremely rarely, | ||
| // and is only used while the altDA is down, so we can afford to be inefficient here. | ||
| // TODO: figure out how to switch to blobs/auto instead. Might need to make | ||
| // batcherService.initChannelConfig function stateless so that we can reuse it. | ||
| c.cfg.DaType = DaTypeCalldata |
There was a problem hiding this comment.
With altda.max-concurrent-da-requests > 1 and target-num-frames > 1, an earlier multi-frame request can return 503 while later grouped requests are still in flight. This path deletes only the failed grouped ID, rewinds its frames, and switches subsequent resubmissions to single-frame calldata IDs; successful later grouped IDs remain in pendingTransactions, while their cached commitments can never be selected because altDAFrameCursor is still waiting at the failed index and calldata confirmations do not advance it. Consequently isFullySubmitted never becomes true and the channel stalls. Failover must invalidate or reconcile every later in-flight grouped request and cached commitment before resubmitting as calldata.
Useful? React with 👍 / 👎.
|
Published: this branch is now |
This moves Celo's optimism fork from
op-node/v1.18.2(celo-rebase-18) toop-node/v1.19.9, and moves Celo op-geth to finalv1.101702.3. It's the same Celo patch set as rebase-18, minus what upstream absorbed, plus the fixes this rebase needed. Those fixes are folded into the commits they belong to, so review per commit. Every commit that touches Go passesjust lint-goandjust build-goon its own.op-geth (
palango/celo-rebase-19-v1.101702.3@c69d62ac3)v1.101702.3-rc.1onto finalv1.101702.3.waitForNodesdeadlock fix (p2p/discover: decouple nodeFeed from Table mutex in waitForNodes ethereum/go-ethereum#34898).release/celo-v2.2.xbranch).optimism
op-node/v1.18.2toop-node/v1.19.9; op-geth pinned toc69d62ac3.espresso:.d5c88aa2(upstream08d6a449merged in, stale Celo owner addresses fixed in Merge upstream 08d6a449 and fix Celo owner addresses superchain-registry#10).go 1.26.5floor restored in go.mod (builders runGOTOOLCHAIN=local); the kona cannon prestate image moved to Go 1.26.5 with it.EngineController.UnsafeL2Head()takes the read lock (live race now that the sequencer runs on its own goroutine).KONA_HOST_PATHis unset), so Celo's FeeHandler/L1Block assertions run again.op-service/log(new depguard rule); batcherLog.Critcalls becameshutdownOnCriticalError.memory-all-opn-op-geth, about 15 minutes). The devstack skips Karst chains on op-geth, so only tests pinned up to Jovian run: 29 passed and 214 skipped in the first green run. Full coverage needs celo-reth as the test EL (celo-org/celo-blockchain-planning#1462).Remaining before publish
celo-rebase-19andcelo-rebase-19-upstreamin optimism and op-geth.celo-rebase-19(last commit's codecBASE_BRANCH,BASE_REVISION, semgrepdiff_branch).Before rollout
--rollup.load-protocol-versionsremoved,--l2.enginekindnow defaults to reth,--syncmode.offset-el-safenow defaults to 12h.v1.7.0before it queries a rebase-19 op-node (cross_unsafe_l2leftSyncStatus).NODE_TYPE=minimal, stop hard-coding the op-node image tag.op-node --version. Images now setGIT_VERSION(the tag on releases,v0.0.0-<sha8>on branch builds); branch builds are checked, the release path isn't until a tag is built.