-
Notifications
You must be signed in to change notification settings - Fork 125
Eip 4844 #125
base: main
Are you sure you want to change the base?
Eip 4844 #125
Conversation
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.
Looks good! I like that we have both positive & negative test cases. I added a couple of preliminary questions before the final review, to sync about some points
@@ -0,0 +1,3 @@ | |||
|
|||
target/ | |||
Cargo.lock |
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.
optional nit: since this is a binary endpoint, we don't necessarily have to ignore the cargo lock. ref
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html | ||
|
||
[dependencies] | ||
halo2_proofs = { git = "https://github.com/mabbamOG/halo2.git" } |
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.
Any reason why we are not using the main remote? Might be beneficial to leave a comment of what is blocking and requiring a fork
/// in a single commitment on the EVM, which can then be opened using EVM precompiles. | ||
/// If the same data is also used in the zkEVM circuits, then the two are linked and the ZKP constraints are validated | ||
/// over the same data. To prove that the same data is used in the zkEVM circuits, we could either do a commitment-equivalency | ||
/// test over thta data, or just take the witness data directly and make a function evaluation over it, which is what a KZG |
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.
typo thta
/// | ||
/// APPROACH: | ||
/// We are going to be implementing the above formula to at the same time interpolate and evaluate over many points | ||
/// of a polynomial. The computations need to be performed in a different field, which is why we make use of Halo2wrong. |
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.
consider adding context on why it needs to be performed in a different/non-native field
integer_config: IntegerConfig, | ||
} | ||
|
||
/// W is the wrong field, N is the native field |
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.
wrong
does make sense under the halo2wrong
context, but might be a bit confusing without this prior
nbits, | ||
} = self.witness_values; | ||
|
||
// 0. JUT MAKE SURE X IS NOT IN THE ROOT-OF-UNITY DOMAIN (otherwise formula doesn't work) |
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.
It's a matter of code style, but I usually don't perform non-constrained checks inside of a circuit. a malicious prover would just remove this code, and this adds overhead to honest provers. If we need to validate input data, we might want to do that a step before the circuit instantiation, also to help the user to debug potential errors.
Ok(assigned_d_i) | ||
}) | ||
.collect::<Result<Vec<_>, Error>>()?; | ||
assert!(assigned_datapoints.len() == NUMBER_OF_POINTS); |
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.
Ditto; consider using debug_assert
.collect::<Result<Vec<_>, Error>>()? | ||
.try_into() | ||
.unwrap(); | ||
let assigned_x2is: [AssignedInteger<W, N, NUMBER_OF_LIMBS, BIT_LEN_LIMB>; 256] = |
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.
Question: do we need to allocate the entire x2is
array? We use the powers only for the bits that aren't enabled
|
||
const NUMBER_OF_POINTS: usize = 4096; | ||
|
||
fn main() { |
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.
It's unclear why we have a main function testing hardcoded values. Maybe move this to a test case?
} | ||
|
||
#[test] | ||
#[should_panic] |
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.
Instead of panic, it might be better to expect a specific error variant, as the panic might be happening for reasons different than the expected. I believe MockProver
will return error variants pointing to the constraint that failed - so we can be sure it is the right one
Reopening PR because of mistake, previous PR: #106
Description
This PR adds the circuit required to integrate Taiko with EIP 4844. Basically it takes data stored in the circuit and uses it for function evaluation. This is then compared with the blob opening checked in the smart contract with EIP 4844. Make sure the data fed into this circuit is checked to be the same as all the other claims of the proof.
Issue Link
#37
Type of change
Contents
Contain the new circuit as well as dependencies which support the latest traits along with the latest halo2curves (hence the breaking change...but the circuit has not been integrated into the rest of the zkEVM so everything compiles for now)
Rationale
Required for the L2 to make use of EIP 4844 Blobs, greatly improving costs for publishing new proofs
How Has This Been Tested?
unit tests