Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    benjaminstrasser
    @benjaminstrasser
    I commented on Zokrates/ZoKrates#513 and want to ask if my approach would be correct.
    marinthiercelin
    @marinthiercelin
    Hello, I was wondering what would be the fastest way, given a verification.key file, and the address of a deployed contract, to check that the contract is indeed a legitimate verifier contract with the correct key ?
    marinthiercelin
    @marinthiercelin
    Also, is anyone else getting a warning : Function state mutability can be restricted to view whenever compiling the verifier.sol file generated by zokrates export-verifier ?
    Thibaut Schaeffer
    @Schaeff
    @marinthiercelin how about running export-verifier on that verification key, compile (with the same compiler) and compare bytecodes?
    marinthiercelin
    @marinthiercelin
    @Schaeff yes indeed that would work, although I would need to be careful to replace the libraries with the deployed addresses in the bytecode.
    marinthiercelin
    @marinthiercelin
    Hello, I have created an issue Zokrates/ZoKrates#519 on github regarding an error I encoutered when using the verifier contract
    Anyone has time to try to reproduce the error ? I would like to know if the error only comes from my setup or if it comes from Zokrates.
    Edi Sinovcic
    @edisinovcic
    @marinthiercelin it's a problem with current version of ganache, it worked on older versions...
    Can you try to downgrade ganache?
    benjaminstrasser
    @benjaminstrasser
    https://eips.ethereum.org/EIPS/eip-1108
    It looks like on-chain verification is going to be even cheaper :D
    marinthiercelin
    @marinthiercelin
    @edisinovcic I have tried with ganache-cli versions 6.7.0 through 6.1.0 and get the same error. npm doesn't know any versions below 6.1.0
    Genysys
    @Genysys

    Hi,

    I am trying to compile zokrates with libsnark but hit errors. To get it to work, I have had to disable super cop.

            let libsnark = cmake::Config::new(libsnark_source_path)
                .define("WITH_SUPERCOP", "OFF")
                .define("WITH_PROCPS", "OFF")
                .define("CURVE", "ALT_BN128")
                .define("USE_PT_COMPRESSION", "OFF")
                .define("MONTGOMERY_OUTPUT", "ON")
                .define("BINARY_OUTPUT", "ON")
                .build();

    It compiles with some warnings. Is it ok to use it like this?

    Genysys
    @Genysys
    Also when i do this, it fails to generate the proof:
    ./zokrates generate-proof
    Generating proof...
    WARNING: You are using the G16 scheme which is subject to malleability. See zokrates.github.io/reference/proving_schemes.html#g16-malleability for implications.
    thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: InvalidData, error: CoordinateDecodingError("x coordinate", NotInField("0x31330a3056d7b72c29d20e98b531ff5cf308021c4f465547175f3877dcd31b3f")) }', src/libcore/result.rs:1165:5
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
    Genysys
    @Genysys
    I am attempting this on a Mac OSX Mojave
    nevermind .. I for to add the proving scheme flag to the generate-proof subcommand
    Genysys
    @Genysys
    also is it worth submitting a PR that checks if the os is Darwin and adds .define("WITH_SUPERCOP", "OFF”) ?
    Thibaut Schaeffer
    @Schaeff
    Hi @Genysys using libsnark on macos is currently untested in ZoKrates, if you found a way that would be welcome, yes!
    Genysys
    @Genysys
    Will do.. if it doesnt need super code then the PR is one line.. does Zokrates explictly require it?
    Thibaut Schaeffer
    @Schaeff
    I don't think so, but I remember making libsnark work on macos was harder than that, never worked for me somehow scipr-lab/libsnark#86
    Genysys
    @Genysys
    Yes that how i got it to compile! I Tried it with zokrates and went through installing it manually and figured out the delta
    Thibaut Schaeffer
    @Schaeff
    And does it setup and prove fine? I remember being able to build it but it would crash when hitting the prover
    Genysys
    @Genysys
    all fine
    was trying to answer this so tried it end to end
    it would panic at the proover if you dont add the correct flags
    Genysys
    @Genysys
    also some openssl gotcha.. when you install homebrew , most people for to link the flags properly and you enter dependency nightmare
    also you might need to adjust this : https://travis-ci.org/Zokrates/ZoKrates/jobs/621537185#L52
    Genysys
    @Genysys
    I have a question re: Groth 16; is it possible to get rid of malleability issues by applying a ristretoo group or will it only work for curve 255519?
    Thibaut Schaeffer
    @Schaeff
    @Genysys yes my issues are with libcrypto
    Genysys
    @Genysys
    Re-install open ssl and dont ignore the instructions after
    Thibaut Schaeffer
    @Schaeff
    the malleability in g16 does not depend on the underlying curve, it's the scheme itself which make it trivial to derive another proof from a valid one
    Genysys
    @Genysys
    brew reinstall openssl

    ah thanks!

    the malleability in g16 does not depend on the underlying curve, it's the scheme itself which make it trivial to derive another proof from a valid one

    Genysys
    @Genysys
    lastly what are the trade offs between using the g16, gm17 and pghr13 back ends?

    https://zokrates.github.io/reference/proving_schemes.html#g16-malleability

    Thanks for this.. where can i read more about the justification for the suggested solutions?

    Genysys
    @Genysys
    super!! Thanks alot!
    Thibaut Schaeffer
    @Schaeff
    We don't have any more details at the moment, but the intuition is that you want to either use a non-malleable scheme, or require more than a proof: for example, a proof where your public key is a public input, along with a signature with that public key.
    Genysys
    @Genysys
    I might have the wrong mental model for this, but if its a public key then wont it be trivial for the adversay to add it too?
    Thibaut Schaeffer
    @Schaeff
    the adversary could produce a different-but-valid g16 proof exposing the same public key, but couldn't create a signature for that public key
    and you would have your verifier require both
    Genysys
    @Genysys
    The night fall repo has interesting discussions around tackling this : EYBlockchain/nightfall#235
    benjaminstrasser
    @benjaminstrasser
    @Schaeff I looked a bit more into #513 and wrote some basic setup. I have some questions on what is the best strategy to compose the verification key and proof.
    1. I assume that the format for them changes depending on what proofing sheme was used. Is that assumption correct ? If yes composition has to be done like serialization ing g16 and not like witness serialization/composition ?
    2. Is there anything I might have overlooked that already implements the composition of the proof and verification key ?
    Thibaut Schaeffer
    @Schaeff
    Hey @benjaminstrasser!
    We are making some changes to the backend API, the latest version is on this branch https://github.com/Zokrates/ZoKrates/blob/wasm-friendly/zokrates_core/src/proof_system/mod.rs and it does have something to hold both proving key and verification key
    basically we changed from having the backend write to a file to returning the value to the rust side
    I guess this API could be extended with verify(proof: &str, vk: &str) -> (bool) which then calls each backend
    You're right to assume that the format depends on the backend, bellman and libsnark are not compatible there
    benjaminstrasser
    @benjaminstrasser
    @Schaeff
    Great this looks excatly like what I have already done. I'll just move eveything over and branch off from wasm-friendly to use the new backend. Thanks for the help and I'll come back to you if I have more questions.
    Thibaut Schaeffer
    @Schaeff
    Great sounds like a plan