This article is part one in a four-part series that aims to guide readers through the design and implementation of the built-in oracle service currently in development for Neo3. The series begins with a primer on oracles and potential use cases, and provides some context and goals for the native implementation under construction for Neo. In future articles, we will explore the proposed inner workings of the system.

Oracle networks

Public blockchains are very powerful as distributed ledgers because they are immutable and resistant to manipulation, but that can only be said for on-chain data which has been verified by the consensus protocol. In some situations, it would be useful for developers to be able to read data from another source, such as a website, and use it during contract execution.

Since off-chain data doesn’t come with the same guarantees as the blockchain, the mechanism responsible for providing that data needs to be decentralized and secure. When an application needs to retrieve specific information, such as live market price data for a particular asset, the request is passed to multiple nodes on the network.

These nodes, called oracles, fulfil the request by looking up the requested data. The oracles will then check the result with the other nodes, guaranteeing its integrity by majority approval. The approved result can then be included in a block, where it can be accessed by the contract in turn. Oracle nodes are paid for this service; in Neo’s case, oracle transactions are paid for with GAS.

Potential use cases

Since smart contracts are contained on the blockchain, they are inherently limited to information that is part of the chain. Oracle networks essentially build a bridge between a smart contract and the data available on the Internet; any information made available through an API can be requested by smart contracts through oracle calls.

Due to the open nature of the Internet, there is a mountain of data available, making the potential applications for oracle networks difficult to count. Valuable use cases will stem from contracts that find a way to make profitable use of specific data, for example a betting application might need to monitor the outcome of sporting events, or location data could be retrieved for supply chain tracking purposes.

One key use case is the retrieval of live market data such as asset prices, which is important information for many on-chain applications spanning from simple blockchain-based vendors to more complex DeFi projects offering derivatives, insurance, and lending services.

These use cases all rely primarily on data retrieved from the web via HTTP, however a notable advantage of the native Neo implementation is that other protocols can be supported, such as NeoFS for distributed decentralized object storage.

For example, a smart contract could store important data off-chain in a cost efficient manner using NeoFS, and access objects or metadata as required through the oracle service. This could pave the way for a more complete decentralization of blockchain-based applications and provides a powerful alternative to centralized cloud storage service providers.

Neo3 Implementation

After being conceptualized as a new feature for Neo3 by Erik Zhang, work began on planning for the native oracle solution at the first Neo Community Assembly in Shanghai. Discussions were led by Belane and Shargon, Neo core developers and cybersecurity experts from Red4Sec, and resulted in an initial proposal that would be refined over the next month.

Since late November, discussions on the oracle solution have been centered on an open Github issue which specifies the design goals to be met and links to separate discussions for each oracle component.

The issue outlines the key requirements for the built-in oracle service, which is designed to be easy to use for developers and decentralized to mitigate potential third-party trust issues. In future articles, we’ll further explore the current proposals for different components of the oracle implementation.

Tags: