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
来源：medium
本文经「原本」原创认证，作者鸵鸟区块链，访问yuanben.io查询【11Q3W1KC】获取授权信息。