Skip to content

feat(CHAIN-3293) Migrate Multiproof Contracts to base/contracts#196

Open
jjtny1 wants to merge 120 commits intomainfrom
joby.thundil/CHAIN-3293-migrate-multiproof-contracts-to-basecontracts
Open

feat(CHAIN-3293) Migrate Multiproof Contracts to base/contracts#196
jjtny1 wants to merge 120 commits intomainfrom
joby.thundil/CHAIN-3293-migrate-multiproof-contracts-to-basecontracts

Conversation

@jjtny1
Copy link

@jjtny1 jjtny1 commented Feb 28, 2026

This PR migrates the contracts from https://github.com/base/multiproof-dispute-game to base contracts.

Multiproofs depend on a modified version of the DisputeGameFactory that takes arguments in the initialize constructor. This is done through a git patch found in multiproof_tests/optimism.patch. Because this patch is needed for the tests to pass, we keep all multiproof tests in the the multiproof_tests folder and use a foundry profile to trigger it. This is abstracted into a make command: make test-multiproof

…andling into a single function, improving code clarity and maintainability. Update tests accordingly to reflect the new verification structure.
…ild game in AggregateVerifier. Implement corresponding test case to verify this behavior.
…d rollup configuration. Update verification methods to use a journal hash instead of root claims. Modify MockVerifier and tests accordingly.
…ier, updating documentation and logic to clarify its purpose as the L2 sequence number.
…rnal to public, enhancing accessibility for contract interactions.
…er for consistency with internal function naming conventions.
…nsolidating the return statement for the first dispute game scenario.
@jjtny1 jjtny1 force-pushed the joby.thundil/CHAIN-3293-migrate-multiproof-contracts-to-basecontracts branch from 0f84ac7 to 76335ba Compare March 2, 2026 05:45
@jjtny1 jjtny1 force-pushed the joby.thundil/CHAIN-3293-migrate-multiproof-contracts-to-basecontracts branch from 9efb20a to ee8c3b9 Compare March 2, 2026 16:37
@jjtny1 jjtny1 requested a review from jackchuma March 3, 2026 03:12
* Replace onchain Nitro cert verification with Automata ZK verifier, add ISemver to multiproof contracts, wire SystemConfigGlobal into standard deploy pipeline

* Integrate multiproof config into standard DeployConfig, fix TEEVerifier proof format to match AggregateVerifier's l1head change

* Fix fmt

* Replace aws-nitro-enclave-attestation submodule with no-git dependency in Makefile

* Consolidate deploy configs: migrate dev scripts to standard DeployConfig, add multiproof fields to sepolia.json and hardhat.json, remove separate nitro config files

* Regenerate snapshots for updated and new multiproof contracts

* Fix Initializable test: guard ETHLockbox entries for non-interop deploys, exclude AggregateVerifier (uses custom bool instead of OZ _initialized)

* Add test-multiproof recipe to Justfile for CI

* Address PR feedback: extract GameType local var, stricter pubKey check, iterate PCRs, add nitroEnclaveVerifier to Input, revert sepolia.json owner, remove redundant CI recipe

* Resolve merge conflicts and regenerate semver-lock snapshots

* Regenerate semver-lock with CI profile for correct bytecode hashes

* Regenerate semver-lock with all compiler profiles including dispute

* Regenerate semver-lock.json to remove stale dispute profile entries

* Fix misleading TEEVerifier comment, require nitroEnclaveVerifier in deploy config, and parameterize hardcoded l2ChainID/block intervals in DeployImplementations

* Reset semvar versioning in SystemConfigGlobal

* Regenerate semver-lock.json for SystemConfigGlobal and TEEVerifier changes

* correct SystemConfigGlobal.t.sol testInitialization() test cases to check correct version() number

* use a proof threshold and allow ZK proofs after TEE nullification (#199)

* use a proof threshold and allow ZK proofs after TEE nullification

* pr feedback

* update deployment scripts and tests

* allow tee nullfiication when a zk proof exists. extend timestamp in this case to allow for zk nullification

* Fix stack-too-deep in DeployImplementations and regenerate semver-lock

* add multiproofProofThreshold to DeployConfig.s.sol to fix CI failures

* Correct semver comment

* Regenerate semver-lock following fix

---------

Co-authored-by: roger-bai-coinbase <roger.bai@coinbase.com>
@cb-heimdall
Copy link
Collaborator

Review Error for leopoldjoy @ 2026-03-05 22:42:40 UTC
User cannot review their own commit

sourceFilePath = path
contractName = name
contractKey = sourceFilePath + ":" + name
if strings.HasSuffix(file, ".dispute.json") {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the reason is because forge build produces an artifact per compiler profile (code) for some contracts.

This results in a non-deterministic generation of the semver.json file. When searching through forge-artifacts sometimes the default compiler profile is picked up and sometimes it's the dispute profile optimization. The contract key doesn't differentiate between these profiles so on different runs it produces different hashes.

This causes the CI tests to be non-deterministic.

This fixes the issue by checking if we are using the dispute optimized code and adds that to the contract key stored in the json

GameType.unwrap(ANCHOR_STATE_REGISTRY.respectedGameType()) == GameType.unwrap(GAME_TYPE);
}

function initializeWithInitData(bytes calldata) external payable { }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this here if it's empty?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It needs to be implemented since this contract inherits IDisputeGame and we added this function for the AggregateVerifier

@@ -21,6 +21,7 @@ additional_compiler_profiles = [
{ name = "dispute", optimizer_runs = 5000 },
]
compilation_restrictions = [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are a bunch of compilation restrictions changed for contracts that are not relevant to multi proofs?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this was the tricky part with getting CI to pass.

Our multiproof contracts, directly import (or indirectly) import these contracts. This causes the forge compiler to produce 2 artifacts (one per compiler profile).

Having more than 1 artifact causes the following error:

  1. semver is non-deterministic (see comment above)
  2. vm.getCode (or vm.getDeploymentCode) cheatcodes cause tests to fail because they pick up different artifacts. An example of this is the VerifyOPCM tests. When the OP contracts are deployed, they are deployed with the code from default profile. When the tests are run, the call to vm.GetCode picks up the dispute optimized profile. This results in 2 different bytecodes so the bytecode comparison check fails.

The fundamental issue here is that the disputecompiler profile causes forge to compile multiple artifacts for a single contract (one optimized the other not). From what I can tell, the reason this error shows up now is because our multiproof contracts somehow trigger different compilations per profile so more than one artifact is created.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im not sure if there is a way for us to tell forge "only use the default compiler profile or optimized one". By adding these contracts, we force these contracts to only use the optimized version

@@ -153,6 +163,7 @@ additional_compiler_profiles = [
{ name = "dispute", optimizer_runs = 0 },
]
compilation_restrictions = [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here regarding compilation restriction changes

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see comment above

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants