Quote from: TheByzantineGeneral on March 14, 2017, 07:53:54 PM

ETH incorporating a SNARK verifier opcode seems to be quite likely,

July 2016:baby ZoE or ZeroCash over Ethereum
https://z.cash/blog/zksnarks-in-ethereum.html
https://github.com/zcash/babyzoe
"In our work this week, we extended the Ethereum contract language to efficiently support verification of zkSNARK proofs. Specifically, we added a snarkverify precompile (like an opcode) to a fork of Parity which uses libsnark to verify generic proofs."

Jan 2017: ZCash integration into Ethereum Blockchain
https://blog.ethereum.org/2017/01/19/update-integrating-zcash-ethereum/

Feb 2017
https://medium.com/@VitalikButerin/zk-snarks-under-the-hood-b33151a013f6

I believe the issue being of the Zcash private transactions are quite expensive in gas
in the context of executing on EVM. You mentioned

Quote

Besides, the Hawk protocol also has mechanisms to make private smart contracts less cumbersome than they would be in ETH.

Could the following fix or alleviate any of such issues?
Hawk seems to have a decentralized manager who receives inputs from the Users and produces the snark proof? correct?

Yes, each private contract in Hawk has a manager that runs the contract on private inputs and produces the proofs. When I noted that smart contracts are less cumbersome in Hawk, what I was referring to was the fact that Hawk provides an automated mechanism to coordinate between manager, users, and the network. However, Hawk does fix the issue you brought up as well.

As you hinted, the ETH developers don't intend to put a SNARK verification opcode into its VM due to cost, but rather to use precompiled contracts. This limits the ability to use private contracts significantly. In the Hawk paper and in a follow-up paper, they describe some optimizations that are used to make it feasible to implement it as an opcode; so, indeed, Hawk does put SNARK verification straight into the EVM. Actually, IMO there are even more optimizations that can be made, which Hawk doesn't even incorporate yet. For example, CredaCash uses a Diophantine subsum hash function instead of SHA2, and the result is that a proof in CredaCash can be generated in about three seconds. (To put that into perspective, a Zcash proof takes two minutes to generate.)

I should also mention that ZoE has a problem right now, which is that a new trusted setup must be conducted for every new smart contract that's created. Actually, Hawk also has this problem, but it can be fixed. A virtual machine called vnTinyRAM can be compiled into the language of SNARKs, so that a setup phase only need be conducted once. To make running proofs on vnTinyRAM code more efficient, a compiler called Geppetto can be used to compile certain aspects of the code before generating the vnTinyRAM code. The setup still only needs to be conducted once, but (at least in theory) creating proofs should be much less expensive than the naive method.

Finally, there's another problem in simply putting SNARKs into Ethereum, but it's quite a bit more subtle. Essentially, zerocash gives you ledger indistinguishability, which means an adversary cannot deanonymize transactions by simply looking at the blockchain. However, the proofs used in Hawk have a much better security property, called Universal Composability (UC): an adversary cannot deanonymize transactions, even if they can execute arbitrary code while they're interacting with the protocol. Ledger indistinguishability simply isn't a good enough security property for a smart contracts platform, simply because smart contracts are designed to allow you to execute arbitrary code while interacting with the protocol. Therefore, unless ZoE incorporates this, their security might no longer be sufficient when applied to smart contracts.

I do hope all these points are legible. SNARKs are still a little abstract for me, but I'm learning.