-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: implement challenger proving fault with zkVM proof #386
Conversation
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. 🗂️ Base branches to auto review (2)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
3c9fe21
to
ef26c20
Compare
ef26c20
to
bb39b82
Compare
if err != nil { | ||
return nil, fmt.Errorf("failed to fetch proof and pair(fault position blockNumber: %d): %w", targetBlockNumber.Uint64(), err) | ||
} | ||
proofResult, err := c.cfg.ZkVMProofFetcher.GetProof(ctx, blockHash, l1Head) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't the zkVM prof response take a long time?
If the proof fetch timeout occurs, it will repeat the request again from witness.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, now challenger does not have to wait for the prover response with maintaining HTTP connection. Since the prover JSON-RPC interface has been changed like this, challenger can just send request and then continuously fetch the status of request processing. You can see the reflected changes of challenger logic in the code!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you also update the gas snapshot result?
* feat(contracts): revive `getChallenge` method of `Colosseum` * feat(validator): prove fault with witness generator, zkVM prover * feat: verify zkVM program verification key * fix: launch kroma-challenger in devnet * chore(contracts): update bindings and snapshot * feat: use rpc client for proof fetcher, witness generator
Description
Implemented challenger to prove fault with zkVM proof for outputs after Kroma MPT time. There are some changes to the validator flags like below.
VALIDATOR_CHALLENGER_POLL_INTERVAL
[REQUIRED] ->VALIDATOR_CHALLENGE_POLL_INTERVAL
[OPTIONAL]VALIDATOR_PROVER_RPC
[OPTIONAL] ->VALIDATOR_CHALLENGER_ZKEVM_PROVER_RPC
[OPTIONAL]VALIDATOR_FETCHING_PROOF_TIMEOUT
[OPTIONAL] ->VALIDATOR_CHALLENGER_ZKEVM_NETWORK_TIMEOUT
[OPTIONAL]VALIDATOR_CHALLENGER_ZKVM_PROVER_RPC
[OPTIONAL]VALIDATOR_CHALLENGER_WITNESS_GENERATOR_RPC
[OPTIONAL]