* mise.toml: cleanup unused devnet tool dependencies

* op-supervisor: update devnet reference in readme

* refactor: using slices.Contains to simplify the code
Signed-off-by: pinglanlu <pinglanlu@outlook.com>

* op-batcher: reintroduce helper func to fix other usages

---------
Signed-off-by: pinglanlu <pinglanlu@outlook.com>
Co-authored-by: protolambda <proto@protolambda.com>

Signed-off-by: piguagua <piguagua@aliyun.com>

This change adds a "compilation" phase for devnet manifest.
Bottom line, we:

- treat the devnet manifest as a high-level specification of an
  expected deployment

- open up the possibility to generate an actionable input for an
  arbitrary deployer

- use kurtosis as a first target, by generating a valid kurtosis input
  that reflects the properties defined in the manifest

pkg/devnet/cmd/main.go is a toy tool to perform that last step.

Going forward, we could imagine a k8s deployment being "compiled"
following a similar process.
Or this being used during automated tests setup in order to create the
right target environment.

At a high-level, this is part of an effort to standardize our sources
of truth across the board.

Bumps [github.com/hashicorp/raft-boltdb/v2](https://github.com/hashicorp/raft-boltdb) from 2.3.0 to 2.3.1.
- [Release notes](https://github.com/hashicorp/raft-boltdb/releases)
- [Commits](https://github.com/hashicorp/raft-boltdb/compare/v2.3.0...v2.3.1)

---
updated-dependencies:
- dependency-name: github.com/hashicorp/raft-boltdb/v2
  dependency-type: direct:production
  update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* feat: Implement OPCM upgrade

* feat: better comment

* feat: Move vars to Setup where they belong

* gas snapshot

* feat: add OP_SUCCINCT game type

* fix: change OP_SUCCINCT to 5

* add ASTERISC_KONA

* op-challenger: Implement split adapter and trace accessor creation for super cannon

* op-challenger: Implement register task for super cannon

* op-challenger: Actually register super cannon game handler

* op-challenger: Lazy create clients

Make sync validator configurable per game type.

* op-challenger: Test split adapter

Remove ClaimTimestamp from ClaimInfo as we always use the poststate timestamp

Make sync validator configurable per game type.

* feat(op-challenger): Kona interop executor

* Add agreed prestate to `LocalGameInputs`

* super executor 🦸

* lint

Not currently used in the interop devnet as we're not yet deploying the new game type.

This is a convenience feature that allows a user to "enter" a devnet /
chain and get a subshell with relevant data (in particular env
variables).

The goal is to try an minimize the amount of error-prone log-browsing
and copy-pasting before being able to interact with the environment.

* op-chain-ops: op-run-block debug tool

* op-run-block: fix conflict with geth merge

* op-program: Implement retries in prefetcher block re-exec

* add canon block with error test case

* add comment on error case in rexec

* op-program: Implement consolidation for interop

* address todos; fix claim validation bug

* fix test

* fix todos

* op-program: Fix short-circuit logic in block walk

* op-program: Use l2-chain block fetcher in canon

* op-program: Fix current header in engine_backend

* op-program: Filter hazardrous exec msgs

* cleanup

* fix block cache lookup

* snap to earliest block and update tests
Co-authored-by: Adrian Sutton <adrian@oplabs.co>

* use adrian's suggestion

* todo formatting

---------
Co-authored-by: Adrian Sutton <adrian@oplabs.co>

Add prestate provider for super roots that can provide preimages.

* op-program: Stop derivation once the claimed timestamp is reached

* op-program: Add comment and switch to a panic if agreed is already after claimed

* use camel case for opcm outputversion var

* fix test

* rm entirely

* op-program: Build an interop prestate

The bootstrap process for interop is different so introduces a separate main method.

* op-program: Stop setting USE_INTEROP env var when running client in external process.

The interop version is used by specifying the interop client binary.
Update Makefile to build a native version of the interop client binary.

* wip: Walkback on conflict reset failures.

* tests: Add initial reset conflict tests.

* tweak: reorganize methods.

* Consolidate attemptReset into resolveConflict.

* tests: Add maxAttempts test.

* interop,tests: Add Emitter contract tests.

* simplify empty block addition

* Fix cross-safe progression.

* add cross safe assertion.

* Remove duplicate assertion.

* Make chains progress as the same rate.

Its only used by split adapter and isn't related to the contracts.

Makes RegisterTask generic enough to support interop games

This change is an attempt at bridging the gap between kurtosis devnets
and future alphanet/betanet specification.
(see ethereum-optimism/devnets#4)

It does so by defining specific override points in a more generic
template.
Generic building blocks are defined in templates/, and rely on a new
"include" capability at the template level.

This approach might also provide a somewhat lighter entry point for
user devnet definitions, following the same principle.

Note that this is completely optional at this point, and the full
scope of the kurtosis definition is still available to whomever
needs/wants it.

Bumps [github.com/bmatcuk/doublestar/v4](https://github.com/bmatcuk/doublestar) from 4.7.1 to 4.8.0.
- [Release notes](https://github.com/bmatcuk/doublestar/releases)
- [Commits](https://github.com/bmatcuk/doublestar/compare/v4.7.1...v4.8.0)

---
updated-dependencies:
- dependency-name: github.com/bmatcuk/doublestar/v4
  dependency-type: direct:production
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* op-challenger: Define the cannon-interop trace and game type.

Doesn't yet actually register a player for those game types.

* op-challenger: Define supervisor-rpc flag and require it for interop-cannon

* op-challenger: Do not require rollup-rpc for interop

* op-challenger: Require general cannon options for interop

* op-challenger: Update config validation for interop

* op-challenger: Rename to super cannon