Defining Secret Contracts

Smart contracts need privacy to become useful. Here’s how Enigma’s secret contracts introduce privacy and enable powerful applications.

A few years ago, after the successful application of Bitcoin to decentralizing money, an old and important idea resurfaced. That idea, today more commonly known as smart contracts, posited that if we can solve the problem of trust in the banking system through code, why not do the same for every other application?

The years that followed would describe this forming movement as the new, decentralized internet, one that avoids centralizing too much power in the hands of a few large organizations and governments, which has been the prevailing theme of the internet in the past two decades.

Enabling true decentralization has many benefits indeed. Decentralized applications (or dApps), enjoy the benefit of being robust, unstoppable, censor-resistant and transparent. All of these are important properties of reducing trust and increasing security.

But all blockchains, and by extension smart contracts, have one glaring problem that is often overlooked — all data stored on them is public. In that sense, blockchains are worse than anything that came before them. Instead of trusting your data with a single organization (e.g., as is the case with Facebook, Google, your bank, etc), you now have to trust everyone. For all intents and purposes, data on the blockchain becomes public domain.

This, of course, is unacceptable. No business or organization would ever agree to make their most sensitive data public. If Amazon, the dominant cloud provider today, were to make all data residing in its data centers public, it would immediately cease to exist. Therefore, it’s not hard to see that a digital world without privacy is not one that can exist in practice. More importantly, privacy is a basic human right — so designing the technology foundation for the next web has to be built with privacy-by-design in mind.

We need privacy, not just correctness.

To address this concern, we need to go back to the drawing board and re-define the problem. In the nomenclature of blockchains, a smart contract is a unit of code, that is executed not by a single computer, but by many systems — essentially all the nodes in a blockchain network. Together, these reach an agreement about some state of the world, making it infeasible for an attacker to tamper with that state, or convince any honest actor that some false claim is in fact, true.

For example, in the simple example of value transfer, if Alice sends Bob five coins, then everyone in the network would agree that the total amount of coins Alice holds has decreased by five, and similarly — Bob gained five new coins. No bad actor would be able to convince honest participants otherwise. This idea is often defined in the academic literature as the correctness property of a distributed system. Smart contracts, and more generally — blockchains, solve this problem. However, as we’ve already established, they fail at solving the equally important problem of privacy.

We therefore propose a new concept called secret contracts. These contracts expand on smart contracts in that they not only solve for correctness, but also for privacy, because they can hide the data completely from the nodes. With these contracts, users and applications can operate in an environment where it’s safe to include sensitive data, which most real-world use-cases require.

To give an example of a potential secret contract, imagine a lending dApp that can autonomously give out loans to users. To function, it operates a smart contract that tests each individual’s eligibility by scanning their wallets and prior transactions, then computing if the individual should receive a loan (and if so — how big it should be). For example, it may examine if you asked for loans in the past, and whether you paid them back on time.

With a normal smart contract, a user would need to disclose all of their transactions publicly. This means that everyone would have complete visibility to your finances. Since most users aren’t likely to opt into such a service, the only option left to the dApp provider is to keep the actual computation of eligibility centralized, in order to limit the exposure of the sensitive data to the provider itself. In this hybrid approach the dApp is no longer autonomous or truly decentralized, as it cannot operate without the aid of the provider. The dApp thus retains all of the weaknesses of centralized applications, with few of the advantages.

Instead, in a setting where secret contracts exist, a user can share their transaction history safely with the secret contract itself. The nodes can execute the contract and receive the eligibility result without being able to observe the user’s transactions. There is no longer a need to create a hybrid dApp. This dApp could be autonomous end-to-end, while guaranteeing both correctness — if a user is eligible for a loan, she will get a loan; and privacy — no one but the user can see their transaction history.

Current privacy solutions need improvement.

To date, work on privacy on the blockchain has been mostly limited to concealing transactions. Several technologies have been proposed for this task (e.g., coinmixers, confidential transactions/pedersen commitments, ring signatures, zero-knowledge proofs), but these do not generalize well to the privacy of smart contracts, and are therefore inapplicable for the realization of secret contracts.

Zero-knowledge proofs (ZKP) in particular, while an important technology and an incredible achievement, are often poorly represented as the de-facto solution to all privacy problems. In practice, ZKPs are useful when a party with access to the data wants to prove a claim to others, without revealing the data to them. In cases where we want to outsource computations, often involving multiple parties, there isn’t a single party we can trust with seeing all of the data. This is exacerbated in the smart contract setting, where the parties executing the computation are untrusted and pseudonymous.

To enable secret contracts, we need to look at other technologies that have not yet been explored in the context of blockchains. For smart contracts, the main technological requirement is distributed consensus — but as we stated, they cannot do enough to create truly decentralized applications and solutions.

For secret contracts, the missing piece comes from an area in cryptography known as secure computation — an umbrella term for different technologies that enable computing over encrypted data. Primarily, these technologies are able to hide the state itself from the nodes in the network (as well as the public) while preserving the ability to execute and validate computations.

At Enigma, our vision and focus is to make secret contracts — and the applications they will power — a reality. We believe they are absolutely necessary to enable true decentralization at scale.

As is illustrated in our recently released roadmap, our first network release (codenamed Discovery, launching in Q2 2018) will make use of TEEs — Trusted Execution Environments— to conceal data from the network. Our second release, Voyager, will introduce secret contracts that are based on a purely cryptographic solution called secure Multi-Party Computation (MPC). The latter solution has been the topic of great interest in recent years, and it previously was the focus of my graduate thesis at MIT.

Secret contracts set the stage for the next step in building out decentralized systems in general, and blockchains in particular. By clearly defining the problems, outlining possible solutions, and clarifying current misconceptions about privacy on the blockchain, I hope that we will be able to more easily converge to solutions. After all — to admit we have a problem is a large portion of the solution already.

Do you want to help Enigma build secret contracts? Are you a dApp developer that recognizes the necessity of privacy-enabled smart contracts? Do you want to build a truly decentralized future? You should join us.

Learn more about our project on our website and blog.

Want to build on our protocol? Submit your interest here. 

Join the Enigma Team: enigma.co/team

Telegram: t.me/EnigmaProject

Reddit: reddit.com/r/EnigmaProject

Discord: https://discordapp.com/invite/SJK32GY

Twitter: twitter.com/enigmampc