Opportunities and pitfalls in decentralized TLS-based oracles

If every server in the world cryptographically signed their API responses, an incredible range of applications would become more decentralized. To give one example: on-chain stablecoins, lending protocols and insurance smart contracts all need frequent price information. If API responses of, say Yahoo Finance were signed, those applications could directly cryptographically verify price data on-chain.

Unfortunately the vast majority of APIs don’t sign their responses. However, given that most API responses are encrypted with the TLS protocol, there are ways to still cryptographically verify their provenance given either some trust assumptions or performance requirements.

Let’s find out how this can be done. The main challenge to overcome is the following 1 :

TLS generates symmetric encryption and authentication keys that are shared by the client and web server. Thus, the client can forge arbitrary TLS session data, in the sense of signing the data with valid authentication keys.

This challenge would be solved if a client is able to commit to a web server’s response, before gaining knowledge of the symmetric encryption and authentication keys. This can be achieved by ensuring the client establishes the TLS handshake together with a notarizing party. The notarizing party can be:

  1. the Verifier party who wants to know some statement about the web server’s response. The upside is that this is a fully trustless architecture. The downside is that this imposes a high burden on the Verifier, who needs to run infrastructure to be available. This is hard for small Verifier parties or impossible for, say, smart contract systems.
  2. a trusted third party or set of parties. By making use of Trusted Execution Environments and Multi-Party Computation, trust can be reduced to a very low degree.

The TLS-based oracle architecture DECO has gathered recognition in the cryptocurrency community for being the first setup to pursue the fully trustless approach (1). Unfortunately, current users of DECO fall short of this promise, because they outsource the process of running the Verifier to Chainlink2. As a result, the security of these implementations fall back to approach (2). The use of additional Chainlink nodes decreases the performance. Moreover, integrations have to be performed by additional service providers, which introduces additional trust assumptions.

Users would be better off using zkPortal, which is building the most resilient possible fully vertically integrated architecture using both Trusted Execution Environments and Multi-Party Computation to reduce trust in the notarizing party: https://zkportal.io/docs/Architecture.html

1: https://arxiv.org/abs/1909.00938
2: https://www.youtube.com/watch?v=eJqZQ2_VBzo&t=1473s