🚀
Energy Web X Ecosystem
  • Documentation Overview
  • Core Concepts
    • Energy Web Chain
    • Energy Web X
    • Energy Web Tokens
      • Token Lifting
      • Token Lowering
    • Worker Nodes and Worker Node Networks
      • Server-based Worker Node
      • Marketplace App (desktop-based)
    • Worker Node Operator
    • Smart Flows and Groups
    • Subscription
    • Reward Period
    • Voting and Consensus
    • Ethereum
      • Transactions and Transaction Costs
    • Decentralized Identifiers (DIDs)
  • EWC ECOSYSTEM
    • Energy Web Chain
      • System Architecture
        • Proof-of-Authority Consensus Mechanism
        • System Contracts
          • Name registry
          • Holding Contract
          • Block Reward Contract
          • Validator-Set Contract
        • Validator Node Architecture
      • Energy Web Block Explorer
      • Energy Web Chain Governance & Validators
    • Energy Web Tokens
  • EWX ECOSYSTEM
    • Energy Web X
    • EWX: Architecture
    • Pallets
      • Worker Node Pallet
      • Balances Pallet
      • Proxy Pallet
      • XCM Pallet
      • Assets Pallet
      • Multisig Pallet
      • Scheduler Pallet
      • Preimages Pallet
      • Offences Pallet
      • Eth-Bridge Pallet
      • Token-Manager Pallet
      • Ethereum-events pallet
      • Avn Pallet
    • Worker Nodes
      • 🖥️The Marketplace App
        • Operator and Worker Accounts
          • Creating an operator account
          • Funding an operator account
          • Connecting to operator account
          • Disconnecting an operator account
          • Creating a worker account
          • Importing worker account
          • Exporting worker account
          • Linking a worker account to an operator account
          • Unlinking a worker account from an operator account
        • How to use Ledger on Marketplace App
        • Token Management
          • Creating an EWC account
          • Managing EWC accounts
          • Lifting tokens
          • Lowering tokens
          • Tracking lifting and lowering transactions
          • Checking EWT balance
        • Subscriptions
          • Subscribing to a solution group
          • Topping-up subscription amount
          • Managing subscriptions
          • Unsubscribing from a solution group
          • Unsubscribing delay
        • Worker Node and Rewards
          • Configuring remote worker node
          • Switching worker node location to remote
          • Participating into worker node network
          • Votes casted per Period
          • Reward Period
          • Checking rewards
          • Claiming rewards
        • FAQ: Marketplace App
        • Location Services
      • 🗄️Server-based Worker Nodes
        • Deployment Guide
        • Bootstrapping Server-based Worker Node Accounts
        • FAQ: Server-based Worker Nodes
      • Worker Node use cases
        • Sample Enterprise Use-Cases
          • Operating Envelopes Partitioning
          • ZEL Request Partitioning
          • Green Proofs
            • SAFc
            • Green Proofs for Bitcoin (GP4BTC)
            • Green Proofs as a Service (GPSaaS)
            • Green Proofs for Electrical Vehicles (GP4EV)
  • ENERGY SOLUTIONS
    • Green Proofs by Energy Web
      • Green Proofs Overview
      • Green Proofs Architecure
      • Green Proofs Software Stack
      • Use Cases and Reference Implementations
        • 24x7 Renewable Electricity
        • Sustainable Aviation Fuel
        • Green Proofs for Bitcoin
          • GP4BTC Miner Guide
        • Decarbonizing Shipping
        • Green Proofs for Electrical Vehicles
        • Green Proofs as a Service (GPSaaS)
    • Digital Spine by Energy Web
      • Design and Architecture
      • Component Guides
        • Energy Web Name Service (ENS)
        • Self-Sovereign Identities
          • SSI-Hub
          • Technical Guide
            • Organizations
            • Applications
            • Roles and IAM
          • Deployment Guide
            • Deploy Identity Cache Server
            • Deploy Switchboard
        • DDHub Message Broker
          • Technical Guide
            • Authentication and Authorization
            • Topics
            • Messaging
          • Deployment Guide
            • Deploy DID Auth Proxy
            • Deploy Message Broker
        • DDHub Client Gateway
          • Technical Guide
            • Authentication and Authorization
              • Key Vault
            • Client Gateway Identity and VCs
            • Address Book
            • Topics
            • Channels
            • Integration Options
            • Messaging
          • Deployment Guide
            • Launchpad SaaS
            • Azure Marketplace
            • Self-Hosted
              • Deploy with Kubernetes
              • Deploy with Docker
            • Key Vault
              • Deploy with HashiCorp Key Vault
              • Deploy with Azure Key Vault
              • Deploy with AWS Secrets Manager
            • Rebranding and Whitelabelling
Powered by GitBook
On this page
  1. ENERGY SOLUTIONS
  2. Green Proofs by Energy Web
  3. Use Cases and Reference Implementations

24x7 Renewable Electricity

Building a traceability platform for 24/7 renewable electricity tracking and matching: Enterprise energy consumers are interested in accurately measuring (and mitigating) their carbon footprint through the procurement of renewable electricity. One strategy to accomplish this is to track their electricity consumption and match it with locally available renewable electricity on an hourly basis. Many established tracking systems for renewable electricity fail to provide this level granularity: today most renewable certificates are issued at a monthly interval at best, and often annually. Green Proofs can be used to create a digital platform with the following functionalities:

· Digital onboarding of all parties

· Collection of granular (e.g. hourly, sub-hourly) generation and consumption data 24/7

· Verification of the sources of data by checking the DID of the data provider

· Performing of matching of generation and consumption data based on predefined logic (e.g. preferences of buyers, prioritization of assignment of available supply)

· Decentralized validation of the matching results by multiple eligible actors (worker nodes)

· Issuance, transfer and redemption of EACs via immutable, tamper-proof, and auditable digital certificates

· Reporting: customizable user interfaces and reporting tools to visualize and export different metrics for generators and consumers.

Historically, the easiest way for an organization to claim it is powered by clean energy is to purchase renewable energy certificates (RECs) from third party renewable energy generators. RECs represent the environmental attributes of the renewable energy produced and are sold separately from the actual electricity, typically on an annual basis. RECs have been beneficial for the development of renewables, but they fail to truly account for the carbon impact of an organization’s electricity consumption. A more accurate way to decarbonize operations is to match actual electricity consumption with available renewable generation within the same grid on a real-time, continuous basis. Energy Web’s 24/7 Green Proof solution is capable of tracking and matching consumption and generation within a granular time frame, moving from a yearly or monthly basis (with RECs) to an hourly or sub-hourly basis.

Example: Performing matching for 24x7 renewable energy applications

The role of workers in a 24x7 solution is to execute a matching algorithm that assigns renewable generation to specific customers (consumption centers) to improve accuracy and reliability of clean energy accounting.

Onboard Renewable Generators and Consumption Centers

  • First, workers establish a registry of known renewable generators (or data providers who own/operate multiple generators) and end-customers (i.e. individual load centers that want to account for their electricity consumption) using pseudonymous identifiers. In this architecture, each worker only “knows” the list of approved IDs, not the real-world information about the entities.

Execute Matching Between Supply & Demand

  • Upon authentication, eligible workers fetch consumption and generation data independently from external data sources via API. The frequency of this process depends on the desired granularity for matching (hourly is most common, but currently workers can support matching at one minute intervals).

  • Workers run the matching logic to match consumption and generation data based on the predefined algorithm. The matching algorithm factors in parameters such as the volume of renewable generation in the current time step, the volume of electricity consumption, consumer preferences (e.g. price they are willing to pay for renewables, preferences for specific types of generation like solar vs. wind, etc.), and any other rules that govern matching within that market.

  • The consensus among workers triggers the issuance of granular renewable electricity certificates for that time interval and transfer / retirement of these certificates to the given consumer.

Reporting

Every worker creates a hash of the result using the keccak256 (SHA-3) hash algorithm. Thus, every single match is transformed into a Merkle Tree. Then from all transformed matches are nested within another top-level Merkle Tree - the hashed result of each voting round. The advantage of using this technique is the ability to verify what's inside each hash without revealing any properties to the public.

The purpose of using worker nodes for 24x7 matching is to have a robust system for being able to verify computations and results without having to trust one single party. The idea is to allow multiple parties to process the same data and logic independently. If a majority of these parties arrive at the same result, then the computations are very likely to be true and can be trusted. These events (consensus and derived results) can then be anchored on the blockchain to have an audit trail for further verifiability of results. Another advantage is redundancy. If one worker is down for whatever reason, then there are multiple other parties to fetch and process the data. This helps avoid downtime of a system and smooth user experience.

PreviousUse Cases and Reference ImplementationsNextSustainable Aviation Fuel

Last updated 5 months ago