feat: sharding of global challenge phase commitment and opcode proving #695
Conversation
lispc
changed the title
| @@ -90,33 +92,59 @@ impl<E: ExtensionField, PCS: PolynomialCommitmentScheme<E>> ZKVMProver<E, PCS> { | |||
| } | |||
| exit_span!(span); | |||
|
|
|||
| // TODO: is it better to set different size of different opcode? | |||
There was a problem hiding this comment.
Yes, I think so. Why choosing 1048576 here?
| @@ -90,33 +92,59 @@ impl<E: ExtensionField, PCS: PolynomialCommitmentScheme<E>> ZKVMProver<E, PCS> { | |||
| } | |||
| exit_span!(span); | |||
|
|
|||
| // TODO: is it better to set different size of different opcode? | |||
| let shard_size = 1048576; | |||
There was a problem hiding this comment.
This might be easier to read in hex. (Because it's not just a random number.)
| // TODO: (1) is it ok to store mle? (2) replace tuple with struct? | ||
| #[allow(clippy::type_complexity)] | ||
| let mut wits_and_commitments: BTreeMap< | ||
| String, |
There was a problem hiding this comment.
What's the meaning of the key here? A type synonym might be useful here?
| let mut commitments = BTreeMap::new(); | ||
| let mut wits = BTreeMap::new(); | ||
| // TODO: (1) is it ok to store mle? (2) replace tuple with struct? | ||
| #[allow(clippy::type_complexity)] |
There was a problem hiding this comment.
Perhaps use some type synonym or so?
| @@ -61,10 +61,11 @@ impl<E: ExtensionField, PCS: PolynomialCommitmentScheme<E>> ZKVMVerifier<E, PCS> | |||
| does_halt: bool, | |||
| ) -> Result<bool, ZKVMError> { | |||
| // require ecall/halt proof to exist, depending whether we expect a halt. | |||
| // TODO: make it less adhoc | |||
There was a problem hiding this comment.
Especially once we support more ecalls. Or perhaps we should introduce a specific 'halt-successfully' introduction.
ceno_zkvm/src/witness.rs
Outdated
| @@ -107,6 +110,42 @@ impl<T: Sized + Sync + Clone + Send + Copy> RowMajorMatrix<T> { | |||
| }) | |||
| .collect() | |||
| } | |||
|
|
|||
| // TODO: should we consume or clone `self`? | |||
There was a problem hiding this comment.
If it's natural to consume self, then do so. The caller can clone.
| @@ -471,6 +478,17 @@ impl<E: ExtensionField, PCS: PolynomialCommitmentScheme<E>> ZKVMVerifier<E, PCS> | |||
| } | |||
|
|
|||
| // verify zero expression (degree = 1) statement, thus no sumcheck | |||
| for (expr, name) in cs | |||
There was a problem hiding this comment.
this logic seems some left over. probably we combine with line 492?
The sharding in first layer circuit is quite simple. While sharding+recursion-circuit will be where most magic happens.
Pending designs:
OpcodeProofstruct as a vector of shard proofs?TODOsinside the PR.Other notes:
into_mleinput is 8xSHARD_SIZE. It is as expected related to some FAN_IN mle parameter.Perf (MBP M3)