Simplify and modularize aggregate verifier + verifiers#201
Simplify and modularize aggregate verifier + verifiers#201roger-bai-coinbase wants to merge 139 commits intomainfrom
Conversation
…andling into a single function, improving code clarity and maintainability. Update tests accordingly to reflect the new verification structure.
…onventions for clarity in Nullify tests.
…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.
…date validation check to use this constant
…ier, updating documentation and logic to clarify its purpose as the L2 sequence number.
…rnal to public, enhancing accessibility for contract interactions.
…fier to emit event upon credit transfer
…er for consistency with internal function naming conventions.
…nsolidating the return statement for the first dispute game scenario.
* 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>
|
@roger-bai-coinbase Nit: would it be possible to add a description to the PR? I started reviewing it but ran into some difficulty understanding the objectives (particularly in light of all of the different considerations we've been discussing of late). |
Done |
🟡 Heimdall Review Status
|
|
|
||
| emit Proved(gameCreator(), proofType); | ||
| // Set the bond recipient to the creator. It can change if challenged successfully. | ||
| bondRecipient = gameCreator(); |
There was a problem hiding this comment.
So if a challenger counters successfully but the game never resolves, the challenger doesn't get the bond, right? This behaviour seems correct to me, but wanted to confirm expectations.
There was a problem hiding this comment.
How would the game never resolve after a successful challenge? By successful, I mean the challenge is not later nullified
There was a problem hiding this comment.
Yes, I mean if its later nullified. I suppose this is the same case as here, yes?
| // Update the expected resolution. | ||
| _updateExpectedResolution(); | ||
| // We purposely increase the resolution to allow for a ZK nullification. | ||
| expectedResolution = Timestamp.wrap(uint64(block.timestamp + SLOW_FINALIZATION_DELAY)); |
There was a problem hiding this comment.
To confirm, this enables TEE-only resolution following ZK nullification by reverting to the SLOW_FINALIZATION_DELAY timeout (thus potentially causing a total finalisation delay of up to 2 weeks), correct?
Again, this aligns with my expectations of the system, but want to confirm.
There was a problem hiding this comment.
Yes, but the theoretical finalization delay could be forever. E.g. Initialize with ZK -> nullify with ZK -> provide a TEE proof years later
There was a problem hiding this comment.
Sure, but assuming there's no bug in the TEE prover, and the collective Multiproving system is progressing on single-path TEE-only finality, then a TEE proof would need to be provided in order to enable L2 -> L1 finality to progress at all, no? Obviously if we transitioned to the permissioned game then this also wouldn't be relevant.
As I see it, this theoretical indefinite finalisation delay only applies if L2 -> L1 finality has altogether stopped progressing.
5 participants
Uh oh!
There was an error while loading. Please reload this page.