Help

[anton-sa]

Hi, I tried to implement a sample application using libsbnark, snarklib or snarkfront. unfortunately I don't understand where in the examples the logic is (the program what is sent by the generator). If I have understood it correctly defines the program using DSL?

I want check a computing by Libsnark, similar to the (pay-as-you-drive example) from the paper (ADSNARK: nearly practical and privacy-preserving proofs on authenticated data)

Could you help me?

With kind regards Anton

[jancarlsson]

I will help. First, I have to read the ADSNARK paper to know the pay-as-you-drive example. That won't take long.

Yes, you understand correctly. The program is built with the DSL. This defines the constraint system and relates the cryptographic key pair, input/witness, proof generation, and verification.

Note that snarkfront does not currently support libsnark as a back-end. The snarkfront DSL uses snarklib only. snarklib has no run-time relationship with libsnark. snarklib is derived from the technology in libsnark but is effectively an independent fork.

[jancarlsson]

This will be some work. The ADSNARK code is not publicly released (although available by request). That makes it harder. Fortunately, the construction is detailed in the research paper. I have to read some of the references, though.

Signed data, either by "generic construction" or using the ADSNARK approach, implies different trust models and network effect performance tradeoffs. That's clear from the benchmarks. This is what interests me - more choices.

What may be tricky is reconciling these different constructions behind the same DSL.

I make no promises. After reading the ADSNARK paper, I believe the issue merits consideration. It is an important use case.

[anton-sa]

Thanks for your answer! If i understood you correctly, corrently i can't use the library for my use case?

[jancarlsson]

If your use case requires the AD-SNARK construction, then you must use the modified libsnark code which incorporates the homomorphic MAC signatures and other changes. At present, snarklib does not support this construction.

If your use case requires the AD-PGHR construction, then you probably can use either libsnark or snarklib/snarkfront. The arithmetic circuit handles signatures "generically" as part of the constraint system.

My guess is your use case requires the AD-SNARK construction.

Signed inputs are important. I plan to incorporate both AD-PGHR and AD-SNARK constructions in snarklib/snarkfront. That won't happen for a few weeks at least, though. If you need to get something done soon, then you should go with the modified libsnark code (available on request from the scientists).

One more thing - perhaps it appeared that snarkfront could be the front-end DSL over libsnark as the ZKP back-end. Even if that support were available today, the ADSNARK modifications to libsnark would force changes on snarkfront (even if localized). It could not work out of the box without additional work.

[anton-sa]

what do you mean with modified (libsnark) code? is the code on (github.com/scipr-lab/libsnark) not up to date?

[jancarlsson]

From "ADSNARK: Nearly Practical and Privacy-Preserving Proofs on Authenticated Data" page 31:

"We have implemented our ADSNARK scheme as an extension to the libsnark library... The source code is available upon request."

I take this to mean the ADSNARK source code has not been released under an open source license. There is nothing wrong with that. The ADSNARK and libsnark research teams are not related. Everyone is free to (not) publish what they want, theory or code.

[jancarlsson]

This may be small consolation. I am still working on this. The first step I take is porting the supercop ed25519 ref implementation. That is for the AD-PGHR implementation (not what you really want).

A few weeks ago, the SHA-2 and AES code was moved out of snarkfront into cryptl. This issue motivated the refactoring. The ed25519 implementation will also go into cryptl.

I expect what you want will be available in a few months. I know that is discouraging. There are other issues which are too important not to put them first.

[anton-sa]

thanks for your feedback!

best regards anton

[reischuk]

Please note that ADSNARK is now an official part of libsnark: https://github.com/scipr-lab/libsnark

[jancarlsson]

Thanks. Your note motivates a decision.

libsnark should be a back-end for the snarkfront EDSL. This is what most people would want. A year ago, this was not possible. The libsnark library was too unstable. I was forced to fork it as snarklib.

A few months ago, the last time I had looked at it, libsnark had completely changed. The code looked excellent. It is better optimized and easier to understand than the code in snarklib (probably too much template metaprogramming). There's really no reason to maintain a parallel fork now.

I will look into adapting snarkfront to use libsnark as a back-end. That also means the EDSL should not break compatibility with libsnark. A developer should be free to use snarkfront as a high-level language extension with libsnark when expedient. I don't like API lock-in.

[jancarlsson]

I had forgotten how very different libsnark and snarklib are philosophically as regards software engineering. libsnark specializes code during preprocessing (i.e. choice of elliptic curve). snarklib does this at compile time with templates (can use Edwards and BN in the same binary). The right thing to do is create a new stub library which adapts libsnark as a "third way". That means supporting both libsnark and snarklib under snarkfront.

ADSNARK reduces costs. That is most important. Economics matters.

Perhaps most important, I should keep my promise to anton-sa and get this done.