DECO - making smart contracts way smarter

DECO is a privacy-preserving oracle protocol built by Chainlink. It leverages cryptography to enable users to validate facts about their Web2 TLS (transport layer security) sessions to oracles without disclosing sensitive details. As most of the useful data in the world is behind secured connections via TLS, opening up this data to smart contracts will make them way smarter and more sophisticated.

The key advantages of DECO include:

1. Provenance: It verifies and attests to data authenticity.

2. Privacy: Only relevant information, or its derivatives, are utilized for validation.

3. Compatibility: DECO is in sync with existing internet structures and supports all TLS-protected APIs without needing changes at the data source.

TLS

To illustrate its function, consider Alice wanting to share specific web data with Bob. Traditional methods either expose Alice to data manipulation risks (like using a screenshot) or compromise her privacy (giving Bob her login details). Other solutions might demand significant server-side alterations or third-party integrations.

When Alice accesses a secured website, she uses TLS (Transport Layer Security), which ensures secure communication over networks. In the current TLS design, Alice can't reliably showcase her data to Bob without running into the same issues as with screenshots. This is due to the nature of the TLS handshake, where symmetric encryption is for data exchange and asymmetric cryptography for authentication. So, in en exchanging data, both Alice and Bob would share the key and sign the data through MACing (message authentication code), rather than the true signature. In this sense, it allows Alice the same properties of signing data as the government or the third party website has (allowing the client to forge TLS session data). So, forwarding TLS data has the same flaws as the printscreen example. 

The problem is that TLS, despite its security benefits, can't prove the authenticity of retrieved data to external parties without additional complications. This has led to vast amounts of inaccessible private data on web servers. DECO addresses this gap, enabling the integration of such locked data within blockchains and smart contracts.

In essence, Alice can validate facts about her data to Bob using zero-knowledge proofs, without compromising on the data’s privacy, through added measures like a three-party handshake. This is achieved without altering server-side configurations, making it compatible with much of the current web data.

Three party handshake

The three-party handshake protocol involving a server, prover, and verifier presents an unforgeable commitment to TLS session data. Here's how it functions:

1. During a login, session keys established with the server are divided between the prover and verifier. Unlike a traditional approach where the client sends a public key to the server, in DECO, the verifier generates its private keys and sends its public key to the prover.

2. The prover then calculates her own private key, computes the public key, and dispatches the product of her and the verifier’s public keys to the server. Due to additive homomorphism, the resultant private key from the server is the combined private keys of both the prover and verifier.

There are additional steps, like the private key corresponding to the product of the two public keys sent to the server, needs to be converted to a symmetric key, but the most important thing is that the following is achieved;

·        Alice and Bob co-create a shared TLS session key (K).

·        K serves in a jointly secure way, such as decrypting data D for Alice.

·        Alice can't alter data D from the server due to the unknown session key.

·        Server remains oblivious to all background interactions between Alice and Bob.

When using different cyphersuites like Galois/Counter mode (GCM) for message security, the protocol needs minor tweaks. DECO is compatible with AES in CBC-HMAC and GCM. Though TLS 1.3 mandates adjustments, the core benefit is that with DECO, data from Web2 can be authenticated and used in Web3.

All this without server side modifications or additional trust assumptions, which is important for the following reason. Server-side cooperation-based oracle schemes, which require servers to install TLS extensions or modify application-layer logic, face two main challenges. First, they break legacy compatibility, creating barriers to widespread adoption. Second, they offer conditional exportability, as web servers can control which data can be exported and may censor export attempts.

DECO employs a decentralized service to validate data integration in Web3, eliminating trust issues with provers. The verifier identifies the data source and any query in the URL but only accesses an encrypted transcript.

Protocol breakdown

The DECO protocol consists of three stages:

1. Three-party handshake: This step sets up session keys in a specific format to ensure unforgeability (as discussed earlier).

2. Query execution: Here, the prover retrieves data from the server, with the query derived from a template incorporating their private parameters using 2PC (two-party computation).

3. Proof generation: In this phase, the prover confirms the query's legitimacy and the appropriate response.

Chainlink integrates zero-knowledge proof advancements in the post-handshake stage, avoiding the need for verifiers like Chainlink oracles to view the prover's private keys. Essential claims made include the prover's possession of a secret key, its use in encrypting the transcript, and assertions about redacted data. Padding is crucial in this context to maintain to hide a field’s length.

During the query phase, post the preliminary exchange, prover P sends their query Q to server S, in the form of a typical TLS client, facilitated by verifier V. They use secret-shared session keys, demanding a collaborative 2PC protocol to generate encrypted TLS records for Q. Chainlink suggests specific 2PC protocols to optimize efficiency as otherwise extensive queries would be resource-intensive as it requires hashing the entire query in 2PC to compute the inner hash.

As an alternative, Chainlink’s efficiency is due to making the computation of the inner hash local to the prover without 2-PC. To compute the inner hash of a message, the prover needs to use a secret as the inverse vactor to compute a hash of the message. It is fine to reveal this secret, because it will not reveal the key as the compression function is one way, by using the Merkle–Damgård structure.  

DECO's ZK technology distinguishes itself from what other protocols use. While SNARKS and STARKS offer perpetual verification, they don't assure DECO's required provenance and can't provide quick proofs as needed for web2 sign-ins (non-interactive is also not possible due to the handshake). DECO adopts zkSNARK, modifying block hash elements and Merkle Trees with TLS components. First, Merkle Tree gets substituted with TLS's AES initialization vector (IV). Second, proof's state data hash is replaced with TLS HMAC as a hash. Incorporating these elements into zkSNARK results in a highly efficient system as Chainlink because the most expensive aspects were replaced with computationally free elements that were already performed in an earlier phase. For instance, verifying a TLS record's decryption traditionally demands proving the correct execution of 1024 AES invocations in zero knowledge. In contrast, Chainlink achieves this with merely three AES invocations.

According to Chainlink, DECO's ZK is vastly faster than alternative interactive ZK technologies, consuming 100-500X less memory.

Improvements

We believe the zkSNARK Proof's design has room for improvement. For example, the Prover's unrestricted access to the SSL session. It is assumed that the Prover is actually the Web3 client and not a third party, because a third party would completely compromise the security of the SSL session, risking exposure of private data.

A full record is required but the API to reveal records is very compatible in a flawed mechanism. HTML is not semantic data, so context is lacking on a “<div>” tag with no references. DECO requires that proving data follows the introduction header, but this claim is only strong with semantic data. 

HTML is often rendered by JavaScript and content is added in separate transmissions. This difference can be seen any time a developer looks at a website with “view-source” and compares it with “inspect source” in browser developer tools. The content from the “view-source” is in the initial SSL session, while “inspect source” includes post-javascript rendering. 

Plugins and extensions are adding a lot of content, as well as CORS based JavaScript. All of these are “external parties” with Web3 being the most obvious exclusion. These are separate SSL sessions with separate handshakes, not part of the original request and only triggered by use of plugins and extensions such as Metamask plus JavaScript.

JSON is not HTML; HTML is not JSON. A single prover mechanism and ruleset is used for two different organization structures. A “single JSON record” may contain the reference data, but the structure of HTML is fundamentally different. The documentation for DECO presents only JSON references, but uses them to make inaccurate claims about HTML. A better system would include hierarchy of data, not just “reference string A came before data string B.”