Oracle Evolution
Rich data sources are what evolved the internet. Static pages turned into dynamic data thanks to APIs (oracles). As APIs (oracles) evolved in the traditional web, they allowed completely new apps that weren’t previously possible. It was key behind the web’s evolution from web1.0 (static) to web2.0 (dynamic).
A personal note: 3–4 years ago, my thoughts on this topic were a lot more binary. I believed there was the traditional centralized web (web2.0) and the decentralized web (web3.0 [while I don’t like this moniker, I will use it in the article, I believe deweb1.0 is probably a better label]). My belief was that these two needed to be completely separate, with no intermingling. The decentralized web back then was akin to the early static pages of web1.0, they could exist in isolation. Over the last 4 years, the decentralized web has evolved into a much more interactive-based system. Web2.0 receiving “off-chain” data (weather, flights, supply chain, etc.) did not diminish its power, it exponentially grew it. The same is true for web3.0.
Oracle v1: on-chain request, off-chain provider; example Oraclize
- User initiates on-chain transaction (deposit/withdraw/buy/sell/liquidate/etc.) to smart contract
- Smart contract submits HTTP request on-chain to oracle smart contract
- Off-chain centralized service picks up the HTTP request event and parses the HTTP request off-chain, receiving data
- Centralized approved service writes the received data back on-chain to the smart contract (the smart contract can optionally callback the initiating smart contract)
Pros:
- Can source arbitrary oracle data
- Data only provided on request (no unnecessary data storage or gas fees)
Cons:
- Centralized service
- Response asynchronous delay (app responsiveness)
- Cost (need to pay for initiation transaction and gas fees for callback)
Oracle v2: on-chain provider; example Chainlink
- Dapp requests a data feed (predominantly price) from Oracle (off-chain)
- Distributed network adds the data feed to their nodes
- Centralized authorizer writes data on-chain periodically
Pros:
- Data availability (data is on-chain when required, no responsiveness delay)
Cons:
- No arbitrary data
- Request pre-approved feeds and access
- Centralized authorizer (trust)
- Cost (subsidize gas fees for every on-chain write)
Oracle v3: off-chain data, on-chain verifier, example Chainlink (in alpha) <- we are here
- Dapp/user requests off-chain provable data from authorized service
- Centralized prover requests the data off-chain and signs (via their own authorized key); returned value, timestamp, source of data
- Dapp initiates on-chain transaction (deposit/withdraw/buy/sell/liquidate/etc.), as part of the transaction it includes the signed data
- Smart contract verifies the signer is the expected prover, verifies the source of data, verifies the timestamp, and verifies the data. If all verified, the dataset is updated with the new data and the rest of the transaction is executed
Pros:
- Can request arbitrary data
- Data only provided on request
- Data availability (it is available as the transaction is processed)
- Low cost (only need to pay for the extra sig verify and SSTORE)
Cons:
- Centralized authority/prover (trust)
- Contract needs pre-knowledge of the prover public key
Oracle v4: zero knowledge provable data, TBD
- Dapp/user requests off-chain provable data from prover program
- A prover program (custom-built zk circuits for TCP [note: we are very far from this]) that anyone can run (including in the dapp itself), that takes as arguments a target endpoint (HTTP/SSL/TCP/etc.) and provides a proof and the output; return data set, timestamp, and source (target endpoint)
- Dapp initiates on-chain transaction (deposit/withdraw/buy/sell/liquidate/etc.), as part of the transaction it includes the proof and data
- Smart contract verifies the proof, verifies the source of data, verifies the timestamp, and verifies the data. If all verified, the dataset is updated with the new data and the rest of the transaction is executed
Pros:
- Can request arbitrary data
- Data only provided on request
- Data availability (it is available as the transaction is processed)
- Low cost (only need to pay for the proof verification and SSTORE)
- No centralized entity (no trust)
Cons:
- Contract needs pre-knowledge of the prover program
- Highly complex circuits and unlikely to be available anytime soon
