feat(op-acceptance-tests): l2cm upgrade accaptance tests and fork tests on karst betanet by 0xCoati · Pull Request #20668 · ethereum-optimism/optimism

0xCoati · 2026-05-12T09:42:43Z

Description
Ability to run fork tests on karst betanet, add acceptance tests for withdrawal. L2 Fork test for checking the existence of the deterministic-deployment-proxy.

Tests
mise exec -- just test -run TestWithdrawal_Karst ./op-acceptance-tests/tests/karst/

Running L2ForkUpgrade.t.sol with a betanet

export L2_FORK_RPC_URL=<url>
export L2_BLOCK_BEFORE_FORK=<previous blockNumber before activation>
just test-post-karst-betanet-l2-fork-upgrade

Additional Context
Setting up a karst betanet is required for running the tests this way.

Metadata

fixes #18870

…imal upgrade with l2cm

… and add flags to support running against betanet

0xiamflux · 2026-05-12T16:39:35Z

        // Skip if not L2 fork test
        skipIfNotL2ForkTest("L2ForkUpgrade: not a fork test");

        // Skip if L2CM dev feature is not enabled


Shouldn't we also check for KARST_BETANET_L2_FORK_TEST before skipping L2 Forked tests? Setting KARST_BETANET_L2_FORK_TEST=true would still just silently skip these.

wouldn't the L2CM feature flag be true on the karst betanet?

Sorry, I meant the check above: skipIfNotL2ForkTest("L2ForkUpgrade: not a fork test");

I see. Probably better to adjust the justfile so L2_FORK_TEST=true is set too for the test-karst-betanet-l2-fork-upgrade task? There are quite a few places were we rely on l2ForkTest / isL2ForkTest.

That sounds good.

actually it's already done, because test-karst-betanet-l2-fork-upgrade starts with prepare-l2-upgrade-env which does set L2_FORK_TEST. I removed a redundant check here 1971c09

0xiamflux · 2026-05-12T17:07:50Z

 		upgradeGas += nutGas
 	}

+	if ba.rollupCfg.IsCustomNUTActivationBlock(nextL2Time) {


I don't think we should add test-only code in here.

0xiamflux · 2026-05-12T17:18:03Z

    function _executeCurrentBundle() internal virtual {
-        PastNUTBundles.ForkWrappers memory w = PastNUTBundles.wrappersForFork(currentFork);
-        PastNUTBundles.executeWithWrappers(executeScript, w.pre, _currentBundleTxns(), w.post);
+        if (!isKarstForkActivated()) {


Why do we need to skip if Karst is activated? In post-karst upgrades we still want to take chains that are in an "older" state up-to-date so we can execute the NUTs in the current bundle.

This reverts commit 329e54d.

…ng a minimal upgrade with l2cm" This reverts commit 9782ee9.

…k test due to PastUpgrades handling it already

…he deterministic deployer

0xOneTony · 2026-05-13T13:17:16Z

/ci authorize da9943e

0xOneTony · 2026-05-13T13:45:54Z

/ci authorize 331ce17

0xiamflux · 2026-05-14T15:59:04Z

/ci authorize 96f15bc

0xiamflux · 2026-05-14T17:32:22Z


    /// @notice Executes the current generated NUT bundle with any fork-specific wrappers.
    function _executeCurrentBundle() internal virtual {
        PastNUTBundles.ForkWrappers memory w = PastNUTBundles.wrappersForFork(currentFork);


I think I see this more clearly here, it should be able to skip the current bundle if it's already applied not only if karst is applied:

if (_isCurrentBundleAlreadyApplied()) return;

…rrent bundle is applied

…with before/after blocknumbers and capture events from the activation block

0xiamflux · 2026-05-18T22:36:30Z

-        return vm.envString("KARST_BETANET_L2_FORK_RPC_URL");
+    /// @notice Returns the L2 block after the fork.
+    function l2BlockAfterFork() internal view returns (uint256) {
+        return vm.envOr("L2_FORK_BLOCK_NUMBER", uint256(0));


I would think it should be an error to either attempt to use this on a non-activation test or try to use it during a activation test while it is 0. wdyt?

fixed in fff70c2

0xiamflux · 2026-05-18T22:49:08Z


-test-karst-betanet-l2-fork-upgrade-rerun *ARGS:
+test-post-karst-betanet-l2-fork-upgrade-rerun *ARGS:
  just test-karst-betanet-l2-fork-upgrade {{ARGS}} --rerun -vvvv


Shouldn't this be also updated to match test-post-karst-betanet-l2-fork-upgrade?

fixed in fff70c2

…terFork revert outside l2CMActivationTest

lumoswiz · 2026-05-19T08:09:50Z

+    /// @notice Returns the L2 block after the fork.
+    function l2BlockAfterFork() internal view returns (uint256) {
+        if (l2CMActivationTest()) {
+            return vm.envOr("L2_FORK_BLOCK_NUMBER", uint256(0));


I think this needs to be fixed before merge.

The justfile documents L2_BLOCK_AFTER_FORK, but this reads L2_FORK_BLOCK_NUMBER and defaults to 0. I assume 0 is meant to preserve the existing "use latest" behaviour from the normal L2 fork setup. But activation mode passes this value directly to createSelectFork(url, block), so following the documented command makes the post upgrade fork select explicit block 0, not latest or the intended after fork block.

Could we do one of the following:

Read a mandatory L2_BLOCK_AFTER_FORK

Keep 0 as latest and have _executeCurrentBundleOrSwitchFork() call createSelectFork(url) overload when this returns 0?

The pre/post activation flow can become:

Fork at L2_BLOCK_BEFORE_FORK

Capture pre upgrade state

Fork at block 0

Verify post upgrade state

fixed in d292e28 and e05e520

…after activation block number

lumoswiz · 2026-05-19T09:40:06Z

+                address(0),
+                topics
+            );
+            logs = _ethGetLogsToLogs(ethLogs);


Currently the L2CM activation path only checks the historical Upgraded(address) logs. That doesn't prove the activation block contained the expected NUT bundle txns.

Can we also assert that the activation block contains the expected activation bundle txns? Otherwise missing, reordered, or corrupted upgrade txns could still be missed if the expected upgrade logs are present.

0xOneTony · 2026-05-19T12:36:14Z

/ci authorize e05e520

0xCoati added 5 commits May 7, 2026 09:58

test(withdraw-post-karst): acceptance test for withdrawing on karst

0179e8a

test(acceptance-test-l2cm-karst): add acceptance test for doing a min…

9782ee9

…imal upgrade with l2cm

test(karst-fork-tests): skip upgrade executing when already on karst,…

a118a9c

… and add flags to support running against betanet

test(acceptance-test-l2cm-karst): make the test proper e2e

329e54d

Merge branch 'develop' into test/l2cm-upgrade-accaptance-test

0a8fe52

0xiamflux reviewed May 12, 2026

View reviewed changes

0xiamflux mentioned this pull request May 12, 2026

[L2CM Upgrades] Devnet acceptance testing #18870

Open

3 tasks

0xCoati added 5 commits May 13, 2026 10:25

fix(acceptance-test-l2cm-karst): remove redundant flag check

1971c09

Revert "test(acceptance-test-l2cm-karst): make the test proper e2e"

a12f6d0

This reverts commit 329e54d.

Revert "test(acceptance-test-l2cm-karst): add acceptance test for doi…

e2eb850

…ng a minimal upgrade with l2cm" This reverts commit 9782ee9.

fix(acceptance-test-l2cm-karst): remove karst activation check in for…

81bcb09

…k test due to PastUpgrades handling it already

test(acceptance-test-l2cm-karst): add test to check the presence of t…

da9943e

…he deterministic deployer

0xOneTony changed the title ~~l2cm upgrade accaptance tests and fork tests on karst betanet~~ feat(op-acceptance-tests): l2cm upgrade accaptance tests and fork tests on karst betanet May 13, 2026

fix(acceptance-test-l2cm-karst): fix testname lint error

331ce17

fix(acceptance-test-l2cm-karst): remove misleading comment

96f15bc

0xCoati marked this pull request as ready for review May 13, 2026 20:34

0xCoati requested review from a team and wwared May 13, 2026 20:34

0xCoati requested a review from a team as a code owner May 13, 2026 20:34

0xiamflux reviewed May 14, 2026

View reviewed changes

0xCoati added 2 commits May 15, 2026 14:51

fix(acceptance-test-l2cm-karst): skip execute and events test when cu…

7cd0a82

…rrent bundle is applied

fix(acceptance-test-l2cm-karst): rework betanet upgrade test to work …

71506e6

…with before/after blocknumbers and capture events from the activation block

0xiamflux reviewed May 18, 2026

View reviewed changes

fix(acceptance-test-l2cm-karst): fix rerun command and make l2BlockAf…

fff70c2

…terFork revert outside l2CMActivationTest

lumoswiz reviewed May 19, 2026

View reviewed changes

fix(acceptance-test-l2cm-karst): fix usage example

d292e28

fix(acceptance-test-l2cm-karst): add missing latest fallback for the …

e05e520

…after activation block number

lumoswiz reviewed May 19, 2026

View reviewed changes

Conversation

0xCoati commented May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xOneTony commented May 13, 2026

Uh oh!

0xOneTony commented May 13, 2026

Uh oh!

0xiamflux commented May 14, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xiamflux May 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xOneTony commented May 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

0xCoati commented May 12, 2026 •

edited

Loading

0xiamflux May 18, 2026 •

edited

Loading