-
Notifications
You must be signed in to change notification settings - Fork 273
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
A problem in gadget split_base
#1421
Comments
splite_base
split_base
split_base
split_base
I think the assert! makes big numbers in the But if we change the code: assert!(
num_bits <= log_floor(F::ORDER, 2),
"{} bits may overflow the field",
num_bits
); to assert!(
num_bits <= log2_ceil(F::ORDER as usize),
"{} bits may overflow the field",
num_bits
); And create a And set the target in the witness to any number larger than I think the restriction in the BaseSumGate is the reason. |
You are right that Goldilocks field elements with 64 bits are not reachable with this gadget, but we want to make sure it's impossible to overflow and this is only possible by rejecting 64 bit vectors altogether. |
Yeah, in my case I need to prove the calculation of In order to do the converting, I transfer the Anyway, luckily, I have solved this problem today, without any changed to the The compromised solution is that, I generate a target with the first 63 bits, and add it to a constant target with the value `` 1 << 63` if the highest bit is 1. If you have any better idea of this case, please let me know. Thanks~ |
Ok great, will close this then. |
If we use
le_sum
to convert a bits target(Vec<BoolTarget>
) to a field target (just a Target related to aGoldilocksField
), some values of the GoldilocksField will be invalid.That is, we cannot set the target with the values in
[2^63, 0xFFFFFFFF00000000]
.The order of a GoldilocksField is
0xFFFFFFFF00000001
The text was updated successfully, but these errors were encountered: