tulip bluff
As I am testing a smart contract and only tinkering with the code that interacts with it (not changing the smart contract itself) I have to wait a long period of time for the compile stage, even though no changes have been made to the smart contract code.
Can I skip this step somehow between runs or somehow use the previous compiled result?
edgy kiln
you can do proofsEnabled: false in your LocalBlockchain
but that’ll run your code in JS only, therefore wont generate proofs
tulip bluff
I did this @edgy kiln but I am finding that compile still takes a long time. Are you suggesting If you have proofs off, can you skip that line as you won’t need to compile with no proofs?
edgy kiln
usually the practice is:
if (proofsEnabled) {
Contract.compile()
}
If you'll skip .compile(), you won't be able to generate actual proofs, but you can still test your code.
But beware, thats just testing 🏴☠️
rustic leaf
Matej's answer is what I'd recommend for testing.
Reusing a previously computed verification key from compile is doable, it's a base58 string that you can store on disk and only recompute when Contract.digest() changed. The zkapp CLI does that.
However, restoring the compiled result for proving is not supported yet, long-standing open issue that we never prioritized (shout if you think we should): https://github.com/o1-labs/snarkyjs/issues/87
rich rain
@rustic leaf can they be stored for verification? For instance could I throw a compiled proof on ipfs and have a frontend just grab that string and quickly verify proofs without compiling?
rustic leaf
Yes that should work! with the global verify() function that just takes the vk as base58 string
rich rain
That is excellent! Is there an example somewhere, or maybe just a unit test I could look at? My use case is with a zkprogram - so can I make an instance of my zk program using the serialized vk? Or would I pass the vk as I am calling verify() on my zk program?
rustic leaf
Now I remember this issue which sounds like it doesn't work 😬 https://github.com/o1-labs/snarkyjs/issues/427
rich rain
That’s what I thought… for a second Christmas came early 🙂
rustic leaf
We should definitely prioritize this - in principle this should work. Probably the SRS is expected to be stored and just has to be computed or something
rich rain
Off-hand... what's the crypto behind the compile-verify process? What I mean is could an attacker produce a verification key which makes a user think one thing is verified, but then a conflicting thing is also verifiable? Or if there exists a vk that can verify a circuit, can we safely believe that it is the only valid vk and it is legitimate?
In a main-net production environment, I could imagine a zkapp source repo similar to etherscan's contract source view where devs can share their apps and their vks, and frontends can use the vks to quickly verify proof results. But I'm not sure if importing that data in an untrusted way could ever be viable from a security standpoint.
edgy kiln
code -> prover key & verification key, so it cant happen that you’ll have code of a zkapp thats been maliciously modified that’d generate a proof, which could be verified by the original, correct and on-chain deployed verification key.
at least thats what the proof system should guarantee 🤔
prover key is just a term i heard, unsure how does the ‘prover’ look internally