Whether you are initiating a transfer on your bank's website, posting content on your social media account, or even viewing a public website including this very blog post, TLS is at work to make sure that all data sent between you and the web server is authentic and confidentially transmitted. But while TLS is excellent at convincing the protocol participants (i.e., you and the web server in the above example) that all data is authentic and secure, it turns out that TLS is useless if you want to convince someone else that you sent or received some particular data to or from a website. So while you can log into your bank account and check your balance, there's no way to use TLS to convince a third party that your bank account has a particular balance. As we will see, this is a serious limitation, and one which we address in a new paper.
An oracle is a service that provides and vouches for the authenticity of data. In systems such as smart contract platforms that are unable to directly access the web, oracles serve as a critical link that enables these systems to make decisions based on real world data. When an oracle is tasked with providing publicly available data (e.g., stock prices), its task is relatively straightforward. But consider an oracle that is asked to provide data about a specific user: confirm that Alice, according to an online government portal, is above a certain age or that Bob's bank account balance is above a certain threshold. For these examples, the oracle needs to vouch for data from a TLS session that is only available when logged in as a particular user. The question becomes then: Considering TLS's limitations, how do you convince the oracle of the correctness and authenticity of this data?
You can of course give the oracle your credentials (e.g., your banking username and password) and have them log in to check your balance, but this would require a high level of trust in the oracle. For security reasons, you definitely don't want the oracle to have full write access to your bank account, but for privacy reasons, you probably don't even want the oracle to have full read access to your account. All that the oracle needs to know, in the banking example, is your account balance, and the critical question is: Can we allow the oracle to validate this information without giving it access to any additional data? DECO answers this question in the affirmative.
DECO is a novel privacy-preserving oracle protocol, created by students and faculty at IC3.
DECO is not the first to introduce this problem, and indeed other solutions have been proposed. But DECO is the first solution to work with modern versions of TLS that does not require the use of trusted hardware or active participation from the web server that provides the data. In DECO, anyone can serve as an oracle for any website, and strong privacy from the oracle is guaranteed. Where previous solutions have used trusted hardware, DECO relies on highly optimized multi-party computation and zero-knowledge proving techniques that allow the oracle to participate in a TLS session while only learning the exact data that it's trying to verify.
DECO has a variety of other applications as well. It turns out that even for publicly available data, DECO is useful, as it allows smart contracts to use an oracle service without even revealing to the oracle the rules that the smart contract is enforcing. In other realms, DECO is also useful for users who want to monetize their own data (and therefore prove that they are indeed providing correct data) without giving away anything but the data that they are selling.
In those cases where trusted hardware isn't available or can't be used, we think DECO is a leap forward for oracle technologies. We encourage you to read our new paper for full technical details, and check out our website.
We're also excited about Chainlink's plans for an initial PoC of DECO, with a focus on decentralized finance applications such as Mixicles.