[Ar-Curunir]

Zerocash is an crash system in the vein of Amon Ta-Shma’s variant from 99, and has rigorous security definitions and proofs. Follow-up work like Zexe strengthens these definitions to standard ones used in MPC, namely simulation-based security.

Furthermore, the MPC deployments you speak of are rather small-scale, there have been no deployments of general-purpose MPC beyond maybe the sugar beets auction.

[betterunix2]

MPC has been deployed at large scale by numerous companies, at least for the ads industry; I know because I actually work on exactly this full time and I have seen the numbers (but unfortunately I cannot share specifics). There is nothing special about general-purpose protocols that makes them more "legitimate" or whatever; we use specialized protocols in practice because it is almost always more efficient and thus less expensive to run (and MPC is usually right on the threshold of being too expensive).

As for zerocash, the last time I looked into it what I saw were a set of security definitions that assume a reliable ledger of some kind; whether or not that ledger is implemented using a blockchain at all is not addressed in the theoretical work. The practical deployment relied on Bitcoin, but since Bitcoin security is not well-defined (or at least not convincingly defined) that makes the rest of the security argument dubious. As far as I know Zexe has the same problem: yes, the security definition is much stronger, but they do not address the realization of the ledger functionality itself and thus any real-world deployment that relies on e.g. Bitcoin, or really any permissionless blockchain, has the same theoretical shortcomings. Ultimately the permissionless setting itself is the problem; zerocoin could be implemented using a ledger managed by a trusted party, and it would achieve its security goals without those theoretical problems.

I should also be clear that when I say ecash does not share this problem, it is because ecash has a well-defined security model and all functionalities needed to realize an ecash system also have well-defined security. We can instantiate ecash using any of the security assumptions we commonly use for digital signatures, and in theory ecash can be instantiated from MPC (by using a generic MPC protocol to implement a blind signature, then using the blind signature to implement ecash), which itself can be instantiated with standard cryptographic assumptions. So ecash has a security definition that is as well-defined as a cryptographic security definition can be.

[Ar-Curunir]

Zerocash and Zexe and Zerocoin are all strict supersets of ecash. If you instantiate them underlying ledger with a single server, you recover ecash. If you instantiate with a permissioned distributed ledger (eg via PBFT), you get a distributed but permissioned ecash system. If you use a permissionless ledger, you get a permissionless system with no central authority. The entire point of the ledger abstraction in those works is to enable a composition-based security analysis. That’s literally the way 99% of cryptography proofs are structured. Saying that “Zerocash doesn’t specify details of the ledger” is like saying that “Schnorr signatures don’t specify details of the underlying DL-hard group”; the point is to abstract away those concerns.

Re: MPC deployments, the point about deploying general-purpose MPC is that it’s a much more complex task than specialized protocols. That’s why I specified general-purpose zkps; we already have ubiquitous deployments of specialized zkps (I.e. digital signatures). And maybe your project indeed has a large scale MPC deployment, that’s awesome. Doesn’t take away from the fact that cryptocurrencies are pushing zkp innovation at unprecedented rates.

[betterunix2]

My job would be much simpler if I could deploy generic MPC; all I would have to do is maintain a library and maybe a compiler, without having to design and implement an entirely new protocol every time someone came along with some new feature or use-case. The engineering effort of productionizing a generic protocol is a one-time cost and my coworkers and I could do that work relatively quickly. On the other hand, special-purpose protocols are typically difficult to modify, we are have to do our security proofs over and over whenever we roll out anything new, and we must go through the engineering effort over and over.

Engineering effort is not what holds back the deployment of generic MPC protocols. Those protocols are just too expensive to run in the majority of real-world MPC applications. Even special-purpose protocols are sometimes too resource-intensive to be deployed. I do not see that situation changing without a radically different approach to generic protocols. I also do not understand what is so uniquely exciting about deploying a generic ZKP or MPC protocol. If it works in a giving setting and no special-purpose construction could be used, great, but it is not some kind of badge of honor.

As for Zerocash, you had originally said that blockchains are where we can finding the largest deployments of non-trivial ZKPs, which is why I pointed out that Zerocash and its followup work do not really involve "blockchains" beyond a particular instantiation of a ledger. If the construction can be implemented without any blockchain at all -- which the authors of the original paper took the time to point out -- then I do not see how any of the research on ZKPs motivated by Zerocash and its followup work supports your claim at all. You are saying that Zerocash is actually ecash, which kind of makes my point for me: we are not actually talking about something in the "blockchain space."

(Also, I have a somewhat controversial view that NIZKs and signatures are not actually "zero knowledge," since the verifier obviously cannot compute a NIZK or signature without receiving a message from the prover/signer and thus gains knowledge when it does receive those strings. Not that it matters in any way for this conversation, since the value of innovation in NIZKs or ZKSNARKs is not in doubt, but I did want to mention that signatures are a poor example of real-world deployments of ZKPs.)