TAKING A STEP DOWN
There are two branches of technology that can get nearly to the extent of obfuscation, however with important compromises to the security model. The first is a secure multi-party computation. Secure multi-party computation allows for a program (and its state) to be split among N parties in such a way that M of them (eg. N = 9, M = 5) are needed to cooperate in order to either complete the computation or reveal any internal data in the program or the state. Thus, if one can trust the majority of the participants, to be honest, the scheme is as good as obfuscation or else it’s worthless.
The math behind secure multi-party computation is complex but much simpler than obfuscation; (For technical details read here). SMPC is also much more efficient than obfuscation. Addition operations can be processed fairly fast, yet every time an SMPC instance performs some extremely small fixed number of multiplication operations, it needs to perform a “degree reduction” step including messages being sent from each node to each node in the network. Ongoing work lessens the communication overhead from quadratic to linear, but even still every multiplication operation brings a specific unavoidable level of network latency.
The necessity of trust on the participants is likewise a grave one; note that, similar to the case with numerous different applications, the participants have the ability to save the data and then collude to reveal at any future point in history. Furthermore, it is very difficult to tell that they have done this, thus it is impossible to boost the participants to keep up the system’s privacy; consequently, secure multi-party computation is arguably much more suited to private blockchains, where incentives can come from outside the protocol, than public chains.
Another sort of technology that has exceptionally amazing properties is zero-knowledge proofs, and explicitly the recent developments in “succinct arguments of knowledge” (SNARKs). Zero-knowledge proofs enable a user to construct a mathematical proof that a given program, when executed on a few (possibly hidden) input known by the user, has a specific (publicly known) output, without revealing some other information. There are many specialized types of zero-knowledge proofs that are fairly easy to implement; for example, a digital signature can be thought of as a kind of zero-knowledge proof showing that the value of a private key is known which, when processed using a standard algorithm, can be converted into a particular public key. ZK-SNARKs, on the other hand, allows making such proof for any function.
First, some specific examples are gone through. Identity systems are one natural use case for the technology. For example, suppose that one wants to prove to a system that they are (i) a citizen of a given country, and (ii) over 19 years old. Assume that the government is technologically dynamic, and issues cryptographically signed digital passports, which include an individual’s name and date of birth as well as a private and public key. A function which takes a digital passport and a signature signed by the private key in the passport as input would be constructed, and outputs 1 if both (i) the date of birth is prior to 1996, (ii) the passport was signed with the government’s public key, and (iii) the signature is correct, and yields 0 generally. One would then make a zero-knowledge proof showing that there is an input that, when passed through this function, returns 1, and sign the proof with another private key that he wants to use for future interactions with this service. The service would verify the proof, and if the proof is correct it would accept messages signed with the private key as valid.
Digital token ownership is another category of use cases for the technology. In order to have a functioning digital token system, it is not necessary to have visible accounts and balances; in fact, all that is needed is a way to solve the “double spending” problem. With zero-knowledge proofs, this should be possible; the claim that zero-knowledge-prove is something like “I know a secret number behind one of the accounts in this set of accounts that have been made, and it doesn’t match any of the secret numbers that have already been revealed”. Accounts in this scheme end up one-time-use: an “account” is created each time assets are sent, and the sender account is totally consumed. If one does not want to completely consume a given account, then he must simply create two accounts, one controlled by the recipient and the other with the remaining “change” controlled by the sender themselves. This is essentially the scheme used by Zcash.
For two-party smart contracts (eg. something like a money-related subsidiary contract negotiated between two parties), the application of zero-knowledge-proofs is genuinely easy to understand. At the point when the contract is first negotiated, rather than making a smart contract containing the real formula by which the funds will eventually be released (eg. in a binary option, the formula would be “if index I, as released by some data source is greater than X, send everything to A, otherwise send everything to B”), create a contract containing the hash of the formula. When the contract is to be shut, either party can themselves compute the amount that A and B ought to get and provide the result alongside a zero-knowledge-proof that formula with the correct hash provides that result. The blockchain finds out how much A and B each put in, and how much they get out, but not why they put in or get out that amount.
This model can be summed up to N-party smart contracts.