ZoKrates relies on this library for proof verification, where you'll find calls to the precompiles
Also, I was under the impression that EIPs of numbers 196, 197 and 1108 were referring to precompiled EVM opcodes as primitives for skSNARKs computations, but what you provided us with was a series of pre-written solidity contracts that are exported based on the type of the zkp scheme used via zokrates export-verifier command.
Yes, depending on the scheme you're using, different on chain libraries are required. The central one is the one I linked to above, and it calls the precompiled contracts introduced by the EIPs you just mentioned. Note that only verification happens on chain, proof generation happens off chain.
That's right, but I cannot find the addresses like 0x06 or 0x07 for , respectively,ECADD and ECMUL, as specified by EIPs 196 and 197. How does zorates calls these underlying opcodes?
in def main(u8[64] input) -> u8[64]: ...
Hi all, it's been a while :)
What's the most efficient way to check for underflows / overflows?
E.g. If I have a = b + c, what's the neatest way to ensure b + c doesn't overflow the field modulus?
E.g. If I have a = b - c, what's the neatest way to ensure b > c?
E.g. If I have a = b * c, what's the neatest way to ensure b * c doesn't overflow the field modulus?
E.g. If I have a = b / c, is there a way to ensure c 'divides' b in the 'integer' sense? Like passing a, b, c as inputs and asserting that c * a == b and ensuring c * a doesn't overflow the field modulus (somehow)?
Presumably I'd need to do the calculations in bits, to check for bits 'carrying over' 2**253?
Does anyone have any neat implementations? :)
Disabling this was easy enough and tests still pass so I guess that's fine. I am wondering if this can be disabled when compiling (a .zok) though, as it can be limiting for some use-cases. For example, I'm working on a program that batch checks and updates a merkle tree. Depending on the position of the leafs I have a different number leafs and proof hashes. By using some booleans and padding I was able to build this in a way that works for a large number of leaf combinations all in the same program. However, this required passing variables which are never used, which is prevented by the unconstrained variable checks. Maybe that's something to consider.
", in "https://zokrates.github.io/language/imports.html" mean that I can import an ASCII file, if so can I perform a hash on it as well ? Also if it is possible to give some sample code which can help in this regard. Hoping to hear soon.
Hi all,
I’m working on a bit of an edge case where I need to check if a field is a positive number by doing either assert(field > 0) or assert(field < (field_prime-1)/2). The problem here is that ZoKrates implements comparison operators such that the operands have to be strictly less than biggest power of 2 lower than p/2. Let’s take the example of Bn128, the operands here will have to be lower than 2^252 even though the field elements can be greater than 2^252 and lower than bn128_prime of 2592827839077369332604021086610909215435616943586837466384278596745456903517. So assert(field > 0) would fail during compute witness stage if field passed into witness is greater than 2^252 but less than bn128_prime. Andassert(field < (bn128_prime-1)/2) would fail at compile stage because (bn128_prime-1)/2 is already greater than 2^252. Can this limitation be worked on in ZoKrates’s rust code ? Thank you
x < constant check, the one we have now is x < y for x and y both variables. We already use it internally (here https://github.com/Zokrates/ZoKrates/blob/master/zokrates_core/src/flatten/mod.rs#L204)
