Energy Web Documentation
  • Energy Web Ecosystem
  • Launchpad by Energy Web
  • EWC Validator Documentation
  • Community Ressources
  • Legacy documentation
  • Welcome to Energy Web
  • Glossary
  • Solutions 2023
    • ↔️Data Exchange
      • Data Exchange Overview
      • Data Exchange Architecture
      • Use Cases and Refrence Implementations
        • Digital Spine for Electricity Markets
          • Digital Spine Integration Client Deployment Guide - from Azure marketplace
        • E-Mobility Management
    • 🔌Open Charging Network
      • Create and Manage an OCN Identity
      • Connect an OCPI/OCN Party to a Node
        • 1. Make your backend service OCN-ready
        • 2. Select an OCN Node and register in OCN Registry
        • 3. Manage your Whitelist and Blacklist
        • 4. Connect your service to an OCN Node
      • Run an OCN Node
      • Use the OCN Service Interface
        • Offer an OCN Service
        • Sign up for an OCN Service
      • Develop on the Test Network
      • Develop on the Production Network
      • Open Source Development
        • Maturity Model, Feature Roadmap and Releases
        • Developer Community Calls
      • E-Mobility Dashboard v0.1
  • EW-DOS Technology Components 2023
    • EW-DOS Overview
    • Worker Nodes
      • Worker Node Process Diagrams
      • Worker Node Architecture
      • Worker Node Guides
        • Deploy Worker Nodes
        • Customize Worker Logic
    • Identity and Access Management (IAM)
      • IAM Guides
        • Implement an SSI Hub instance
        • Verifiable Credential API
        • Sign-In with Ethereum
        • Using Switchboard
          • Switchboard Transaction Cost Estimates
      • IAM Patterns
        • Assets as Ownable Smart Contracts
        • Credential Lifecycle
        • Credential Metadata
        • SSI Credential Governance using ENS Domains
      • IAM Libraries
      • SSI Hub
      • Switchboard Application
    • Decentralized Data Hub (DDHub)
      • DDHub Message Broker
      • DDHub Client Gateway
      • DDHub Patterns
        • Channels and Topics
      • DDHub Guides
    • Green Proofs Contracts
    • Energy Web X
    • The Energy Web Chain
      • EWC Overview
      • System Architecture
        • Proof-of-Authority Consensus Mechanism
        • System Contracts
          • Name Registry
          • Holding Contract
          • Block Reward Contract
          • Validator-Set Contracts
        • Validator Node Architecture
      • Energy Web Block Explorer
      • Validator Node Installation Specifications
        • Volta Test Network: Validator Node Installation
      • Energy Web Chain Governance
      • EWC Guides and Tutorials
        • Getting started with Energy Web Chain
        • Developing on the Volta Test Network and Main Network (Energy Web Chain)
        • Run a Local RPC Node
          • Run RPC Node using Nethermind client
        • Deploy a Smart Contract on Volta with Remix
        • Interacting with Smart Contracts in EW-DOS
        • Set up MetaMask to interact with Energy Web Chain
        • Using the Ethereum Name Service
        • Using Oracles
      • Energy Web Token (EWT)
  • 🧠Foundational Concepts
    • Open-Source Software
    • Scaling Access to Grid Flexibility
    • Facilitating Clean Energy Purchases
    • Ethereum
      • Transactions and Transaction Costs
    • Self-Sovereign-Identity
      • Self-Sovereign Use Case Interaction
    • Cryptocurrency Wallets
      • Software cryptocurrency wallets
        • Metamask
        • Mycrypto wallet
      • Hardware cryptocurrency wallets
      • Hierarchical Deterministic (HD) Wallets
Powered by GitBook
On this page
  • Blockchain Oracles
  • Inbound vs. Outbound Oracles
  • Oracle Data Sources
  • Centralized Vs. Decentralized Oracles
  • Fundamental Oracle Functionality
  • Oracle Design Patterns: Communicating Data To Smart Contracts
  • Tutorial: Using Chainlink with the Volta Test Network
Export as PDF
  1. EW-DOS Technology Components 2023
  2. The Energy Web Chain
  3. EWC Guides and Tutorials

Using Oracles

Incorporate external data sources into your smart contracts

Blockchain Oracles

By themselves, smart contracts cannot access data outside of the blockchain or send its data to services outside of the blockchain. To do this, smart contracts use middleware called an oracles, which are third-party services that fetch and send data to and from smart contracts. Oracles are similar to traditional web-based API services.

Smart contracts can contain logic that triggers certain changes or actions based on external data from an Oracle. Without oracles, blockchains and their applications that cater to specific industries that rely on real-time changes such as finance, commodity trading, or IoT, would not have access to the data necessary to react to real-time external factors.

It's important to keep in mind that oracles are agnostic of the data they transmit - they are only responsible for fetching, verifying and relaying the data to and from the blockchain.

Inbound vs. Outbound Oracles

Inbound oracles send data to the blockchain. This is the most common type of oracle. Like traditional API services, the inbound data that the oracle provides can be anything that your smart contract needs for internal logic that it cannot access from the blockchain or the smart contract itself.

For example, you want to send 10 EWT to a friend's address when the price of a specific stock goes above $10 per share. An oracle will provide you with the data about stock price, and the blockchain logic will trigger the send when the oracle delivers data indicating that the price of a stock goes above $10.

Outbound oracles send data about events that happen on the blockchain to third party applications. For example, an account could receive a payment and trigger an outbound oracle to a mechanism that activates a pv solar panel.

Oracle Data Sources

Oracles can gather data from software and hardware. A software oracle interacts with and fetches data available from any web source that exposes its data. Some common examples are weather APIs, real-time stock information and exchange rates.

Hardware oracles interact with 'physical' data sources like sensors from IoT devices, QR codes or bar codes. Some examples could be reading the temperature from a smart thermostat or fetching data from a flood sensor..

Centralized Vs. Decentralized Oracles

Centralized oracles are developed, maintained and controlled by a single entity. One oracle is responsible for fetching data from one or many data sources, and then transmitting that data to the smart contract on the blockchain. You could liken this to using a centralized database for your smart contract's external data sources.

Decentralized oracles aggregate data from multiple sources using multiple oracle nodes, so that there is no single point of failure for data retrieval, and no single point of failure for the oracle itself. Decentralized oracles are more aligned with the wider community of public blockchain.

Fundamental Oracle Functionality

Regardless of the data source, or if it is centralized or decentralized, all oracles provide three main functionalities:

  1. Listen to the blockchain network for incoming requests for off-chain data

  2. Fetch data from the requested off-chain source

  3. Transfer the data to the blockchain via a signed transaction

  4. Insert the data into a smart contract’s local storage. Once the data is in the smart contract's storage, it can be used to trigger logic within that smart contract, or it can be available for other smart contract's to use

Oracle Design Patterns: Communicating Data To Smart Contracts

Depending on the nature of the data itself and how the smart contract uses the data, oracles can be designed to communicate with smart contracts using three main patterns:

  1. Publish-subscribe: An oracle broadcasts data, and certain smart contracts are polling or "listening to" that oracle for changes in data. An example: "Poll the temperature of region X every 10 minutes. If the temperature is above 70 degrees celsius, turn the smart thermostat to 'on'."

  2. Immediate-read: Oracles hold data in their storage and provide this data on request. Users or devices query the oracle for this data at the same time that it is needed. An example: "Is device X in a list of authorized devices to provide solar power to region Y."

  3. Request-response: External accounts (via decentralized applications) interact with a smart contract and necessitate data from the oracle. The smart contract sends the data parameters to the oracle and performs the third-party data query. When the data is fetched, it sends the result back to the smart contract for the decentralized application to use. Because the decentralized application cannot always wait for the data, this occurs asynchronously. An example: A user selects from a dropdown on a decentralized application a date range to determine the average temperature of each day during the range. The start and end date are sent to the data oracle to fetch the temperatures for the days in the given date range. The data is sent back to the smart contract to perform necessary logic based on the data.

Tutorial: Using Chainlink with the Volta Test Network

  • Setting up a Chainlink node and using it from a smart contract on the Volta test network

  • Design principles of Chainlink oracles

  • Scenarios where it makes sense to use Chainlink

PreviousUsing the Ethereum Name ServiceNextEnergy Web Token (EWT)

Last updated 3 years ago

provides decentralized oracle networks. covers:

Aggregating data from multiple Oracles, and how to use the public Price Pair Oracle infrastructure on Volta

Chainlink
This tutorial
EWT/EUR