Interesting ZK App Concepts like Privacy & Offchain execution - is my understanding correct?

[fresh inlet]

Are the following statements expressed correctly:

1. User input to a smart contract can be kept private due to zk proofs rather than the fact that the smart contract is executed in the zk app client and not on the blockchain.

2. the fact that smart contracts are executed in the zk app client, makes it so that the gas fees required to send transactions to the blockchain should not change much regardless of the complexity of the transaction.

3. what about the smart contract code? is there a way for other blockchains to read your smart contract code through the verification key or any other means?

4. What other data is private in a zk app transaction besides the user input?

[dire drift]

1. Actually its both, proof + client side execution = privacy = no need to share 'private input' to the contract / prover

2. (??? i think ???) there's a formula in the protocol that allows you to calculate the cost of the transaction, here's more information https://github.com/MinaProtocol/MIPs/blob/main/MIPS/mip-zkapps.md#fees-and-queueing

3. To create a proof (to execute a smart contract method) you need the actual contract code (to compile into a prover), but to verify (on the chain side) you dont need the smart contract code, only the verification key. I'd guess its not possible to go back from the verification key to the prover, like with hashing (but someone else must confirm this on the math side cc @rough summit)

4. Better question, or an easier one to answer would be what is public? If you console.log tx.toPretty() you'll see all account updates that were created by your smart contract(s) in that tx, that gives you a nice picture of what is exposed publicly. But thinking about it again.. what's private is any private input (all arguments) of your smart contract.

[fresh inlet]

thanks so much for helping to clarify these points! based on what you said for 3. I'd say the smart contract code is not public (thus private) - would you agree @rough summit?

4. ooooh thanks so much for this method! It's a great way to show what's public and conversely, what's private - like the user input/zk proof method paramters!

[rough summit]

@fresh inlet
Re 2., the answer is yes - the fact that execution happens on the client is the main reason that we have flat fees
the cost function that @dire drift shared is not expected to affect tx fees (and also, as you can see its very flat & doesn't depend on the size of the computation done on the client)

@fresh inlet I confirm that you can't, in practice, go back from the verification key to the smart contract code. However, I don't think its fair to say that the smart contract code is "private". Creating the verification key does not involve any secrets or other stuff that hides the code, so its not protected from brute-force attacks in a strong cryptographic sense . You could start from an empty contract and try to brute-force-adding simple statements, and this has a reasonable chance of recovering simple verification keys.

Probably the main reason for the verification key to be a hash, rather than a full representation of the prover code, is succinctness / efficiency, not protecting the source code. (But still, in practice, it protects the source code)

[dire drift]

good points gregor, i also think its fair to mention that to get the VK you probably always need to compile (?) which takes time so its difficult to brute force unless you have the computational power

[fresh inlet]

Thanks Gregor, that makes sense! The source code being "protected" is a more a side-effect than the intent. Can the same be said for state that's stored in a merkle tree? It's encrypted for efficiency but doesn't mean one couldn't brute force their way into figuring out the merkle elements? (Though the difficulty increases as the height of the tree grows.)

[dire drift]

yes

[crisp drum]

I understand that code obfuscation could be useful in some instances, but probably most use cases involve code that not only isn't obfuscated, but also ubiquitously available through clients that need the code to make transactions, or published so people can actually audit the application, right?

[rough summit]

In the case of a Merkle tree, a very common scenario is indeed that the content of the Merkle tree should remain private. For example, If you'd build something like Tornado Cash and the Merkle tree contains UTXOs. In that case, the zkapp developer would make sure to use a proper cryptographic scheme where the Merkle leafs hide the data, i.e. they are computed as a hash of the private data plus some secret that only the user who owns the data can access.
Built-in nullifiers will make something like this fairly easy (nullifiers are designed to protect the identity / public key of the user who creates them)

But yeah, in general terms Merkle trees hash the data into one field element for efficiency, so it's a good analogy 🙂

[rough summit]

I agree, the general idea for zk smart contracts is that everybody can call these methods and create proofs, and for that they must be able to download the code, so it can't be obfuscated

[fresh inlet]

Ah I see, do you think that it would be worthwhile to create a tutorial for this? How to keep smart contract state private via Merkle Trees & Encryption?

[fresh inlet]

and on this note - smart contract input is 'private' by default unless that input is then stored as a state on the blockchain. It would be interesting if users could know whether or not their input is being stored as state so they can know if the 'privacy' guarantees are maintained.

Or alternatively(/inclusively), some guidelines that help developers write a good quality zk app. E.g. what ensures privacy of input is maintained, how to make smart contract state private etc. What even is a good quality zk app? lol

[crisp drum]

I wouldn't assume anything is "private". You can have "private inputs" that can be inferred by looking at the public state, or "private inputs" only as part of a zkProgram, ran by a third-party server that can log all "private inputs", etc.

The design space for zkApps is big, so keeping certain data private for a specific zkApp may involve different strategies, so there's likely no "recipe" for privacy, and I guess the best we can do is constantly searching for privacy vulnerabilities, and collecting examples of common mistakes

[rough summit]

I fully agree @fresh inlet tutorials on that would be great, but yeah I also don't have silver bullet recipes / don't think that this can be shown to users in an automated way