Enterprise Data Exchange is a customizable solution for authorizing, delegating, and delivering messages between a multiplicity of companies, systems, and assets operating in a common market environment without relying on a central administrator or broker. It is an extension of electricity market flexibility and e-mobility solutions developed in the Energy Web community over the last five years.

• Data Exchange Overview

• Data Exchange Architecture

• Channels and Topics

• Use Cases and Reference Implementations

  • Digital Spine for Electricity markets

  • E-Mobility Management

Energy Web is an independent nonprofit accelerating the global energy transition by developing open-source Web3 software solutions that help companies unlock business value from clean and distributed energy resources. This site provides an overview of the foundational concepts, technical components, and use cases of the Energy Web Decentralized Operating System (EW-DOS).

EW-DOS gives companies simple tools to deploy custom applications and business networks that combine established protocols and platforms with pioneering technologies and novel architectures.

💡 Get Started

Learn More about EW Solutions

Energy Web's tech stack is designed to address two primary challenges in the current energy and renewables market:

Learn More about EW-DOS Components

Click on any of the boxes below to learn more about the EW-DOS technical components.

Learn about EW-DOS foundational concepts

Develop with the Energy Web Chain

A Note on this Site's Documentation

EW-DOS builds on the foundations of other open-source technologies and uses many well-known libraries and technologies in the stack, so this documentation provides references and links to other articles and sources of documentation throughout.

We encourage you to become familiar with the core concepts of blockchain technology and if you are new to this space. The Foundational Concepts section provides brief explainers for what we think is essential to understand our technology. They point you toward more in-depth resources and documentation.

We are an open-source foundation and we want our solutions to be accessible and our community to be wide. Please provide feedback or questions on the documentation by reaching out on , , or .

The EV Dashboard is an application which aggregates OCPI data (via the OCN) and Blockchain data for both EVs and charge points. It also facilitate the request and issuance process for credentials relating to a flexibility market.

The dashboard client is available on Github at

Energy Web Data Exchange simplifies communication and business logic execution in complex markets by replacing heterogeneous point-to-point integrations among participants with a hub-and-spoke model in which all participants maintain a single integration to communicate with all other parties. Unlike conventional hub architectures that rely on a central broker to administer access and host the infrastructure, EW Data Exchange combines multiple open-source technologies to establish a shared platform that is owned, operated, and governed by multiple participants.

EW Data Exchange is tailored to execute high-volume, business-critical communications in electricity markets and e-mobility applications, but can be customized to support any business process involving data exchange between multiple organizations. Enterprise Data Exchange is protocol agnostic, and supports established standards including IEEE 2030.5, XML, OADR, and OCCP.

In its simplest form, Data Exchange is a secure, open-access messaging infrastructure that:

• Allows multiple parties to send, receive, and authenticate messages based on the roles that have been issued to and associated with their self-managed identity;

• Allows parties to exchange diverse datasets, ranging from real-time telemetry to bulk file uploads, in support of multiple DER and e-mobility use cases;

• Provides end-to-end encryption for all messages and data transfers, using cryptographic signatures from self-managed identities;

• Requires only a single integration mechanism with a central infrastructure in order to communicate via one:one (bilateral), one:many (broadcast), and many:many (multicast) channels.

Data Exchange can support a wide variety of use cases, including:

• Coordinating DER installation data among installers grid operators

• Streamlining DER registration in wholesale and/or local markets

• Enabling seamless roaming and advanced tariffs for electric vehicles

• Coordinating real-time grid operations between transmission and distribution system operators (operating envelopes, local constraints)

• Facilitating customer switching between retailers in deregulated markets

• Consolidating disparate market operations communications channels and processes (e.g. registration, nomination, bids/offers, dispatch, settlement)

• Establishing dynamic registries for DERs and EVs

A use case is defined by a particular configuration of a messaging channel (i.e. who is allowed to read/write, how messages are routed) and data schema (the format, frequency, and logic governing messages). Thus Data Exchange is a practically infinitely customizable solution; much like the way a road supports many types of transportation (from cars, to bicycles, scooters, trucks, etc.) Data Exchange provides a foundation for many types of business processes in electricity markets.

Who is it for?

EW Data Exchange can be applied in any energy market context where many-to-many data exchanges are critical. Companies or consortia can design how user roles are defined and acquired; what data structures and protocols are supported; and what types of integration options are made available to participants.

• Wholesale market & transmission system operators who need a solution to facilitate data exchange among market participants and distribution system operators in order.

• Distribution utilities who need to coordinate local services and non-wires alternatives with multiple vendors or aggregators.

• E-mobility service providers and charge point operators who want to reduce the cost and complexity of managing e-roaming and advanced charging programs.

• Industry consortia

EW Data Exchange allows companies seeking to offer / build / operate market-wide data exchange hubs to define the following aspects:

• Onboarding and issuing roles to organizations, systems, assets and users with DIDs, via the SSI-Hub

• Configuring role-based permissions, conditions, and restrictions for users

• Defining data structures and protocols

• Defining hosting and integration patterns (e.g. self-hosting clients, exposing APIs)

• Establishing communication channels between participants

• Scheduling jobs for batch processing and caching of data

• Use the channels for passing data between participants

24/7 Clean Energy

An initiative for purchasing clean, carbon-free energy every hour on a regional grid where consumption occurs. An entity's clean energy demands are correlated with its energy generation on an hourly basis.

Aggregator

A new role in energy service provision that groups local participants in a power system (energy consumers, energy producers, energy prosumers) to determine and moderate how much energy they will need to consume from the grid, and, in some cases help them sell their excess electricity from distributed energy resources (DERs) back to the regional or wholesale electricity market.

The aggregator is an intermediary between prosumers, Transmission System Operators (TSOs), and Distribution System Operators (DSOs) that want to serve this group or use their DER services on the grid.

Application Registries

Application registries are the logic to manage permissions, enrollments, and relationships between market participants in an automated way.

Charge Point Operator (CPO)

The Charge Point Operator (CPO) is responsible for technical operation and maintenance of (public and semi-public) charging stations. Its revenue comes mainly from providing electrical energy to EVs.

Crypto Climate Accord (CCA)

The Crypto Climate Accord (CCA) is a global private sector-led initiative co-launched by Energy Web to build, test, and implement digital solutions that will decarbonize the crypto and blockchain industry by 2040. Learn more here.

dApp

A decentralized application (dApp) is an application built on a decentralized network that combines a smart contract and a frontend user interface.

Decentralized Identifier (DID)

DIDs **** are persistent identifiers that identify DID subjects such as assets, customers, organizations, and other market participants. DIDs allow the controller of a DID to prove control over it without requiring permission from any other party. DIDs associate a DID subject with a DID document to allow trustable interactions with that subject.

Decentralized Service Bus (DSB)

The DSB is the messaging service of the Energy Web Decentralized Operating System’s (EW-DOS) utility layer. Unlike any other centralised and managed pub/sub messaging systems, EW-DSB is designed and implemented to be fully decentralised and scalable. Messages shared on EW-DSB can be traced back to its original sender using cryptographic signatures; it adds extra security to data exchanges. One of the key benefits of the EW-DSB is to be schema agnostic, meaning any type of schema can be shared as a message between users/systems.

Distributed Energy Resources (DER)

Physical and virtual assets that are deployed across the distribution grid can be used individually or in aggregate to provide value to the grid, individual customers, or both.

DERs can for example include solar, batteries, flexible loads and are also often referred to as “devices” or “assets”.

Distribution System Operator (DSO)

The operating managers (and sometimes owners) of energy distribution networks that operate at a regional or local level. DSOs manage high-voltage incoming electricity from larger transmission grids (via TSOs), convert it to a lower voltage, and distribute it throughout the local network. They are, in essence, the middle-man between the raw, high-voltage electricity from transmission grids and the local consumers of electricity.

E-Mobility Service Provider (eSMP)

The eMobility Service Provider (eMSP) provides e-mobility services such as access to charging services, payment and more to EV drivers. It requires certain data exchange for those services, e.g. charging locations for routing.

Electric Power Distribution

The movement of high-voltage electricity from sub-stations to customers through distribution lines.

Electric Power Transmission

The movement of high-voltage electricity from initial generation sites to substations.

Energy Attribute Certificates (EACs)

Energy Attribute Certificates (EACs) describe global instruments which certify that a specific unit (historically 1 MWh, but sometimes 1 KWh) of electricity was produced from a renewable source.

Globally there are various EAC systems to claim the use of renewable or low-carbon energy. Some well-known standards include Guarantees of Origin (EU), I-RECs (global), and RECs (US/Canada).

• Redeemed EAC = an EAC that has been bought by someone can't be resold to anyone else

• Claimed or Cancelled EAC = other ways of calling Redeemed EACs

• Bundled Certificates = contracts that sell consumable energy + EACs together

• Unbundled Certificates = contracts that sell EACs separately from the energy that produced them

Energy Web Chain (EWC)

The EWC is a public, enterprise-grade blockchain platform designed for the energy sector’s regulatory, operational, and market needs. Launched in mid-2019, it serves as a foundational digital infrastructure on which companies can build and run blockchain-based decentralized applications (dApps). Learn more here.

Energy Web Decentralized Operating System (EW-DOS)

EW-DOS is the acronym for Energy Web Decentralized Operating System. EW-DOS is an open-source stack of decentralized software and standards. **** Learn more here.

Energy Web Token (EWT)

The EWT is the Energy Web Chain native first-layer utility token.

Grid Flexibility

The ability of the grid to balance how much power it generates with how much demand there is for it. Flexibility services include any service that meets a requirement to provide more or less demand on the system. ****

At a basic level, Transmission System Officers (TSOs) and Distribution Service Operators (DSOs) procure flexibility services. Aggregators and prosumers offer flexibility services using distributed energy resources.

Message Broker

A distributed messaging node which can send OCPI messages between OCN Parties.

Open Charging Network (OCN)

A decentralized network for enabling use-cases in the EV charging domain. Consists of many OCN Nodes and a single OCN Registry. Can also be considered as an implementation of the OCPI 2.2 Hub concept.

Open Charge Network (OCN) Identity

A self-sovereign identity of a party on the Open Charging Network based on an Energy Web Chain public/private key-pair.

Open Charge Network (OCN) Node

**Open Charge Network (**OCN )Node

A single node of the Open Charging Network which forwards OCPI/OCN messages between parties based on a routing system. Consists of a message broker, a connection to an Energy Web Chain Node, a blockchain wallet and more. A network of nodes constructs the Open Charging Network.

Open Charge Point Interface (OCPI)

A protocol that allows for a scalable, automated roaming setup between Charge Point Operators and eMobility Service Providers. See OCPI documentation here.

Open Charge Network (OCN) Registry

Smart contracts on the Energy Web Chain that contain important information about registered OCN Nodes, OCN Parties and OCN Services. These contracts act as the addressing, identity, and permissions system of the OCN. A command line interface and libraries are provided for interaction.

Original Equipment Manufacturer (OEM)

A company that manufactures and sells products or parts of a product that their buyer, another company, sells to its own customers while putting the products under its own branding.

Prosumer

Anyone who both consumes and produces energy. Prosumers produce energy through Distributed Energy Resources (DER), such as rooftop solar panels.

Self Sovereign Identity (SSI)

SSI is a digital paradigm that promotes an individual’s control over their identity and their data. This is in contrast to the current paradigm where most of our official identifiers (driver’s license, birth certificate, usernames, etc.) are given to us and maintained by a central authority, and where our data can be shared without our knowledge or consent.

DIDs and VCs are the two most critical components of SSI. Together they allow users to have control over both their identity and any data associated with them.

Software Development Toolkit (SDK)

An SDK is a collection of software development tools in one installable package. They facilitate the creation of applications. In the context of Energy Web, they are open-source “blueprints” for building apps on EW-DOS.

Staking

Energy Web launched staking on the Volta Test Network in August 2021. This is a first step towards a Decentralized Software as a Service (dSaaS) infrastructure, allowing for decentralized, community-driven service provision for Energy Web utility services and applications.

The Energy Web staking model extends blockchain tokens staking to SaaS provisioning. Ultimately, anyone will be able to stake tokens with service providers of their choosing, and both parties will be rewarded for providing fast, stable and secure services based on EW's decentralized, open-source software. Staking in the way Energy Web is implementing it, applies the benefits of decentralization and network resiliency of blockchain technology to software and IT services more broadly.

Supervisory Control And Data Acquisition (SCADA)

Supervisory control and data acquisition (SCADA) is a system of software and hardware elements that allows industrial organizations to i) control industrial processes locally or at remote locations; ii) monitor, gather, and process real-time data; iii) directly interact with devices such as sensors, valves, pumps, motors, and more through human-machine interface (HMI) software; and iv) record events into a log file.

Switchboard

Switchboard is an identity and access management dApp (decentralized app). Switchboard allows for the definition of organization and application structures to be used for role-based permissioning within applications that relate to decarbonization.

It enables a user-centric, decentralized approach where users are in control of their identity (identifier, keys, credentials). Switchboard enables the digitization of assets by giving them unique identities and allowing them to interact with the decentralized operating system and decarbonization use cases.

Transmission System Operator (TSO)

Responsible for transmitting electrical power from power generation plants to distribution local or regional operators (Distribution Service Operators) via the electrical grid. This involves determining how much electricity needs to be on the grid at any given time, and managing reserve capacity and ancillary energy providers to keep the grid balanced.

Utility Layer (UL)

The UL is composed of decentralized cloud services like messaging, key manager, and storage that form the “middle” layer of the EW-DOS tech stack.

Validators

"Validators" refer to both a node and an organization; the companies operating the EWC. Validators on the Energy Web Chain have three main responsibilities: i) Create Blocks, ii) Provide Network Security, and iii) Participate in the EWC Governance.

Verifiable Credentials (VC)

VCs are a set of statements made about a subject (such as a DID) by an authority. They can be used to convince others (who trust the authority) of the truth of the statements and can be linked from a DID document.

{coming soon}

In order to connect a service to the OCN, you must choose which OCN node you want to connect to, and know the node's public wallet address. You will then request a registration token (Token_A) from your selected node.

1. Select a node

In order to connect a service to the Open Charging Network, you must decide which OCN Node you want to connect to.

Test Network

To view public nodes available on the public test network and their wallet address, see "".

Production Network

To view public nodes available on the public test network and their wallet address, see "".

2. Request a Token

Once you select a node operator that you want to connect to, you must:

1. Know the OCN Identity (wallet address) of that OCN Node Operator ().

2. Request a registration token (TOKEN_A in OCPI terms). Note that this token is only temporary and will become invalid once the registration is complete.

3. Enter Node details in OCN Registry

After you have the public address of your public node and your registration token, you are now ready to create / update your OCN Identity on the OCN Registry. Follow the steps provided here:

The Open Charging Network allows you to exchange OCPI messages with anybody on the network with just one single OCPI connection, regardless of the OCN Node that you or your counterpart are connected to.

There are some cases in which you want to restrict the list of parties that can communicate with you. For this, the OCN Node provides you with a white- and blacklisting module, called OCN Rules.

Note: This service is an optional feature that needs to be enabled in your own OCN Node or by your OCN Node Operator.

Example: add party to blacklist

• You can find a documentation of how you can use this service on the under OcnRules module.

• See the source code for the OCN node Rules service .

Overview

The OCN Service Interface enables third-party services (such as billing, settlement, location data enrichment) to offer their products to the OCPI community by accessing communication between two OCPI parties on the Open Charging Network without the need for endless API development work.

This is done using OCN Permissions, and requires no additional integration work to be done by the OCPI parties.

It reduces the cost for integration work beyond the EV roaming use-case, helping everyone involved climbing the API mountain of Electric Vehicle charging.

We consider this as crucial to a seamless mass-consumer experience and an efficient EV charging value-chain.

Get Started

As an OCN Service Provider

Learn how to connect your OCN Service to the OCN and to define what OCPI-based information your service needs from OCN Parties / Service Users (OCN Permissions).

As an OCN Party / Service User

Learn how to sign up for an OCN Service by agreeing to OCN Permissions.

Demo

To get started with the OCN Service Interface and to see how the above given example works in action, see our OCN Demo. It mocks a full set-up of an Open Charging Network with two OCN Nodes, two CPOs, one eMSP and one billing service and allows developers to run through the scenario outlined in this article. Get started .

An OCN Service Provider develops and provides OCN services that can be used by CPOs, eMSPs and other parties to improve their charging services - such as contracting, billing, payment systems etc.

The OCN Service is - similar to any other OCPI role - an OCN Party. We make this distinction from other "Services" that might only require customers to send OCPI messages (including custom OCPI modules) directly.

Offer your OCN Service

To offer your OCN Service via the OCN Service Interface, make sure the following prerequisites are met:

Now you are ready to publish your OCN Service on the OCN Registry.

Set Service Permissions

An OCN Service is an OCPI party that requires additional permissions from their customers. Such permissions could include the forwarding of session or charge detail record data, for example in a payment service.

Once a customer/user has agreed to the Service's permissions, the OCN Node tied to the customer will automate any such required permissions, lessening the cost of integration with a service.

To be granted the aforementioned permissions, you must then list your OCN Service and the permissions required in a separate smart contract, entitled "Permissions". Thereafter, a user can make their agreement explicit in the same smart contract. Learn more on how to list your OCN Service on our .

You can find a full list of currently implemented OCN Permissions .

If an OCN user wants to make use a particular OCN Service, it has to agree on to the Service's permissions. The OCN Node tied to the customer will automate any such required permissions, lessening the cost of integration with a service

To make use of an OCN OCN Service via the OCN Service Interface, make sure the following pre-requisites are met

3. Your preferred OCN Service is connected to the OCN

You are now ready to give the OCN Service its required permissions.

Learn more about how to do that on our .

Leading examples of Data Exchange Implementations include:

• E-Mobility Management [coming soon]

Energy Web X is an open-source, public, substrate-based blockchain purpose-built to support .

To learn more about the role of Energy Web X within EW-DOS, read the .

Hardware wallets are a physical device. They provide an added layer of protection as the wallet’s private key is not stored in your browser or even on your machine - it is stored on the hardware device itself. is a widely-used hardware wallet, and it supports most major cryptocurrencies, including all and. We provide direction on how to connect your Trezor Hardware Wallet to MetaMask here (link), and to a local node of the blockchain here(link)

Overview

DDHub Message Broker is a component that primarily provides message routing, persisting, and delivery for a seamless data exchange between participants within an energy market or supply chain.

The message broker promotes sovereignty of participants by:

• The broker does not have authority or logic which assumes the power of the participants

• No one except the participant themselves can govern data exchange channels and verify messages

• Encryption/decryption, signature validation, authorization, etc must be done under the participants domain ()

DDHub Message Broker Component Diagram

Below are the Message Broker components which need to be hosted to deploy a Decentralized Data Hub:

• Message Broker App

• NATS Jetstream and Jetstream Store to store small data messages (small messages up to 2 MB) and channel configurations

• Azure Blob (or other large file) Store for large data messages and delimited files converted into blobs, as well as file metadata

• RDBMS for message topic and schema management

A cryptocurrency wallet is a digital wallet to manage your cryptocurrency. Just like you need an email address to manage your online communication, you need a cryptocurrency wallet to manage your crypto.

A cryptocurrency wallet has two keys, . Your public key is also called a receive address and you send it to people to receive cryptocurrency. Just like you send your email address to people to receive an email message. A private key gives you full rights and full access to your wallet. It is extremely important that only you have access to your private key and that you don’t share this with anyone. This is the key to your wallet, similar to a password to your email account.

Background

Adoption of electric vehicles (EVs) is growing exponentially around the world, and EVs are on pace to represent a significant share of the global transportation sector this decade. Collectively, EVs represent an opportunity to both accelerate decarbonization in the energy sector and introduce innovative new business models. Emerging opportunities for EVs include:

1. Grid balancing and demand response: EVs can provide multiple grid services (e.g. peak shaving, voltage support, etc.) by adjusting their charging patterns based on grid conditions. Smart charging systems can optimize charging schedules to avoid overloading the grid during peak demand periods, or consume excess variable renewable energy duriong periods of low demand. By acting as demand response resources EVs can help flatten demand peaks and reduce strain on the grid, thus enhancing its efficiency and reliability.

2. Grid flexibility and storage: EVs can act as distributed energy storage units. With smart charging infrastructure and vehicle-to-grid (V2G) technology, EV batteries can be used to store excess electricity during times of high renewable energy production. This stored energy can then be fed back into the grid during periods of high demand or when renewable generation is low. V2G technology allows bidirectional power flow between the grid and EVs, enhancing the grid's flexibility and stability.

3. Accelerating deployment and increasing utilization of renewables: As a major consumer of electricity, EVs can drive demand for carbon-free electricity through clean energy tariffs, purchases of environmental attribute certificates, or even carbon-optimized charging. EV charging infrastructure can be colocated and powered directly by renewable energy installations, and EV charging strategies can be optimized to charge EVs during hours with plentiful supply of renewables.

While these opportunities are promising, fully realizing their potential is challenging due to complex relationships between multiple stakeholders, the highly distributed and diverse nature of EV and EV charging infrastructure, and the sheer volume of EVs.

EW Data Exchange builds on the capabilities first introduced in the Open Charging Network to deliver EV drivers, grid operators, charge point operators, vehicle manufacturers, retailers, and other EV service providers with a comprehensive and cohesive solution for sharing and validating data.

Reference Implementations

• Open Charging Network 2.0: A next-generation implementation of the OCN is currently under development. OCN2.0 will share many architectural features with the Digital Spine toolkit, but include several e-mobility specific features including built-in standards (e.g. OCPI) within the DDHub Client Gateway, as well as the ability to run the gateway within EV and EVSE equipment, to simplify integration between EV equipment and channels hosted in the DDHub Message Broker. OCN2.0 will also feature dedicated Worker Node networks to verify and validate message routing between participants, as well as execute custom business logic involving multiple companies (e.g. smart charging, V2G, etc.).

• Real-time Locational Green Charging: Combining the Data Exchange solution with the 24x7 Green Proofs toolkit enables advanced green charging tariffs and programs that match locally-available carbon-free generation with specific EV charging events in near real-time.

Software License

Our mission is to develop and deploy an open and decentralized digital operating system for the energy sector in support of a low-carbon, customer-centric energy future. Therefore, the Energy Web Foundation publishes the source code of its software projects under the GNU General Public License Version 3+. Some libraries intended to be distributed with hardware devices are released under the LGPLv3+.

Frequently Asked Questions about the GNU Licenses

https://www.gnu.org/licenses/gpl-faq.html

Advantages of Free Software

A program is free software if the program's users have the four essential freedoms: [1]

* The freedom to run the program as you wish, for any purpose (freedom 0).

* The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.

* The freedom to redistribute copies so you can help others (freedom 2).

* The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

https://www.gnu.org/philosophy/free-sw.html

Data Exchange Context Diagram

Overview

The most common use case of the Open Charging Network describes an eMobility Service Provider (eMSP) or Charge Point Operator (CPO) connecting their backend service to an OCN Node. An OCN node provides an entry point into the system, so a party must connect to an OCN node in order to participate in the network.

Follow these steps in order to successfully connect your own backend service.

1. Make your backend service OCN-ready (implement the OCPI 2.2 API and OCN Signature)

2. Select an OCN Node and enter details in OCN Registry

3. Manage your White- and Blacklist

4. Connect your service to an OCN Node

*Note that not only MSPs and CPOs can use the Open Charging Network, but these are the most common roles.

The worker node is containerized and can be run on a virtual machine.

Requirement

• CPU: 2 vCPUs

• Memory: 4 GB

• Disk Space: 100 GB

• Operating System: Ubuntu 20.04 LTS

Create a Virtual machine

To create a virtual machine in your cloud provider. Ensure the virtual machine matches the minimum requirements listed in the above section.

Deployment Guide

Clone the following repository - GitHub - energywebfoundation/greenproofs-worker-guide

It contains the guide and files required to run the worker image.

Deploying Worker Image to Virtual Machine

Once connected to the VM. Follow the steps to run the container image.

Install docker

sudo snap install docker

Confirm docker and docker-compose are installed

docker -v docker-compose -v

Application setup

Once done, ensure to the .env file contains all environment variables required in the same directory as the docker-compose.yml file.

Finally, run the command

docker-compose up -d

This would bring up all services. You can reach out to the team for further help or check out the Docker Compose cheat sheet for more debugging tips here.

The DDHub Client Gateway is an integration gateway SDK that is intended to run on-premises or on the cloud environment of participants. It provides an interface for participant systems to interact with other systems in the shared interacting with a data exchange solution - namely, the DDHub Message Broker.

The Client Gateway is available in Github at https://github.com/energywebfoundation/ddhub-client-gateway or in the Azure Marketplace.

The gateway application is authenticated, authorized, and encrypted (messages) using self-sovereign identities (DIDs) and verifiable credentials rather than a centrally trusted and managed approaches seen in legacy solutions.

The client container is an integral part of the DDHub in achieving its decentralized characteristics as it assumes the power of the identity that it currently holds/represents.

• DDHub Client GW UI: the main interface for admins to manage their DDHub Client GWs

• DDHub Client GW API: exposes RESTful and Web Socket APIs for integration

• DDHub Client GW Scheduler: contains scheduler jobs for caching data including but not limited to channels, topics, and decryption keys

• DDHUB Client Gateway Storage: a postgres DB used to store configuration data.

• Key Vault - store private keys and other secrets

• DDhub Message Broker: The component that routes messages between Client gateways (using API to control NATS messaging).

• SSI Toolkit: Libraries and components that implement identity and access management functionalities.

The Energy Web Decentralized Operating System gives companies simple tools to deploy custom applications and business networks that combine established protocols and platforms with pioneering technologies and novel architectures.

The Decentralized Data Hub (DDHub) is one of the primary technologies underpinning EW Data Exchange solutions. The DDHub Environment is composed of multiple DDHub Messaging Client Nodes interacting with each other through the DDHub Message Broker.

• Each node (or group of nodes) in the Message Broker cluster is identified with a unique DID and must be issued with a DDHub Messaging Client role

• Each node contains an IAM Client that ensures legitimacy of users interacting within the messaging cluster by checking their identities, and issued role or set of roles\

• The IAM Client and DIDs provide a layer of protection against unauthorized access to DDHub functionalities

• Data exchanged within the cluster is secured in transit with mTLS

Reaching Consensus

Voting Manager

Caching Results

Worker Nodes are a new technology developed by Energy Web that enable enterprises to construct distributed computing networks that securely execute sensitive business operations impacting multiple companies.

What are Worker Node Networks?

Worker Nodes were originally developed to solve a paradox that hinders advanced renewable energy tracking solutions like 24x7 matching and green electric vehicle charging: credibility relies on accurate, publicly verifiable results (e.g., proof that digital representations of renewables are not double-counted). But inputs from separate organizations, such as granular renewable energy production and electricity demand data, are commercially sensitive and need to remain private. Complex commercial, legal, and technical requirements often make it challenging for a single actor to unilaterally access and process all requisite data. The ability to establish a shared source of truth from segregated, individual information sources has been an ongoing challenge in multilateral settings; the challenge is even greater for energy market participants seeking to exchange and process granular data in order to procure services from distributed energy resources.

The Energy Web Worker Node toolkit solves these challenges by enabling enterprises to configure, launch, and maintain distributed computing networks that ingest data from external sources, execute custom workflows based on business logic, and vote on results in order to establish consensus without revealing or modifying the underlying data. Worker Nodes apply concepts and components from blockchain technology in a novel, enterprise-friendly architecture to provide all stakeholders with cryptographic proof that mutually-agreed rules and and processes are followed correctly, ensure computational outputs from business processes are correct, and preserve the privacy and integrity of underlying data for auditing purposes.

Why are Worker Nodes beneficial for the energy sector?

Decarbonizing the global energy sector is the most important solution to mitigate climate change. Worker Nodes can help accelerate decarbonization in two specific areas that require coordination and information sharing among multiple independent actors. The first is (e.g., rooftop solar systems, batteries, electric vehicles, electric vehicle charging stations, heat pumps) to the grid. The second is bringing —including but not limited to , , and .

The solutions we apply to these areas, dubbed and , are powered by a brand-new web 3 technology that has significant business value for energy enterprises: . Each worker node network is a decentralized group of computers that jointly execute sensitive business processes that involve or impact multiple companies. Though worker nodes establish consensus about the results of a business process, they are not blockchains. Whereas the “work” performed by traditional blockchain miners or validators—validating and sealing blocks—has limited value for energy enterprises, worker node networks are fine-tuned to execute custom logic that is specific to an actual business problem. Worker node networks are only useful in cases where multiple businesses need the capability to transmit complex datasets amongst three or more parties in a way that does not reveal all data to all parties, and/or the capability to provide public verification of outputs while maintaining privacy and integrity of inputs.

How do Worker Nodes actually work?

Today worker nodes are implemented as independent off-chain computing nodes that communicate with a smart contract deployed on the Energy Web Chain. Worker nodes can be implemented in any development framework, including node.js, python, and rust.

Each worker node is programmed to execute a specific conditional logic workflow based on a predefined dataset (i.e. source and schema) and event trigger (e.g. a regular time interval, or a specific external event). Workers are given read-only access to one or more external data sources via API or message broker. When the workflow “event” is triggered, the workers initiate a round of calculation and voting (worker nodes can be configured to either poll an external data source at regular intervals, or “listen” to an external source for a specific trigger).

In the calculation step, each worker node independently executes the conditional logic based on the data it received during the trigger. Then, each worker submits its results (i.e. output of the logic workflow) to the smart contract, which collates the worker nodes’ votes into a unique voting round and keeps track of each round to maintain continuity. The smart contract defines a voting threshold (typically a simple majority, such as 2 of 3, or 4 of 7, etc.) that must be reached in order to establish consensus on the results of each voting round. Each voting round is defined by a voting ID, the number of unique votes (from worker nodes), and a consensus result. If the threshold is reached (i.e. a majority of nodes independently reach the same conclusion and submit identical results to the vote), then the voting round is closed and the result is hashed on the Energy Web Chain; this creates a connected tree of results that can be queried and validated for auditing purposes. If consensus is not reached in the voting round, the entire process from event trigger through voting is repeated; if a second round fails, a custom workflow is executed (this can include alerts, failover to other nodes, or acceptance of results from a plurality of workers).

In addition to collating the voting results, the smart contract is configured to issue rewards for workers in the pool based on performance criteria. A base reward can be issued simply for workers being available in the pool, and additional rewards can be issued based on metrics such as consistency (i.e. availability for all voting rounds), accuracy (i.e. being part of the winning consensus), and speed (i.e. being fastest to submit voting results following the event trigger).

1. Choose a hosting provider (on-premise or qualified cloud provider) and favored operating system.

2. Install operating system and prepare host according to the OS Installation Guide (see previous lesson)

3. Find the Client installation script matching the installed OS on the energyweb github: and copy it from the volta-affiliate/openethereum or volta-affiliate/nethermind directory to the host

4. Make sure the latest system updates are installed by running apt-get update

   (debian/ubuntu) or

   (centos)

5. Make the script executable with

6. Run the script (please do not use the

   parameter which can be used to take default for node-name and generate a random key)

   • First review any to see if there is a known issue.

   • If the issue is not already known, email to troubleshoot.

7. If the installation was successful, it should generate a .txt file (named install-summary.txt) that lists the node address, IP address, , influxDB username/password. You will need to provide these details via a form in the next step to successfully add your validator node to the .

   • If you encounter issues with the installation or the install-summary.txt file is not generated:

     • 1. First review any to see if there is a known issue.

       2. If the issue is not already known, submit a question in the #validators or #technical_questions channels in the to troubleshoot.

8. Submit the Volta node installation details .

   1. After submitting the installation details, you will receive another email with instructions for proceeding to the main EW Chain.

The Energy Web Chain is comprised of different components that provide the functionalities determined by the blockchain’s protocol.

Broadly speaking, protocols are defined rules and standards. Internet protocols, like HTTP protocol for example, define standard procedures for the transfer of data over the internet.

A blockchain network is no different. In a decentralized and self-executing system like a public blockchain, protocols are of significant importance in establishing how the system works, and then ensuring that the system continues to self-execute as designed.

Protocols exist to determine specific aspects of blockchain behavior, such as:

• How transactions are validated

• Who gets to validate transactions and when

• How validators are compensated

• How peer nodes interact with each other

The system components below ensure that the Energy Web blockchain adheres to Ethereum's protocols, and the protocols established by OpenEthereum's . (OpenEthereum is the Ethereum client that is used by the Energy Web Chain. You can read more about the purpose of Ethereum clients )

System Components

System Contracts are that implement the protocols. Read more about Energy Web's system contracts

The validator node architecture monitors validator behavior to ensure consistent and secure blockchain operation. Read more about the validator node architecture

Related Content

1. Install MetaMask

You will need to (or another Ethereum wallet) to connect to EW-DOS applications on the Volta test network or the main network, and to sign transactions on the blockchain.

Read more about using MetaMask .

2. Get Tokens

If you are using applications or smart contracts on the , you will need .

• Learn how to get Volta Tokens .

• Once you have Volta tokens, you will need to .

If you are using or developing applications or smart contracts deployed on the , you will need to have .

• Learn how to get EWT .

• Once you have EWT, you will need to .

3. Using EW-DOS

Learn about Volta Testnet and Energy Web Mainnet

See an Overview of the EW-DOS Tech Stack

1. Alice creates a digital identity

She can manage her data and consents using a unique, secure digital signature

2. The data is encrypted and inaccessible to anyone without Alice’s consent

3. Alice can share her data with others

• She must explicitly consent to this

• She can revoke her consent at any time

• The recipient does not store the data

• She can prove or reveal attributes without revealing the entire underlying data

4. Alice can add verified data from others, if she chooses

5. Alice can then consent to share that verified data with a third party

6. The third party can see both the data and its verified source

7. If/when conditions (e.g., contractual relationships) change, Alice modifies her consent to change permissions for ADRs

Alice keeps her digital identity in perpetuity; there is no need to re-register / duplicate digital identities across different systems

This architecture can be applied in any market context and with other types of data

is a browser extension and a mobile app that handles blockchain account management and helps users securely interact with web dApps. It’s supported in Chrome, Brave, and Safari browsers, as well as it is available for Android and iOS devices. By default, you can connect to the Ethereum Mainnet or any of the Ethereum test network.

To interact from your browser with Energy Web or the testnet Volta, you need to add settings to Metamask and point it to the right network.

Using MetaMask with Other Blockchains

MetaMask is compatible with any blockchain that uses an Ethereum-compatible . This is why we can connect to the Energy Web mainnet and the Volta testnet with MetaMask via a custom Remote Procedure Call (RPC). We provide directions on how to do this . By default, MetaMask connects to the blockchain using and nodes. This allows you to connect with the blockchain without having to run a node yourself.

MetaMask was designed as both an Ethereum-compatible wallet and a method for decentralized application (dApp) verification.

1. Store and transfer Ethereum compatible (ERC20) tokens

2. Connect to other Ethereum-based blockchains using a remote procedure call (RPC)

3. Store and transfer utility tokens for other Ethereum-based blockchains, like the Energy Web Chain. (You must be connected to that blockchain network to do this.)

4. Authenticate into Dapps and sign transactions. The key-pair for each account generated by MetaMask serves as your cryptographic signature

5. Connect to a hardware wallet and initiate transactions using an account on the hardware wallet

It's important to understand that MetaMask provides user sovereignty in Ethereum-based decentralized applications. Instead of having a separate username and password for each decentralized application that you interact with, you can authenticate into all of them using your account(s) in MetaMask. MetaMask accounts are initialized by you and are under your authority.

Hierarchical Deterministic (HD) Wallets

Many cryptocurrency wallets (including and Trezor) are Hierarchical Deterministic Wallets (HD Wallets).

Using a protocol called , HD Wallets allow you to derive multiple accounts that support different types of coins from one master private key. For each HD Wallet, there is one 12-24 word mnemonic seed phrase. The algorithm associated with BIP44 forms a tree using the seed phrase. Account information (public addresses and private keys) for different tokens or currencies exist at different branches of the tree. This ensures that you get a different address information for each token. You can recreate this tree in a new wallet by importing your mnemonic seed phrase.

Derivation Paths

A path called a 'Derivation Path' provides a logical hierarchy for the wallet to use to search the tree for a user's address information at a specific branch (for a specific coin type).

Derivation Path Components

• The path typically starts with "m'" for "master"

• The second figure is the purpose. This is a constant, always set to '44' for . It indicates that this branch of the tree is compliant with BIP-44 specifications.

• The third figure denotes the coin type for a specific blockchain. Ethereum, for example, is always "'60". Energy Web Chain is "'246". (You can see all of the registered coin types for BIP-44 .)

• The fourth figure is the account. Accounts are numbered from index 0 upward. A user can have many accounts associated with one currency. You can liken this to having multiple accounts at a single bank.

• The fifth figure is the change. It can be a value of 0 or 1. 0 denotes that the address is visible to others outside of the wallet and can receive payments. 1 indicates that the address is not visible to others outside of the wallet and cannot receive payments.

You can find documentation for the BIP-44 .

Derivation Paths and Energy Web Chain

If you are using a hardware wallet and are not using it through a connection with MetaMask, you may need to change the derivation path to Energy Web Chain's derivation path to see your EWT in your account.

Energy Web Chain's derivation path is m/44'/246'/0'/0

SSI Hub

NodeJS server application using NestJS framework. The server caches specific smart contract data such as ENS namespaces and DID documents in order to improve read-query performance for applications and packages that rely on on-chain data.

The SSI Hub also facilitates the credentials exchange between credential requesters and issuers, which enables other applications such as Switchboard or Decentralized Service Bus to use credentials for role permissioning.

SSI Hub persists the following information that is created, read and updated by the IAM library:

• Organization namespaces

• Application namespaces

• Role namespaces

• User credentials

Documentation Resources

• GitHub repository

• ReadTheDocs

See an overview of all Identity and Access Management (IAM) components in EW-DOS here

Dependencies and Dependents

What are cryptocurrency wallets used for?

Cryptocurrency wallets are used to:

1. 'Store' and exchange cryptocurrency - tokens or cryptocurrencies are actually stored as records on the blockchain itself, but they are associated with a user's private key, which is stored in a cryptocurrency wallet.

2. Authorize transactions on a blockchain

There are many different wallets available, many of which are built to be compatible with a specific blockchain like Ethereum or Bitcoin. You can choose to use a hardware wallet (discussed below), use only software or web-based wallets, or use a combination of both.

Cryptocurrency wallets are used in decentralized, peer-to-peer environments that have no central oversight or source of authority. Because of this, trust mechanisms are built into wallet functionality. Methods and implementations vary, but most cryptocurrency wallets use cryptographically seeded public-private key-pairs that serve as a way for users to identify themselves and safely validate and authorize transactions on the blockchain. The public key serves as their address in a network, and their private key (which should never be shared) serves as as a method for authorizing transactions. It serves as your digital signature. In EW-DOS, the user's public key is used as the identifier in their DID that is anchored on the blockchain. You can read more about this here.

Regardless of your choice of hardware wallet, we highly recommend that you use MetaMask when developing with or using EW-DOS. MetaMask is a browser-based cryptocurrency wallet. It is both an Ethereum-compatible wallet and a gateway for using decentralized applications built on Ethereum-based blockchains like the Energy Web Chain. We discuss MetaMask's functionalities below.

Multisignature Wallets

A multi-signature wallet is a smart contract that allows multiple parties to agree on transactions before execution. It is analogous to a joint bank account.

One pain point of "traditional" crypto wallets is that anyone who has access to the wallet's private key has total authority over the wallet’s funds: they can move funds or perform transactions with no limitations or accountability.

If an account is managed by multiple people, each person knows the private key and can therefore make transactions at their discretion without group consensus. Risk remains even if an account is managed only by one person. In this case, if the private key is stolen, someone else now has total control over the wallet and the funds in it.

A multi-signature addresses these pain points. You can set multiple owners for a wallet and the number of minimum confirmations needed to perform transactions. It gives robust security for private users and businesses. Some benefits include:

• No single-point-of-failure: If your wallet has 3 owners and 2 confirmations are needed to execute a transaction (2-­of-­3 scheme), and one of the private keys gets stolen or lost, the funds can still be accessed, or the compromised owner's address can be removed or changed. A wallet with 2-­of-­3 scheme can tolerate 1 failure, a wallet with 3-­of-­5 scheme can tolerate 2, etc.

• Accountability: No more insider theft. The transaction history, details, and the approvers of a transaction can be viewed.

• Daily withdrawal limit: an amount can be determined that can be withdrawn daily without confirmations

• Ease of use: less operational burden than a hardware wallet

There are a number of multi-signature wallets for the Ethereum network. One of the most widely used is the Gnosis Safe Multisig. You can view the smart contracts for Gnosis Safe here.

Related Content

Accessing Your Energy Web Tokens in MyCrypto wallet

By using a Ledger Device (Hardware wallet)

To interact with EWT using your Ledger device, you have to use the EnergyWebChain app on your Ledger device, not the Ethereum app. If you do not have this app installed, you can use Ledger Live to install it.

After accessing your Ledger device with MyCrypto, you will notice that a list of different addresses will show up instead of the addresses that you would see if you were connected to the Ethereum network. You are free to use these for your Energy Web Tokens.

If you have accidentally sent EWT to your Ethereum addresses previously, you can still access these by clicking the drop-down field next to "Addresses" and selecting the "Ledger (ETH)" option.

You will see your Ethereum addresses displayed alongside their EWT funds.

By using a Trezor Device (Hardware wallet)

Access your Trezor device like usual. You will notice that a list of different addresses will show up, instead of the addresses that you would see if you were connected to the Ethereum network. You are free to use these for your Energy Web Tokens.

If you have accidentally sent EWT to your Ethereum addresses previously, you can still access these by clicking the drop-down field next to "Addresses" and selecting the "TREZOR (ETH)" option.

You will see your Ethereum addresses displayed alongside their EWT funds.

Accessing Your EWTB (Bridged) Tokens

Energy Web has developed the EWT Bridged (EWTB) token, which is an ERC-20 token on the Ethereum blockchain. You can mint EWTB tokens through its interface which you can find at bridge.energyweb.org. This method allows you to transfer EWT from the Energy Web Chain to the Ethereum blockchain.

If your Ethereum address contains EWTB tokens, you might not see them in your interface right away. In this case, you have to manually add this token as a custom token.

The contract address of EWTB is 0x178c820f862b14f316509ec36b13123da19a6054, you can also find this address on Etherscan.

The Energy Web Chain (EWC) is the foundational “trust layer” of the stack. The Energy Web Chain (EW Chain) is an open-source, public blockchain blockchain technology. It is the foundational trust and persistence layer of EW-DOS.

The blockchain performs three key functions in EW-DOS:

1. Provides the smart contract mechanism to store (DIDS)

2. Facilitates on-chain verification and transactions between parties

3. Executes smart contracts that are used by EW-DOS's decentralized applications, SDKs and utility packages.‌

The blockchain provides trust in several ways that allow for a decentralized system that is self-executing and without central authority or oversight of on-chain transactions:

1. The data in each block is immutable and unchangeable. Each is linked to the previous block by a cryptographically created hash. If one block is tampered with, the hash of every subsequent block in the chain would be need to be updated. Because Validators' consensus is required to create new blocks, a block with an alternative transaction history would be rejected by Validators.

2. Smart contracts provide automated logic for on-chain actions. Transactions on the chain are governed by code called that contain explicit logic and requirements for actions to occur. When specific conditions are met, the code will self-execute. Once a smart contract is deployed on the blockchain, it cannot be changed or reversed, removing the risk that anyone can update the logic of the contract for personal gain.

3. Cryptographic verification is required for . In order for an individual to verify any on-chain transaction, they must sign the transaction using their private key. This makes it impossible to perform a transaction unless you have the private key.

Persistence on the Energy Web Chain

The Energy Web Chain stores the following information:

• Smart contracts for that are created through EW-DOS's .

• Smart contracts that govern validator consensus behavior and remuneration. These are known as .

• Smart contracts that implement other Ethereum network protocols, such as permissioning and protocols.

• Smart contracts that contain logic and functionality specific to deployed on the Energy Web Chain and the that connect them and their users to the Energy Web Chain.

Related Content

Overview

The Open Charging Network is a decentralized implementation of the hub concept. Unlike traditional, centralized hub architecture, the OCN does not rely on a centralized server - the network is made up of a distributed network of server nodes. Anybody can run an OCN node.

Why Run a Node?

In the context of OCN, running a node means running and hosting an instance of the

There are several benefits to running your own node of the network.

• From an individual perspective, running a node makes you less dependent on external service providers

• From a network perspective, the Open Charging Network becomes more reliable the more nodes that are running

The following steps below help you to successfully set up and run your own OCN Node:

1. Setup and Configuration

Before running a node and connecting it to a local, test or production environment, it is recommended to become acquainted with how the network operates first.

For this, a demonstration of a network simulation with two OCN Nodes and mock parties ( and has been provided. Please visit this page to learn more and to find the necessary repositories for running the demo:

If you are familiar with the concept behind the Open Charging Network you can start the setup and configuration of your OCN Node. We recommend first running the node on the before moving to .

Visit the OCN Node README page in the GitHub repository for a step-by-step guide and all necessary resources:

2. Administration of Node and Connected Parties

After you have set up and configured your OCN Node, you can now set up administration and access restrictions, and allow others to access your node using the OCN Node APIs.

The for the OCN Node describes the available endpoints which can be used by administrators and parties.

Outside of the full OCPI v2.2 API, OCN Nodes provide additional features, such as the custom OCPI module, OcnRules, as well as ways for admins to restrict use and users to query the OCN Registry.

3. Keep your OCN Node up to date

Every OCN Node is a crucial part of the overall Open Charging Network. As soon as you run your own node, you are responsible for keeping it up to date. This helps to keep the Open Charging Network efficient and secure.

The Energy Web Foundation is steering the development of all Open Charging Network Open Source components, and will release regular updates.

The release date of an update will be announced on our at least two weeks before it will come into effect (be pushed from its DEVELOP BRANCH to the MASTER BRANCH). It is planned to keep the components downwards compatible at least one version, but this may not always be possible. Please make sure that you update your OCN Node within 24 hours after the publication of a new release.

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

provides decentralized oracle networks. covers:

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

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

• Design principles of Chainlink oracles

• Scenarios where it makes sense to use Chainlink

Ethereum

The Energy Web blockchain is derived from technology. Ethereum provides a strong foundation for the Energy Web Chain because it is open-source, widely used, and many well-developed tools for development on Ethereum exist today.

Ethereum-based technology is used as EW-DOS's trust layer because anyone can use Ethereum to build and deploy decentralized applications that run on blockchain technology. This aligns with the purpose of EW-DOS, which is to build decentralized, open-sourced applications that accelerate decarbonization of the energy grid.

What Sets Ethereum Apart from Other Blockchains?

Prior to Ethereum, most blockchains were protocols created to exist as a public, decentralized ledger for financial transactions (think Bitcoin).

Ethereum developed the (EVM) to allow users to store and execute programs on the Ethereum blockchain. This lets programmers write programs that contain logic and state management, both which are critical to. These programs are called . Once it is deployed on the blockchain, a smart contract has an address on the blockchain and anyone can use to interact with the contract or call its public functions. You can read more about how to interact with smart contracts .

This means that blockchain technology can not only be used to buy and trade cryptocurrency, but also to create robust applications for decentralized finance, asset trading, gaming and, in our case, a decentralized energy market.

Ethereum Fundamentals

The Energy Web Chain is derived from Ethereum, but it is a separate blockchain using a different consensus protocol and unique governance mechanisms. However, most of the fundamentals of the Ethereum network are the same for the Energy Web Chain. These fundamentals are helpful in understanding the role that blockchain technology plays in EW-DOS. This is especially true if you want to develop and deploy smart contracts on the Energy Web Chain.

If you are unfamiliar with Blockchain technology, or the Ethereum Virtual Network, there are some additional resources below to get you started.

• (this is an overview of transactions in Ethereum, but we explain more about transactions on the Energy Web Chain )

Additional Resources

• on

The Public Test Network is the pre-production test network of the Open Charging Network.

It should be used to test services and features in a robust quality assurance environment. To develop on the test network, you can connect to an OCN test node and the OCN Registry that is deployed on the Volta Test Network. See more details on this below:

• OCN Registry on Volta Test Network

• Connect your service to an OCN test node

• Run a node in a test environment

• Testing tools

OCN Registry on Volta Test Network

The Volta Test Network is the pre-production test network (testnet) of the Energy Web Chain. It is the blockchain equivalent of a test server or test environment in traditional software development.

The OCN Registry for the test network can be found on Volta under the following public key: 0xd57595D5FA1F94725C426739C449b15D92758D55.

You can view transactions and the log history for this contract on the Volta Block Explorer here. If you're unfamiliar with the Block Explorer, you can read more here.

Connect your Service to an OCN Test Node

The Public Test Network of the Open Charging Network provides you with some public test OCN Nodes that you can use for testing the features of the Open Charging Network.

The following test OCN test nodes are currently known to Energy Web Foundation:

• eMobilify GmbH with OCN Identity 0x4174161e7B8f137De780C024D0e988f4039F8C70 - You can obtain a registration token (Token_A) for this node here: https://qa-faucet.shareandcharge.com/ Temporarily unavailable - By using the Public Test node provided by eMobilify GmbH, you accept the Terms&Conditions and Data Protection Guidelines by eMobilify GmbH. Please visit the company website to learn more, or reach out to [email protected]

• Elaad NL with PublicURL ocn.elaad.io (Reach out to [email protected] to obtain the OCN Identity and the registration token)

Follow the steps outlined in the "Connect your Service to an OCN Node" in order to connect your service to one of the nodes listed above.

Run a Node in a Test Environment

The Public Test Network should give you the option to test your OCN Node operation in a QA environment.

The OCN-Registry for the Public Test Environment can be found on the Volta Test Blockchain by Energy Web under the following public key: 0xd57595D5FA1F94725C426739C449b15D92758D55

Follow the steps outlined in the Run and OCN Node for guidance on how to run a node.

Testing Tools

The Open Charging Network provides mock OCPI parties for exchanging simple OCPI requests over the Public Test Network.

One Mock CPO and one Mock eMSP are available on the Public Test Network (i.e. registered in the Registry contract that is deployed on the Volta Testnet)

Please note that the functionality of both mock parties is limited, and does not implement or cover all OCPI modules and use-cases. Details can be found on the Bitbucket repository: tutorial-servers.

Identity and Access Management (IAM)

Identity and access management (IAM) refers to the frameworks and procedures that provide the users of a technology with appropriate access to the technology’s resources (i.e. what a user is allowed to do and access within a system). It includes the processes for validating user identities and establishing the hierarchies they exist in.

IAM plays a critical role in Energy Web tech stack. The IAM components are responsible for creating user identities and defining and enforcing governance structures that identities participate in. These governance structures define criteria that users must have in order to take on roles within an application or organization, and provide the mechanisms to request, verify and issue these roles.

Energy Web's Approach to IAM (Self-Sovereign Identity)

The Energy Web IAM architecture is informed by and implements the principles of self-sovereign identity (SSI). SSI is a paradigm that promotes an individual’s control over their digital identity and how it is used. This is in contrast to traditional, centralized IAM approaches, where a third party is responsible for storing a user's identity and/or their data in a proprietary database.

Self-sovereign identity exists to address the shortcomings and vulnerabilities of centralized identity approaches. Some of these include:

1. Users lack custody over their digital identity and its associated data (what data is shared and with whom).

2. Applications and systems do not provide interoperability or portability of user data. User identifiers and data are typically sequestered within an application and are not accessible to the user outside of that context.

3. Centralized systems are vulnerable to attack, resulting in exposure and dissemination of sensitive user data.

The two fundamental components of SSI (Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) serve as the fundamental components of Energy Web's IAM framework.

• Similar to a traditional 'username', A DID is a user's primary identifier in the Energy Web ecosystem. A DID is derived from the user's public key, and is anchored on the Energy Web Chain in the DID Registry. See further documentation on DIDs in self-sovereign identity and the IAM stack here.

• Verifiable credentials are digital credentials that can be verified cryptographically using public-key infrastructure. In the Energy Web ecosystem, verifiable credentials are used to authorize a user's or asset's enrolment into an application or organization. See further documentation on verifiable credentials in self-sovereign identity and the IAM stack here

DIDs and Verifiable Credentials are used together within a framework of role-based hierarchies to create permissioning systems. You can read more about the role of DIDs and verifiable credentials in our governance framework here.

EW SSI Toolkit Architecture Diagram

Further Documentation

For further documentation on our IAM stacks:

• Guides (how to use IAM stack apps)

• Patterns (cross-cutting concepts across the IAM stack):

  • Credentials: the role and lifecycle of verifiable credentials in the IAM stack

  • Assets as Ownable Smart Contracts: defining and managing digital identities for assets (digital representation of a physical or virtual device)

  • SSI Credential Governance using ENS Domains: Energy Web's role-based governance frameworks

In a verifiable credential ecosystem, there are various metadata that are useful for effectively using the data in the credentials. This page aims to describe possible metadata specifications and technologies that may be used with credential data.

Note: Not all of the following metadata is available for all credentials within the Energy Web credentials ecosystem.

Data Semantics

Data semantics refers to the meaning of the data. This includes semantic disambugation (know precisely what a term is refering to) as well as data descriptions and relationships.

Linked Data provides semantic disbiguation by requiring that terms be IRIs.

Linked Data Contexts

Linked Data context maps terms to IRIs. This allows JSON-LD documents to be written in more concise, readable manner, without sacrificing accuracy.

The VC Implementation Guide also has instructions on how to create new contexts for verifiable credentials.

Linked Data Vocabulary/Ontologies

Linked Data can also be used to provide further information about the semantics of a term. This is provided in a data vocabulary or ontology.

For example, the RDF Schema comment property can be used to provide further description of a resource.

Note that vocabularies can be used to infer data validation but this is non-standard and violates the open-world assumption of W3C ontology languages.

This point is made in SHACL and OWL Compared

Although data validation is an important practical use case for the RDF stack, until SHACL came around, there was no W3C standard mechanism for defining data constraints. Over time, people became creative in working around this limitation. Many tools simply decided that for all practical purposes, the open-world and non-unique-name assumptions should simply be ignored. OWL-aware tools including TopBraid and Protégé, for example, provide data entry forms that restrict users from entering more than one value if there is a corresponding owl:maxCardinality 1 restriction, or require the selection of a specific instance of ex:Person if that class is the rdfs:range of the property. The GAIA-X FAQ makes a similar point SHACL shapes are not an ontological models. They serve a different purpose. Ontologies describe concepts and help in inferring additional knowledge. Firstly, the W3C ontology languages follow the Open World Assumption, secondly SHACL follows the Closed World Assumption. If a self-description is missing an attribute, it is an error in the shape validation (and that’s how it should be!). From the ontology’s point of view, the attribute could be defined somewhere else in the WWW, if not in the JSON-LD file at hand (but this extremely decentralised view is not compatible with Gaia-X’s trust-building approach).

Data Structure Validation

Data structure validation is used to validate that data, for example, contains specific properties or that properties have specific values.

There does not seem to be a single way of describing data structures in the Verifiable Credentials ecosystem as different methods have different tradeoffs.

For verifiable credentials, the schema of a credential can optionally be linked using the credentialSchema property.

JSON Schema

JSON Schema can be used to describe the precise shape required by the a credential.

The JsonSchemaValidator2018 credentialSchema type is defined in the Verifiable Credentials Vocabulary

Open API Schema

SHACL

SHACL is the W3C standard for validating RDF graphs.

SHACL is being used by GAIA-X for their self-descriptions.

To check whether the claims in a Self-Description follow all constraints, such as including all mandatory attributes, the claims are validated against a shape. Technically, these shapes follow the W3C Shapes Constraint Language (SHACL). The claims themselves are represented as an RDF graph, serialised in the W3C JSON-LD format, where JSON is a data interchange format widely supported by programming languages, and JSON-LD (LD = “linked data”) makes it compatible with RDF.

JSON-LD Schema

JSON-LD Schema is a pre-alpha project that attempts to reconcile the trade-offs of JSON Schema and SHACL.

It notes:

JSON-LD documents can be seen from two points of view: as regular JSON documents following certain conventions or as RDF graphs encoded using JSON syntax. Validation mechanisms indeed exist for both ways of looking at the information in a JSON-LD document, but each of them has important drawbacks when working with JSON-LD:

• JSON-Schema can be used to validate JSON-LD as plain JSON documents. However, the information in a JSON-LD document can be encoded through multiple, syntactically different, documents, so it is hard to write a generic JSON-Schema validation without going through a normalisation step, and even if the validation is written for a normalised JSON-LD document, the description of the validation becomes verbose and complex to write, relying, for example, on the usage fo fully expanded URIs. There is also the issue of the implications for the validity of the RDF information encoded in the document when we are just validating the JSON syntax.

• SHACL can be used to validate the RDF graph encoded in the JSON-LD document. SHACL is powerful and expressive but difficult to write and learn, especially for users that do not want to work with JSON-LD as an RDF format. Additionally, the performance of SHACL validators is far from the performance of syntactical JSON-Schema validators

Data Display

The Wallet Rendering specification describes how a credential can be displayed.

In EW Data Exchange, the DDHub Message Broker is analogous to a computer - it is foundational infrastructure upon which participants gain the ability to establish their own “profiles”, exchange messages, and run their own applications. The DDHub Message Broker routes and translates messages between participants. Messages are structured and organised in distinct channels corresponding to specific use cases or business processes, and formatted in topics which define data formats and schemas.

In order to access certain channels and gain permissions to send and/or receive specific message types, participants must acquire roles that reflect their role within the market (or use case), using credentials attached to their self-determined identity. Credentials are granted by a platform governing body and determine the ability to send messages to other participants using channels (what messages are sent and received) and topics (data schemas that define the payload of a message).

Channels

Channels are defined at the client gateway, and are what messages are sent and received on. Participants define a channel as:

• Type: Publish/Subscribe

• Topics: Any that the DID has visibility of

• Restrictions: Who will receive a message on a publish channel, or who I will receive a message from on a sub channel. Channels can be restricted by DID or role

An example of a channel definition object is provided below. In this example, the channel will receive RealTimePricing or DayAheadPricing from any DID with the role: user.roles.internal.apps.operator.iam.ewc and does not specify that payload encryption is required.

// Market Pricing Channel Example
 {
        "fqcn": "pricingtopics.sub",
        "type": "sub",
        "conditions": {
            "topics": [
                {
                    "topicName": "RealTimePricing",
                    "owner": "internal.apps.operator.iam.ewc",
                    "topicId": "62f9b4123bef104db2264f2b",
                    "schemaType": "JSD7"
                },
                {
                    "topicName": "DayAheadPricing",
                    "owner": "internal.apps.operator.iam.ewc",
                    "topicId": "62f9b4644bfe104db22642c0",
                    "schemaType": "JSD7"
                }
            ],
            "dids": [],
            "roles": [
                "user.roles.internal.apps.operator.iam.ewc"
            ],
            "qualifiedDids": [
                "did:ethr:volta:0x135ebb63ab839bef3e292e55dcF4A98Bfe38Ba47A9",
                "did:ethr:volta:0x87795f53b443ece663986f46e6747fb10dbc6745fC"
            ]
        },
        "payloadEncryption": false,
        "createdDate": "2022-08-16T00:03:46.164Z",
        "updatedDate": "2022-09-04T22:33:43.313Z"
    }

Topics

Topics are data schemas that define the payload of a message within a channel. They are grouped under owners that are used as an authorization unit for visibility. Two examples of Topics for publishing and acknowledging a distribution network line constraint are provided below:

// Constraint Publication Example
{
    "participantId": "string",
    "submissionTimestamp": "string",
    "networkConstraints": [
        {
            "meterID": "string:",
            "intervals": [
                {
                    "activePowerExportLimit": 0.0,
                    "activePowerImportLimit": 0.0,
                    "diEndtime": "string",
                    "diStarttime": "string"
                }
            ]
        }
    ]
}

// Constraint Acknowledgement Example
{
    "data": {
        "initiatingMessageId": "string",
        "initiatingTransactionId": "string",
        "systemProcessedDttm": "datetime"
    },
    "acknowledgements": [
        {
            "code": "string",
            "title": "string",
            "detail": "string",
            "source": "string"
        }
    ],
    "errors": [
        {
            "code": "string",
            "title": "string",
            "detail": "string",
            "source": "string"
        }
    ],
    "warnings": [
        {
            "code": "string",
            "title": "string",
            "detail": "string",
            "source": "string"
        }
    ]
}

\

The Production Network is the live network of the Open Charging Network. Services and features should only be used in a production network after performing robust quality assurance environment.

OCN Registry on Energy Web Main Network

The Energy Web Main Network (mainnet) is the production network of the Energy Web Chain.

The OCN Registry for the main network can be found under the following public key: 0x184aeD70F2aaB0Cd1FC62261C1170560cBfd0776

You can view transactions and the log history for this contract on the Block Explorer here. If you're unfamiliar with the Block Explorer, you can read more here.

Connect your Service to an OCN Production Node

Follow the steps outlined in the "Connect your Service to an OCN Node" in order to connect your service to one of the nodes listed below.

The following test OCN production network nodes are currently known to Energy Web Foundation:

• eMobilify GmbH with OCN-Identity 0x34F160573b96D3Db5928Ae804D7d99DdD0aF222c Reach out to eMobilify GmbH via [email protected] to get connected.

• eMobility Easy with OCN-Identity 0x79d2D88A1F668296c96150139366ff507eFeD618 Reach out to eMobility East via [email protected] to get connected.

Follow the steps outlined in the "Connect your Service to an OCN Node" in order to connect your service to one of the nodes listed above.

Run a Node in a Production Environment

For the running of a production node, we advise that a few extra steps are taken. These include configuring HTTPS, enabling message signing, and running against a relational database.

You can see all OCN node configuration settings here.

1. Configure HTTPS

Running the OCN Node in production mode (by default or with the configuration setting ocn.node.dev=false) will require HTTPS. On startup in this mode, the OCN Node will look to see if HTTPS is enabled and properly working. If not, the node will shutdown.

We recommend using an Nginx reverse proxy and Let’s Encrypt certificate, but other solutions are not discouraged.

2. Enable Message Signing

This feature allows recipients to verify the integrity of the data they are receiving. When the configuration setting ocn.node.signatures=true, request senders should include an OCN-Signature header that all entities that the request passes through (i.e. OCN Nodes and the recipient) sign to verify that the data has not been modified without consent. Likewise, for responses, an ”ocn_signature” property should be placed in the JSON response body by the recipient.

Read more about OCN signatures here.

In some cases an OCN Node will need to modify data (typically to make URLs work for recipients). The signature can be modified by an OCN Node, but they must state the properties that they changed, and sign any new data. More information about message signing and verification can be found here.

By default message signing is turned on, but it can also be set with ocn.node.signatures=true if it is not.

3. Configure a Database

The default dev properties configuration file only connects to an in-memory database, for ease of quickly testing the OCN Node. When running a Node on the test or production environment, a database should be set up to persist data across restarts. The example application.prod.properties file provided with the OCN Node provides the configuration necessary to use PostgreSQL.

4. Configure Load Balancing

If necessary, the OCN Node can be load balanced. To do so, the nodes operating under the load balancer should have the same configuration:

ocn.node.url = https://balancer.server.net
ocn.node.privatekey = 0x...45d1
ocn.node.apikey = supersecretkey

The operator should also list the load balancer as the domain name using the same private key in the registry listing:

ocn-registry set-node https://balancer.server.net --signer 0x...45d1

Legal Setup of eRoaming via the OCN

The OCN allows you to have simple, cost-efficient and secure technical connections to other EV charging players like Charge Point Operators and eMobility Service Providers. To run your EV charging service in production, you may need to enter into different legal relationships.

You might want to consider establishing the following agreements when setting up your charging service:

Service Level Agreement (SLA) with Your OCN Node Operator

The OCN Node is responsible for your technical connection to other parties on the OCN. If you are not running your own OCN Node, but using the OCN Node of a third party (OCN Node Operator), you might want to sign a Service Level Agreement (SLA) with the OCN Node Operator. The agreement should make sure the OCN Node is hosted properly and has a high uptime.

eRoaming Agreement with Other Players on the OCN

Engaging with other parties on the Open Charging Network (like charge points or electric vehicles) requires in many cases a formal legal relationship between you and your counter party. An eRoaming Agreement stipulates the terms and conditions for the eRoaming connections between you and your counter party.

The development of the Open Charging Network is steered by community needs with the non-profit Energy Web Foundation curating the development.

For this purpose, transparency about the current feature set is required, which the following OCN maturity model (inspired by Gitlab) shall provide. The maturity model and the roadmap of the Open Charging Network development is discussed quarterly during the Share&Charge Foundation and Tech Call.

The maturity model is based on different categories (columns):

• Messaging: How messages between OCN Parties are transmitted and secured

• Service interfaces: Interfaces that can be used by OCN Parties to connect their services to the OCN

• Connection & Community: Tools for the community to test and use the OCN

Maturity is indicated with different-sized black boxes or a heart:

Planned: Requirements are getting defined

Minimal: First implementations are tested

Viable: Can be used in production

Lovable: Functionality set is complete and used by community

A reference to the open source repositories is provided in parenthesis after the feature description.

What is the Energy Web Token?

The Energy Web Token (EWT) is the native utility token of the Energy Web Decentralized Operating System (EW-DOS). Tokens are used in EW-DOS to pay for gas fees on the Energy Web Chain, and for staking to secure the Energy Web X blockchain as well as Worker Node Networks. You will need EWT in your digital wallet (we recommend using MetaMask) if you want to make transactions or use applications or smart contracts that are deployed on the Energy Web Chain main network.

EWT on the Energy Web Chain

Like other public blockchains, the Energy Web Chain uses EWT as a utility token to access services and orchestrate stakeholders within its blockchain system. In the context of the Energy Web Chain, EWT compensate validators for processing transactions, and are used to pay for transactions - for example, registering a new asset or organization in Switchboard.

Utility tokens like EWT are different from other digital assets in the blockchain sphere such as coins, non-fungible tokens, and stablecoins. To learn more about the distinctions between these assets, see this article, The ultimate cryptocurrency explainer: Bitcoin, utility tokens, and stablecoins .

EWT on Energy Web X

Energy Web X will leverage and complement the existing Energy Web Chain by introducing new technical capabilities that streamline the deployment and operation of Worker Node networks.

To maximize the security of every Energy Web solution using worker nodes, EWT will be required to interact with worker nodes and Energy Web X. Most notably, Energy Web Tokens will be required to:

• Reward worker node networks: worker nodes are software packages that need to be run by individuals and/or businesses. In order to attract entities to run worker nodes, enterprises will need to include rewards, paid in EWT, that compensate worker node operators for their work.

• Operate worker nodes: in order to become a trusted party to run worker nodes, individuals and/or businesses will be required to stake EWT. Staking requirements and reward schedules are mass customizable—enterprises launching worker node networks can configure different thresholds and award schedules at their discretion.

• Validate Energy Web X: Energy Web X validators will need to stake a significant number of Energy Web Tokens in order to become validators on Energy Web X.

For clarity, instead of launching a new token with the Energy Web X blockchain, Energy Web X will be powered by the existing or EWT. Users have the ability to “lift” Energy Web Tokens from the existing Energy Web Chain onto Energy Web X. Lifted Energy Web Tokens can then be used for the functions described above. With this mechanism in place, EWT holders will be able to “lower” Energy Web Tokens back to the main Energy Web Chain at their discretion. Over time, token holders will be able to lower EWT to other layer one blockchains (for example, main net Ethereum) making Energy Web solutions interoperable with any blockchain ecosystem.

Get EWT

You can buy EWT on any of the exchanges listed here. You can also bridge EWTB ERC20 tokens acquired on Ethereum mainnet back to EW Chain by following this guide.

Related Content

• Transactions and Transaction Costs

• Energy Web Token

• Volta Testnet Token

• Token Bridge

• Cryptocurrency Wallets

Additional Resources:

• What is Energy Web Token? | EWT Coin | Kraken

• ****The utility of the utility token for utilities - how companies can use the Energy Web Token to build and operate enterprise-grade decentralized applications on a public digital infrastructure

• Energy Web Token - Energy Web

Overview

The Block Reward contract manages block reward payouts to validators. Block rewards are issued as native Energy Web tokens that are minted by the engine.

Two entities are rewarded by each created block:

1. The block author (validator)

2. The community fund

Documentation and Source Code

• Energy Web Block Reward Contract

• OpenEthereum documentation on Block Reward Contract

Block Reward Payouts

Block Authors

Block authors are rewarded each time they seal a block. The amount issued to block authors decreases over time, as depicted by the Discreet S Curve.

Calculator: https://github.com/energywebfoundation/discrete-scurve-calculator

Energy Web Community Fund

A portion of block rewards goes to the Community Fund. Unlike the amount awarded to block authors, the amount that goes to the Community Fund remains constant over time.

The amount is chosen to add up to roughly 37.9 million tokens over a 10 year period. The community fund can change its own address and set a payout address too.

With 5 second step size: Payout-per-block = 600900558100000000 wei

Visual representation of the community reward distribution is depicted below in Fig. 3.

Interaction with Block Reward Contract

Contract Address and ABI

Callable functions

Energy Web supports two distinct blockchain networks:

1. The Volta Test Network (Testnet)

2. The Energy Web Production Network (Mainnet)

These networks are independent of each other. They each have their own chain specifications that the OpenEthereum client uses to configure the blockchain. You can view them on github here.

You cannot transfer tokens between these two blockchains. They each use their own unique utility token that pays for transaction fees on the blockchain (read more about this here).

The Energy Web Chain's main network utility token is the Energy Web Token, which has real fiat value. The Volta Test Network's token is the Volta Token, and it has no real value. They are not interchangeable - if you have Volta tokens, this does not mean you have Energy Web Tokens, and vice versa.

Developing on Volta Test Network

Volta is the pre-production test network (testnet) of the Energy Web Chain. It’s the blockchain equivalent of a test server or test environment in traditional software development. Most blockchains have at least one test network. Ethereum, for example, has several test networks for pre-deployment testing.

Volta is used as a staging network to:

• Test smart contracts before they are deployed on the production chain. If you write your own smart contract, you will want to deploy it and test it on Volta first to make sure it works as expected. Because tokens on the testnet (Volta tokens) have no real value, you can test thoroughly and incur no cost.

• Test protocol updates before they are deployed on the production chain. Each time there is an upgrade to Ethereum's protocol, we test it on the Volta Network first.

The utility token for the Volta Test Network is the Volta token. Volta tokens have no real value, but you will need them to "pay" for transaction costs associated with interacting with smart contracts on the Volta network. Read more about the Volta Token and how to get some here.

Get Started Using Volta

• Get Volta Tokens

• Connect to Volta Test Network using MetaMask - you will need to connect to the Volta network in order to access applications and smart contracts deployed on Volta

• Run a local node - you have the option to run your own local node of the Volta network. You can read about the purpose and benefits of running a local node here.

Developing on Energy Web Main Network

The Energy Web main network (mainnet) is the production network of the Energy Web Chain. The gas fees to pay for transactions require Energy Web Tokens (EWT), which have real value. You can read more about EWT and how to acquire it here.

Get Started Using the Energy Web Chain

• Get EWT

• Connect to Energy Web Main Network using MetaMask - you will need to connect to the Energy Web Chain in order to access applications and smart contracts deployed on the Energy Web main network

• Run a local node - you have the option to run your own local node of the Energy Web Chain. You can read about the purpose and benefits of running a local node here.

Related Content

Overview

The Holding Contract holds tokens for initial investors. These tokens are "pre-mined", and do not enter the pool through block validation. Tokens are held for affiliates until a specific point of time that is specified in the contract, at which point they can be released to the specified address. The constructor of the holding contract and its initial balance is part of the chainspec file. This allows the investors' tokens to be locked at the first block.

The mapping between the account address and the token amount is hard coded into the contract and cannot be changed after deployment. After a block that has a later timestamp than the holding timestamp of an address is created, the tokens for that address can be transferred to the address by calling the realeaseFunds method. This method can be called by anyone, not only by the address that holds that balance.

Documentation and Source Code

• Energy Web Holding Contract

Check a Balance and Withdraw Funds

If you're an investor and want to see your balance, you can use the Balance Viewer interface: http://balance.energyweb.org/.

You will need MetaMask pointed to a local or a remote node

• To learn how to connect via remote RPC, go here

• To learn how to run a local node go here

1. Enter your address in the lookup field to see your holding balance

2. If the release period has ended, press the "Withdraw" button to release the funds to the address it belongs to. Make sure you trigger the withdraw function with an account that has some ethers to cover transaction costs

Mapping Between Address and Tokens

The mapping between addresses and tokens/release timestamp is kept in the storage of this contract. This mapping data structure was filled at the deploy time of the contract and cannot be changed.

mapping (address => Holder) public holders;

// -- snip --

struct Holder {
    uint256 availableAmount;
    uint256 lockedUntilBlocktimestamp;
}

// -- snip --

// in the constructor
addHolding(0x120470000000000000000000000000000000000a, 10000000000000000000000000, 1564509540);

Interacting with the Holding Contract

Contract Address and ABI

Callable Functions

In order for your backend service to be OCN-ready, it must:

1. , the shared communication protocol for the OCN

2. in order to sign and verify OCN messages

1. Implement the

The OCPI protocol is the common communication protocol for the OCN. Each OCN node implements the OCPI 2.2 API (see, for example, the Kotlin implementation of the OCPI 2.2 API for the OCN node ), and every backend-service that communicates with an OCN node must also implement the OCPI 2.2 API.

Using the OCN Bridge

Using the is an alternative to implementing the full OCPI 2.2 API in your backend service. The OCN Bridge provides an OCPI interface using pluggable backend APIs. You can instantiate an instance of the Bridge, which will proxy your requests and responses with other OCN parties.

In addition to the OCPI 2.2 implementation, the OCN Bridge also provides services to interact with an OCN node (i.e. register with a node, get connection status to a node) and the OCN Registry.

Examples:

You can view documentation on how to to implement the OCN Bridge .

The OCN Bridge simplifies the implementation of the OCPI interface, but it is not required to use in your backend service. Note that the OCN Bridge can only be implemented in JavaScript environments.

2. Implement the

The OCN Notary is a package that enables the verification of OCN signature, which are used to sign and verify OCN requests using public/private key-pairs.

OCN Signatures

Taking a cue from the blockchain community, we have developed a message signing and verifying system for the Open Charging Network.

Under the hood it uses the Elliptic Curve Digital Signature Algorithm (ECDSA) as implemented by Ethereum. The signature itself holds a JSON Object containing all the necessary data for the recipient to verify the data it is receiving.

Not only do requests need to be signed, but responses too.

Signing Requests

For requests, the signature is appended to the outgoing OCPI 2.2 headers:

Authorization: Token 0ea32164-515f-418b-8bef-39f3817ea090

X-Request-ID: 71d62c5b-5017-493e-be00-3f5ad4e34fff

X-Correlation-ID: 9881b6f7-63aa-40d2-b9c2-d6daa69c11fb

OCPI-From-Country-Code: CH OCPI-From-Party-Id:

MSP OCPI-To-Country-Code: CH OCPI-To-Party-Id:

CPO OCN-Signature: eyJmaWVsZHMiOlsiJFsnaGVhZGVycyddWyd4L (truncated)...

Signing Responses

For responses, the signature is appended to the outgoing OCPI 2.2 JSON response body:

{

"status_code": 1000,

"data": { "result": "ACCEPTED" },

"timestamp": "2020-03-02T12:48:33.005Z",

"ocn_signature": "eyJmaWVsZHMiOlsiJFsnaGVhZGVycyddWyd4L (truncated)..."

}

The idea is that the recipient can use this signature to verify that the message has been signed correctly and has not been modified by an unauthorized party.

What do we mean by unauthorized?

For the OCN to function properly, there are cases where an intermediary (i.e. an OCN node) needs to modify the request/response. Such an example would be the response_url in the JSON body of requests made to the receiver interface of the OCPI commands module. As the recipient does not have access to the response_url defined by the sender, the OCN Node must modify the value. In an OCN signature, this is known as “stashing”. The signature object contains the history of rewrites, with the previous signature being stashed by the party modifying the data. When a recipient then verifies a signature, the rewrites are also verified.

Let’s take a closer look at what the signature actually is:

interface Signature {

val fields: Array val hash: String

val rsv: String

val signatory: String

val rewrites: Array

}

interface Rewrite {

val rewrittenFields: Map<String, Any?>

val hash: String

val rsv: String

val signatory: String

}

The signature itself contains everything needed to verify the most-recent version of the sent data, i.e. by the sender or OCN node depending on whether any values needed to be modified. Provided is a list of jsonpath fields which can be used to recreate the message as signed by the sender, with the original order of values preserved. The values are hashed using keccak-256, as implemented by Ethereum. The resultant hash is actually the message which is signed. The RSV is the signature, produced by ECDSA using an Ethereum wallet’s private key. The signatory refers to the address of the wallet that was used to sign the message.

The list of rewrites contains an object containing the previous hash, rsv and signatory. It also allows the original message to be recreated by storing the fields which have been rewritten. For example, a commands receiver request might have the following rewrite by the OCN node:

1Rewrite( 2 rewrittenFields = mapOf("$['body']['response_url']" to "https://emsp.net/ocpi/2.2/sender/commands/START_SESSION/acfbb8d2-bd49-4837-97e2-d2c38f6bae55"), 3 hash = "0x1ce93f156bc5b3a5c26c5f2499db7bfa2b38c37fd32616fc6487175b86f41eb2", 4 rsv = "0x16e8b9c4e44f4646235fca85a594b5a31057930676d338d111ae985a4f0d9d4214705a0a2ae18c4dfd014581e96eb4625137a937853d4b2d17a0f3a22750f6ac1c", 5 signatory = "0x25e4fca0a0e5107d06d71ed78f687827208d5ff9" 6)

The Signatory

Of course, the signatory of both the OCN Signature and its rewrites should be independently validated. The verification of the signature only tells us that the message was signed by the signatory provided. The signatory itself could be any Ethereum wallet address. The address of both the original sender and their OCN node can be found in the OCN Registry[link to repo].

Now that we know how the signature functions, how do we actually use it? Enter the .

Implementing the OCN Notary

The OCN Notary implements the above Signature and Rewrite interfaces. It can deserialize an incoming OCN Signature and verify its contents. It can be used to sign an OCPI request, and likewise to stash/rewrite values in a request.

Currently the Notary library is available as an and as a Maven package for languages targeting the JVM. See the to find more information for each package.

OCN Network v1.0 Open API 3.0 Specs

You can find the API specification document in the OCN Node repository, here:

Using this specification, it is possible to generate client code and test implementations. For more information, see .

Note that this document was generated using unmodified source code in the master branch. As such, certain features of the specification format might be missing, such as examples for HTTP requests and responses.

The Open Charging Network is a community project by and for the Electric Vehicle Charging community. Its mission is to provide the EV Charging industry players an open, secure and decentralized network for digital interoperability. This is why the core components are developed open source under the .

The development of the Open Charging Network is driven and steered by the non-profit Energy We Foundation. Many users and community members are contributing to it in the form of feedback, raised issues, pull requests and dedicated working groups. This article should provide you with some guidance on how you can contribute to this project.

Version Management

The production-ready version of every Open Charging Network component can be found in its MASTER BRANCH

Development of each component can be found in its DEVELOP BRANCH. Pull requests should therefore generally derive from the develop branch, which will be eventually merged into the master branch to coincide with the release of a new version.

Bare in mind that new features that are big enough may warrant their own feature branch so that multiple contributors can work on them before being merged into the development branch.

Maturity Model, Feature Roadmap and Releases

• The current state of development is made transparent with a maturity model, which describes the current and planned feature set:

• Monthly Developer Community Calls are being hosted to align the development of all software components. Anyone is invited to join. Learn more about it

Community support

If you need support in using or contributing to the Open Charging Network, use our .

Reporting bugs and contribute with coding

Issues are raised, described and prioritized in our .

You can contribute fixes to bugs or new features by sending via the GitHub repository. Using the GitHub UI, a pull request can be initiated from a branch in a fork of repository.

Before we can include your contributions to the Open Charging Network code, you need to give us permission. As the author of any creative work (including source code, or documentation), you control the copyright for that work. Energy Web Foundation Foundation can’t legally use your contribution unless you allow us to.

To manage this process, we use a mechanism called a popularized by The Linux Foundation. The DCO is a legally binding statement that asserts that you are the creator of your contribution, and that you license the work under the .

Please take the following steps so that we can include your work:

1. Each source file must include the following header:

2. Each commit must include your sign-off

Your sign-off certifies that you are either the author of the contribution or have the right to submit it under the Apache 2.0 license used by the Share&Charge project. The sign-off is done by adding the following line to your source code:

You must use your real name. Pseudonyms or anonymous contributions are not allowed.

If you set your user.name and user.email as part of your Git configuration, you can sign your commit automatically with git commit -s.

More tips on how to sign-off your work with Git can be found on this website:

The full text of the DCO is:

Sign-in with Ethereum (SIWE) is an open standard for decentralized authentication that allows users to sign in to websites and applications using their Ethereum accounts. Unlike traditional centralized authentication methods, this innovative approach allows users to access various online services and applications using their Ethereum wallet address and cryptographic keys. This groundbreaking login solution represents a significant step forward in the evolution of decentralized identity management, empowering users with enhanced privacy and ownership of their digital identities.

Why SIWE?

The Ethereum Foundation and Ethereum Name Service (ENS) had put forward a for Sign-in with Ethereum in 2021, based on EIP-4361 (). The reference implementation of Sign-In with Ethereum by SpruceID ( ) provides an easy integration with Application’s Identity services and assures smooth Sign-In user experience. It has numerous benefits over other PKI based signatures, such as :

1. A standard human readable verifiable message to confirm signatures.

2. An EIP-standard message schema to incorporate all the information needed for a secure authentication.

3. Verification for domain and uri, this assures the authenticity of the requester / verifier. Users can validate the domain the transaction was initiated from and the URI to which the access would be provided to (redirection) upon signing for authentication / authorization.

4. Preventing replay attacks with a nonce, which could be a challenge from a server or a random token .

SIWE message template

Message Field Descriptions

authority is the RFC 3986 authority that is requesting the signing. address is the Ethereum address performing the signing conformant to capitalization encoded checksum specified in EIP-55 where applicable. statement (optional) is a human-readable ASCII assertion that the user will sign, and it must not contain '\n' (the byte 0x0a). uri is an RFC 3986 URI referring to the resource that is the subject of the signing (as in the subject of a claim). version is the current version of the message, which MUST be 1 for this specification. chain-id is the EIP-155 Chain ID to which the session is bound, and the network where Contract Accounts must be resolved. nonce is a randomized token used to prevent replay attacks, at least 8 alphanumeric characters. issued-at is the ISO 8601 datetime string of the current time. expiration-time (optional) is the ISO 8601 datetime string that, if present, indicates when the signed authentication message is no longer valid. not-before (optional) is the ISO 8601 datetime string that, if present, indicates when the signed authentication message will become valid. request-id (optional) is an system-specific identifier that may be used to uniquely refer to the sign-in request. resources (optional) is a list of information or references to information the user wishes to have resolved as part of authentication by the relying party. They are expressed as RFC 3986 URIs separated by "\n- ".

Sample SIWE Message :

Given all these advantages, Sign in with Ethereum proved to be an ideal choice for Energy Web in implementing authentication for our decentralized applications (DApps). Authentication with SIWE is supported by our Passport strategy (available in passport-did-auth from v2.0.0 ).

How it works?

A signature request with Metamask SIWE will look something like :

Note: The text block in the above MetaMask pop-up for signing is the SIWE message.

Major security considerations for SIWE

Preventing replay attacks

• During each session initiation, it is crucial to select a nonce with sufficient entropy to thwart replay attacks – a type of man-in-the-middle attack where an adversary intercepts the user's signature and uses it to initiate a new session on their behalf.

• To ensure security, implementers have the option to utilize privacy-preserving but readily accessible nonce values. For instance, they may consider using a nonce derived from a recent Ethereum block hash or a recent Unix timestamp. These methods offer a balance between safeguarding privacy and ensuring widespread applicability.

Verification of domain binding

• Wallets are required to verify that the domain aligns with the actual source of the signing request.

• It is recommended to cross-check this value with a trusted data source, such as the browser window, or through another reliable protocol. By doing so, wallets can enhance security and mitigate potential risks associated with fraudulent or unauthorized signing requests.

SIWE with Federated Identity service

Many organizations aim to deploy a unified Identity Service that can be utilized across all federated services, employing OpenID Connect for efficient user session management. Thanks to SIWE-OIDC (), this objective has now become achievable.

Current scope for SIWE-OIDC

SpruceID has deployed an OpenID Connect Provider (OP) which has support for SIWE and hosted under SIWE Open ID Connect . This deployment is a DAO-governed OP supported by ENS DAO.

To use the hosted OIDC server it is required to register the application as an OIDC client using the OIDC client registration of SIWE Open ID Connect . Currently, no user interface for OIDC client registration is supported. For that reason, developers will need to use the REST API.

The following is an example response:

A client can then be updated or deleted using the registration_client_uri with the registration_access_token as a Bearer token. The authentication could be similar to

Note : This flow is just a possible flow, it could be different for a different use case.

Apart from the existing functionalities offered by SIWE, there is potential for future extensions, including support for Decentralized Identifiers and Verifiable Credentials, as well as integration with EIP-712 for Type structured data hashing and signing.

Below are steps to deploy a on the (the test network for the ) using . Remix is a web application used to compile, deploy and test smart contracts on Ethereum networks.

In order to deploy a smart contract to the Energy Web Chain Main Network, rather than the Volta Test Network, the steps are identical, except that you will connect your MetaMask to the Energy Web Chain rather than to Volta. We recommend that you always deploy and test your smart contracts to Volta first to make sure they behave as expected.

Once your smart contract is deployed, you can use the contract's ABI and address on the blockchain to interact with its public methods. For more information on how to interact with smart contracts, go .

1. Configure MetaMask to connect to the Volta Test Network

You can see steps for doing this are . If you do not have a MetaMask installed, you can do so .

2. Get Volta Tokens

You will need to to pay for the transaction fee for deploying the smart contract to the blockchain. For directions on how to get Volta Tokens, go . To learn more about what transaction fees are, you can go .

*Note that if you are deploying to the Energy Web Main Network, you will need to have .

3. Navigate to

4. Navigate to the "Deploy and Run Transactions" icon on the left panel (shown below).

In the "Environment" dropdown, selected "Injected Web3". Notice that when you select this, "Custom (73799) network shows up. 73799 is the Volta Test Network - this confirms that we are connected to the Volta network via MetaMask.

5. Confirm the connection on MetaMask

You will need to confirm the connection to MetaMask.

6. Create a simple smart contract

Go to the file explorer panel (select the first icon on the left panel). Add a new .sol file in the 'Contracts' folder. Below it is called VoltaContract.sol.

In the .sol file, add the following code:

7. Compile the smart contract

If there are no errors, click "Compile VoltaContract.sol" (make sure that the 'Language' selected is 'Solidity').

8. Copy the deployed contract's (Application Binary Interface)

If you want to interact with your contract in the future using an API client, you will need the contract's ABI. The ABI is in the bottom right hand corner of the Solidity Compiler page after it is compiled.

9. Deploy the smart contract

Click 'Deploy' to deploy the contract to Volta Test Network.

Confirm the transaction in MetaMask. Make sure that you have some gwei as a gas price by doing the following:

Select EDIT

Select "Edit suggested gas fee"

Make sure you have a Gas price of 6e-8 GWEI (this should be autofilled)

Confirm the transaction in MetaMask

10. See and test the deployed transaction

Once your contract is deployed, you can see it in the "Deployed Contracts" section of the same page ("Deploy and Run Transactions")

Click on "get" to test our contract's functionality. Remember from the code that is should just return a string "Volta".

11. See deployed contract on the Volta Block Explorer

Copy the address of the contract by clicking the copy icon.

Go to the . If you are deploying to the main network, the block explorer is .

Paste the contract address in the search bar at the top right:

You can see the smart contract address details, the block it was created in, and the byte code. The block explorer contract details from the example above is .

12. Use your smart contract in dapps

Now that you have your smart contract's address on the blockchain and its ABI, you can use an Ethereum API client to interact with your contract in your decentralized applications. For a tutorial on how to do this, go .

Governance

Governance provides the rules and procedures to establish behavior, expectations and trust within an environment. While governance is a critical component of any multi-party network, it is especially critical in decentralized environments, where there is no central authority to define and orchestrate governance mechanisms over every component of the ecosystem.

As an example, consider an application built on top of the . Each application must ensure that:

• Components are in compliance with existing digital frameworks that their application depends on (e.g. , peer-to-peer protocols or )

• The application has a governance framework that is robust enough to garner stakeholder trust and compliant participation within the application itself (i.e. defining and enforcing who is allowed to do what within the application)

Governance Frameworks

Governance in a network is established through a governance framework (also referred to as a trust framework). The framework provides concrete policies, rules and expectations for the stakeholders within the network.

Energy Web IAM Governance Framework

Energy Web’s IAM governance relies on two systems: and . Used together, these components provide a governance framework for users to interact with the digital infrastructure, and with other users in a secure and self-sovereign manner.

Role credentials are associated with a user’s , which is anchored on the Energy Web Chain in the . This means that a user’s roles and credentials are not siloed within any one application; because a user can use their DID to register with any application built on top of the Energy Web Chain, their roles and credentials are portable.

Role-based Hierarchies

In the Energy Web IAM ecoystem, role-based hierarchies are defined by organizations, applications, and designated roles within them. The tech stack leverages to define and namespace relational hierarchies within a system. We decided to deploy our own copy of ENS on the Energy Web Chain as it provides a standard set of widely-used, well-tested smart contracts. Read more about the ENS smart contracts deployed on the Energy Web Chain .

The namespace hierarchy is built on four levels:

1. Organization: a top-level organizing body

2. Sub-organization(s)

3. Application: a distinct service or functionality provided by an organization or sub-organization

4. Role: a distinct functionality within an application or within an organization

Role-definition properties

When roles are created within an organization or an application, the creator can define conditions or criteria that restrict who is qualified to take on the role. The role creator can also determine which users (by DID or role) are authorized to issue or revoke a role.

Below is a resolved role definition for a role of "install lead". Note that it contains an enrollment precondition that the subject already has the role (credential) of 'project installer'. The role definition also specifies an expiration date, and asserts that only users that have the role of 'install manager' can issue or revoke this role.

Verifiable Credentials

Verifiable Credentials enable users and their assets to take on (that is, within an organization, a sub-organization or an application within a hierarchy, as discussed ).

See more extensive documentation on credentials in the IAM stack .

IAM Stack Governance Components

provides the user interface for creating and defining these hierarchies. See the Switchboard guide on Governance and role creation .

The supporting provide the functionality for persisting and resolving namespaced domains Namespace domains that are registered and managed in the . Read more about the role of Ethereum Name Space in Energy Web Digital Infrastructure .

These libraries also support governance by providing credential verification mechanisms. This is discussed further in the .

Additional Resources

The block explorer interface provides the most important on-chain information about blocks, transactions, accounts and . Below is an overview of what information you can view on the Block Explorer.

Note that there is a separate site for the Volta Testnet Block Explorer.

• Volta Testnet Block Explorer:

• Main Network Block Explorer:

Block Explorer Overview

Blocks

• - block details for all sealed blocks

  • Block Height

  • Num transactions

  • Hash

  • Parent Hash

  • Difficulty

  • Total Difficulty

  • Gas Used

  • Gas Limit

  • Block Rewards

  • Miner (validator)

  • Transactions

Transactions

• - transaction details for all validated transactions

  • Transaction address

  • Status

  • Block Number

  • Nonce

  • Transaction fee

  • Transaction Speed

  • Raw input

  • Gas

  • Internal Transactions

• - transaction details for all pending transactions

  • Transaction address

  • Nonce

  • Gas limit

  • Internal Transactions

Account details for all external and smart contract account addresses with balances and associated transactions

• Address

• Token balance

• Num. transactions

• Last balance update

• Gas used

• All transactions

• Coin balance history

Tokens

APIs

• GraphQL: GraphQL interface which you can use to query specific information that are on chain: . To find out more about the possible queries visit:

Blockchain Consensus

In a centralized system, such as a bank or a broker, a designated authority or central operating system would be in charge of adding transactions or information to the system, making sure that each transaction is trustworthy, up to date with the whole system, and does not duplicate previous transactions.

In contrast, public blockchains are decentralized, peer-to-peer systems that have no central authority or oversight like this. Designated actors are responsible for processing transactions, creating new blocks and maintaining the integrity and history of previous blocks.

The system for determining these actors and how they are selected is called a consensus mechanism. These mechanisms determine the process of who can confirm transactions and create new blocks on the blockchain and the protocol for how they do so. Because there is no central oversight, consensus needs to be designed in a way that prevents or disincentivizes malicious or uninformed actors from corrupting the integrity of the chain.

There are many consensus algorithms. You may have heard of some widely used ones like Proof-of-Work or Proof-of-Stake. Each mechanism has its own way of determining who is eligible to process transactions and create new blocks, and how how actors are selected to do so.

The Energy Web Chain uses the Proof-of-Authority (PoA) consensus mechanism.

All consensus mechanisms have disadvantages and advantages and are chosen based on the purpose and use case of the blockchain it will be serving. You can read more about why Energy Web employs the Proof-of-Authority mechanisms below.

Proof-of-Authority Consensus

The Proof-of-Authority (PoA) consensus mechanism has a defined set of actors that validate transactions and propagate new blocks to the chain. Rather than competing or staking for a chance to add blocks, they take turns creating new blocks in a round-robin style. These actors are called validators.

Energy Web validators participate by running full nodes of the blockchain using OpenEthereum client software. Smart contracts called Validator-Set contracts have the functionality to add or remove validators. Anyone can run a full node of the blockchain, but only addresses that are included in the Validator-Set contracts can validate transactions and seal blocks. You can read about the Energy Web Chain's Validator Set Contracts here.

The Energy Web Chain uses a specific type of PoA called Authority Roundtable (AuRa). The AuRa Proof-of-Authority consensus mechanism can be used by blockchains that run the OpenEthereum client.

You can read more about the validator process below.

Energy Web Chain Validators

In other consensus mechanisms, such as Proof-of-Work or Proof-of-Stake, miners can remain anonymous. So long as they meet the proof-of-work or staking requirements, they can process transactions on the blockchain and in many cases do so anonymously.

Validators are not anonymous. They have applied to become a validator and have undergone a a KYC (“Know Your Customer”) process as part of their application. Our validators are well-known members of the energy community, meet the eligibility requirements and the hardware/software installation specifications to become a validator, and they have a vested interest in the Energy Web Chain’s performance. You can see a full list of Energy Web Chain validators here.

Validator Functions

1. Validators create blocks: The fundamental role of the Proof-of-Authority validator is to validate transactions, compile valid transactions into blocks and propagate new blocks to the network.

2. Validators provide network security: By storing the current and historical state of the Energy Web Chain, each validator contributes to the overall integrity and security of the network. Since at least 51% of validators are required to sign each block before it is finalized on the chain, validators provide checks and balances against any erroneous or malicious attempts to publish falsified transactions or alter historical data. Physical decentralization of validator nodes provides redundancy in the event that one or more validators is unavailable due to technical reasons or otherwise compromised.

3. Validators participate in the the Energy Web Chain's governance: Validators will be asked to offer opinions and contribute to technical and non-technical decisions relating to modifications of the Energy Web client, protocol and validator set.

Why Proof-of-Authority?

Energy Web uses Proof-of-Authority consensus for three primary reasons that benefit the Energy Web’s digital infrastructure, the energy sector that will use the technology, and the environment as a whole.

1. To enable transaction capacity on the order of hundreds to thousands of transactions per second: we estimate that the Energy Web Chain has the ability to achieve 30x greater throughput capacity than the Ethereum Mainnet;

2. To minimize resource (i.e. electricity and computation) consumption, and subsequently, transaction costs: Eliminating competitive Proof-of-Work results in 54,000x less energy consumption and 350x lower network costs (i.e. costs incurred by organizations hosting validator nodes) which translates into lower and more stable transaction costs;

3. To improve compliance with relevant regulations and business requirements in the energy sector: substituting fully anonymous miners for vetted validators enhances the ability of decentralized applications to comply with various regulations, including data-protection regulations like GDPR, and increases the likelihood of widespread user and enterprise adoption.

To improve compliance with relevant regulations and business requirements in the energy sector: substituting fully anonymous miners for vetted validators enhances the ability of decentralized applications to comply with various regulations, including data-protection regulations like GDPR, and increases the likelihood of widespread user and enterprise adoption.

Proof-of-Authority Process

At a high level, the PoA mechanism works as follows:

1. All validator nodes maintain a complete list of the validators, identified by public keys. This list changes as validators are added or removed. In addition to storing the current and historical state of the network, all validators maintain essential information about the network (such as synchronized timing information and current data processing limits).

2. For a defined time window, one validator is assigned as the primary validator via the PoA algorithm. During this time, they are responsible for collecting the broadcasted transactions and proposing the new block. Only one validator is designated as primary at a time–based on a calculation derived from the timestamp on synchronized clocks among the validator nodes in the network and the number of validators–in order to prevent validators from arbitrarily creating blocks at irregular intervals.

3. If a validator fails to create a block when it is selected (e.g., because of hardware problems on the side of the validator) or its block fails to be validated by the pool of nodes (e.g., because of network connectivity problems), the next validator proceeds to create a block with whatever transactions haven’t been processed.

4. The remaining validator nodes verify that the transactions in each block are legitimate for that time window, sign the block with their private keys, and propagate the signed block to the network.

5. Once a simple majority of validators have authored a block on top of a given signed block, finality is achieved for that given block, and the block is confirmed by the network and added to the chain.

Additional Resources

• AuRa Proof-of-Authority white paper

• “What is "proof of work" and "proof of stake"? On CoinBase

• “Blockchain Consensus: A Simple Explanation Anyone Can Understand” on Blockgeeks

Connect MetaMask to the Energy Web blockchain

Prerequisite: Metamask plugin is installed in the browser; this section explains how to add the Energy Web blockchain to it.

Option1: Automatic configurator

To configure Metamask to connect to the Energy Web blockchain or to Volta, the fastest way to do that is using the or

Option2: Manual configuration

Video Tutorial

Assets in EW-DOS

In the context of EW-DOS, an Asset is a digital representation of a physical or virtual device on the Energy Web Chain. An Asset could represent, for example, a solar photovoltaic panel, a battery, an electric vehicle, or an IOT device.

Assets must have a Decentralized Identifier - DID in the Energy Web Chain's DID Registry in order to participate in applications and marketplace activities. Once an Asset has a DID, it can take on roles within an organization or application. This is discussed further below.

Asset Smart Contracts

Assets and their chain of custody are managed by smart contracts that are deployed on the Energy Web Chain.

IdentityManager smart contract

When an Asset is first created, it is registered in the IdentityManager smart contract as an owned identity (the owner address being the Asset owner, discussed below).

The main purpose of the IdentityManager smart contract is to have a on-chain location which aggregates known assets. In other words, it provides a kind of "asset-registry" functionality. This can allow one for instance, to more easily answer questions such as "how many assets have been registered in total?".

While there are many OfferableIdentity smart contracts, there is intended to be fewer IdentityManager smart contracts as the IdentityManager's main purpose is the aggregation of OfferableIdentity information. For instance, an enterprise could have a single IdentityManager to all assets which are registered by their employees.

OfferableIdentity smart contract

The Asset owner can offer ownership to another DID. The OfferableIdentity smart contract provides methods to verify, offer and transfer ownership of Assets (these concepts are discussed in further detail below).

Asset Owners

Every Asset must have an owner. Asset owners initiate the registration, transference and enrolment activity of their Assets. This requires them to make transactions on behalf of their Asset, so the owner must have an address on the Energy Web Chain that is connected to an Ethereum-compatible crypto-currency wallet such as MetaMask. The owner of an Asset is recorded in the Asset's identity on-chain.

Asset Chain-of-Custody

The iam-client-library Asset service provides high-level methods to facilitate the chain of custody for an Asset.

Chain-of-custody events (registration, ofference and transference) for an Asset are emitted from the IdentityManager smart contract. SSI Hub listens for and persists the details of these events. All historical owners of an Asset and the dates of offer, transference and acceptance are accessible through SSI Hub's API.

Register Asset

Registering as Asset involves creating an OfferableIdentity smart contract for the Asset on the Energy Web Chain, and registering its identity in the IdentityManager smart contract. This is initiated by the Asset owner. Because each Energy Web Chain address is a valid DID under the did:ethr DID method, each asset inherently has a DID.

Transfer Asset Ownership

The owner of a registered Asset can transfer ownership to another address on the Energy Web Chain. (The new owner's address must have signing capabilities in order to sign transactions associated with asset management).

The OfferableIdentity smart contract provides methods to facilitate Asset transferance. This contract makes calls to the IdentityManager smart contract so that the state of the Asset is updated at each phase of the transfer.

1. Offer Asset

When a transfer is initialized, an 'offer' of transfer is made to the recipient DID.

The state of the Asset identity is marked as 'offered' in the IdentityManager smart contract.

2a. Accept Asset

The DID that the Asset was offered to must accept the Offer before it is transferred to them. iam-client-library provides a method to accept the transfer. The Asset's owner is updated in the IdentityManager smart contract to reflect the new ownership.

2b. Reject Asset

The DID that the Asset was offered to has the option to reject the transfer. The Asset's 'offered' status in the IdentityManager smart contract is set to 'false'.

Asset Enrolment

An Asset can take on (enrol to) roles within an organization or an application. If their enrolment request is approved by the role issuer, the Asset is issued a role-based verifiable credential.

• If the Asset's owner is an authorized issuer of the desired role, the Asset owner can directly issue a role-based verifiable credential to their Asset.

• If the Asset's owner is not an authorized issuer of the desired role, the owner can submit an enrolment request on behalf of their Asset to the issuer.

iam-client-library provides the high-level methods to request and issue enrolments. See the API documentation here.

Using and Managing Assets in EW-DOS

Switchboard provides an interface for users to register, transfer and enroll Assets. If you are logged into Switchboard, you can view the Asset management interface here.

iam-client-library contains the high-level functions for managing (registering, fetching, transferring, etc.) assets and their corresponding data. You can view the service API documentation for Assets in the library here.

Use Case: Stedin Decentralized Asset Management

Energy Web and the distribution system operator (DSO) Stedin jointly developed a decentralized energy asset management system leveraging the EW-DOS components and architecture discussed above.

The goal of this collaboration was to:

• Facilitate secure, encrypted communication between distributed energy resources (DERs) (i.e. solar panels, batteries, etc) and the grid

• Enable DERs to provide grid services (e.g. selling excess energy back to the grid)

Grid assets (e.g, smart meters, distribution automation devices), and distrubuted energy resources (DERs) were assigned DIDs. The DID is anchored on the asset's pre-existing SIM cards. Each asset exists as an identity in the IdentityManager smart contract on the Energy Web Chain. Cryptographically signed information (such as control signals and commands) from the DSO (Stedin) can then be sent to targeted assets. This allows for an awareness and exchange of grid services between the DSO and DERs.

You can read more about this use case in the official press release here.

1. Download Nethermind Client

2. Full specification for Nethermind configuration options can be found here:

   1. https://docs.nethermind.io/

   2. https://docs.nethermind.io/get-started/system-requirements

3. Run the following command in your terminal -

Run RPC node in Volta Network

chmod +x nethermind
# To run a Full node
./nethermind --config volta 

# To run an Archive node
./nethermind --config volta_archive

Run RPC node in EWC Network

# To run a Full node
./nethermind --config energyweb

# To run an Archive node
./nethermind --config energyweb_archive

Your local node should start:

2024-03-05 13-54-12.2501|Nethermind starting initialization.
2024-03-05 13-54-12.2939|Client version: Nethermind/v1.25.4+20b10b35/linux-x64/dotnet8.0.2
2024-03-05 13-54-12.2980|Loading embedded plugins
2024-03-05 13-54-12.2981|  Found plugin type Nethermind.Consensus.AuRa.AuRaPlugin
2024-03-05 13-54-12.2982|  Found plugin type Nethermind.Consensus.Clique.CliquePlugin
2024-03-05 13-54-12.2983|  Found plugin type Nethermind.Consensus.Ethash.EthashPlugin
2024-03-05 13-54-12.2983|  Found plugin type Nethermind.Consensus.Ethash.NethDevPlugin
2024-03-05 13-54-12.2983|  Found plugin type Nethermind.Hive.HivePlugin
2024-03-05 13-54-12.2983|  Found plugin type Nethermind.UPnP.Plugin.UPnPPlugin
Resolved executing directory as /home/ubuntu/neth/nethermind-1.25.4.
2024-03-05 13-54-12.3211|Loading 12 assemblies from /home/ubuntu/neth/nethermind-1.25.4/plugins
2024-03-05 13-54-12.3212|Loading assembly Nethermind.Init
2024-03-05 13-54-12.3230|Loading assembly Nethermind.Merge.AuRa
2024-03-05 13-54-12.3254|  Found plugin type Nethermind.Merge.AuRa
2024-03-05 13-54-12.3255|Loading assembly Nethermind.HealthChecks
2024-03-05 13-54-12.3270|  Found plugin type Nethermind.HealthChecks
2024-03-05 13-54-12.3271|Loading assembly Nethermind.EthStats
2024-03-05 13-54-12.3276|  Found plugin type Nethermind.EthStats
2024-03-05 13-54-12.3277|Loading assembly Nethermind.Consensus.AuRa
2024-03-05 13-54-12.3315|Loading assembly Nethermind.Optimism
2024-03-05 13-54-12.3330|  Found plugin type Nethermind.Optimism
2024-03-05 13-54-12.3331|Loading assembly Nethermind.JsonRpc.TraceStore
2024-03-05 13-54-12.3338|  Found plugin type Nethermind.JsonRpc.TraceStore
2024-03-05 13-54-12.3338|Loading assembly Nethermind.Mev
2024-03-05 13-54-12.3361|  Found plugin type Nethermind.Mev
2024-03-05 13-54-12.3361|Loading assembly Nethermind.Init.Snapshot
2024-03-05 13-54-12.3365|  Found plugin type Nethermind.Init.Snapshot
2024-03-05 13-54-12.3366|Loading assembly Nethermind.Merge.Plugin
2024-03-05 13-54-12.3393|  Found plugin type Nethermind.Merge.Plugin
2024-03-05 13-54-12.3394|Loading assembly Nethermind.AccountAbstraction
2024-03-05 13-54-12.3419|  Found plugin type Nethermind.AccountAbstraction
2024-03-05 13-54-12.3420|Loading assembly Nethermind.Api
2024-03-05 13-54-12.4062|Loading standard NLog.config file from /home/ubuntu/neth/nethermind-1.25.4/NLog.config.
2024-03-05 13-54-12.4908|NLog.config loaded in 83ms.
2024-03-05 13-54-12.4915|Reading config file from /home/ubuntu/neth/nethermind-1.25.4/configs/volta.cfg
2024-03-05 13-54-12.5428|Configuration initialized.
05 Mar 13:54:12 | RocksDb Version: 8.3.2 
05 Mar 13:54:12 | Loading chainspec from embedded resources: /home/ubuntu/neth/nethermind-1.25.4/chainspec/volta.json 
05 Mar 13:54:12 | CPU:  (CT) 
05 Mar 13:54:12 | Using http://ipv4.icanhazip.com to get external ip 
05 Mar 13:54:12 | Setting up memory allowances 
05 Mar 13:54:12 |   Memory hint:          768 MB 
05 Mar 13:54:12 |   General memory:        32 MB 
05 Mar 13:54:12 |   Peers memory:          25 MB 
05 Mar 13:54:12 |   Netty memory:         134 MB 
05 Mar 13:54:12 |   Mempool memory:       110 MB 
05 Mar 13:54:12 |   Fast blocks memory:    46 MB 
05 Mar 13:54:12 |   Trie memory:           83 MB 
05 Mar 13:54:12 |   DB memory:            335 MB 
05 Mar 13:54:12 | Generating private key for the node (no node key in configuration) - stored in plain + key store for JSON RPC unlocking 
05 Mar 13:54:14 | Store this password for unlocking the node key for JSON RPC - this is not secure - this log message will be in your log files. Use only in DEV contexts. 
05 Mar 13:54:16 | Block tree initialized, last processed is 0, best queued is 0, best known is 0, lowest inserted header , body , lowest sync inserted block number  
05 Mar 13:54:16 | Initializing 15 plugins 
05 Mar 13:54:16 |   Clique by Nethermind 
05 Mar 13:54:16 |   Clique by Nethermind initialized in 0ms 
05 Mar 13:54:16 |   AuRa by Nethermind 
05 Mar 13:54:16 |   AuRa by Nethermind initialized in 0ms 
05 Mar 13:54:16 |   Ethash by Nethermind 
05 Mar 13:54:16 |   Ethash by Nethermind initialized in 0ms 
05 Mar 13:54:16 |   Optimism by Nethermind 
05 Mar 13:54:16 |   Optimism by Nethermind initialized in 0ms 
05 Mar 13:54:16 |   NethDev by Nethermind 
05 Mar 13:54:16 |   NethDev by Nethermind initialized in 0ms 
05 Mar 13:54:16 |   AuRaMerge by Nethermind 
05 Mar 13:54:16 |   AuRaMerge by Nethermind initialized in 0ms 
05 Mar 13:54:16 |   Merge by Nethermind 
05 Mar 13:54:16 |   Merge by Nethermind initialized in 2ms 
05 Mar 13:54:16 |   MEV by Nethermind 
05 Mar 13:54:16 |   MEV by Nethermind initialized in 0ms 
05 Mar 13:54:16 |   HealthChecks by Nethermind 
05 Mar 13:54:16 |   HealthChecks by Nethermind initialized in 1ms 
05 Mar 13:54:16 |   Hive by Nethermind 
05 Mar 13:54:16 |   Hive by Nethermind initialized in 0ms 
05 Mar 13:54:16 |   Account Abstraction by Nethermind 
05 Mar 13:54:16 |   Account Abstraction Plugin: User Operation Mining Disabled 
05 Mar 13:54:16 |   Account Abstraction by Nethermind initialized in 0ms 
05 Mar 13:54:16 |   EthStats by Nethermind 
05 Mar 13:54:16 |   EthStats by Nethermind initialized in 0ms 
05 Mar 13:54:16 |   Snapshot by Nethermind 
05 Mar 13:54:16 |   Snapshot by Nethermind initialized in 0ms 
05 Mar 13:54:16 |   TraceStore by Nethermind 
05 Mar 13:54:16 |   TraceStore by Nethermind initialized in 0ms 
05 Mar 13:54:16 |   UPnP by Nethermind 
05 Mar 13:54:16 |   UPnP by Nethermind initialized in 0ms 
05 Mar 13:54:16 | Loaded 0 static nodes from file: /home/ubuntu/neth/nethermind-1.25.4/Data/static-nodes.json 
05 Mar 13:54:16 | Skipping Account Abstraction network protocol 
05 Mar 13:54:16 | Now syncing nodes starting from root of block 0 
05 Mar 13:54:16 | No block tree levels to review for fixes. All fine. 
05 Mar 13:54:16 | Numbers resolved, level = Max(0, 0), header = Max(0, 0), body = Max(0, 0) 
05 Mar 13:54:16 | Beacon Numbers resolved, level = 0, header = 0, body = 0 
05 Mar 13:54:16 | Loading fork choice info 
05 Mar 13:54:16 | Grafana / Prometheus metrics are disabled in configuration 
05 Mar 13:54:16 | System.Diagnostics.Metrics disabled 
05 Mar 13:54:16 | Skipping Flashbots RPC plugin 
05 Mar 13:54:16 | Skipping Account Abstraction RPC plugin 
05 Mar 13:54:16 | Json RPC is disabled 
05 Mar 13:54:16 | 
======================== Nethermind initialization completed ========================
This node    : enode://15ec8f735368cf809735071cd607ee8e12fe86bbbc99c14161272c8a2253d4a7cf063d46b9cd201735011ae008687175b504bdcf45f8f20605a763d39b951044@15.188.207.110:30303
Node address : 0x1dc9ca5452806e178959506e100300d3566ec79f (do not use as an account)
Mem est tx   :    40 MB
Mem est DB   :     8 MB
Genesis hash : 0xebd8b413ca7b7f84a8dd20d17519ce2b01954c74d94a0a739a3e416abe0e43e5
External IP  : 15.188.207.110
Ethereum     : tcp://15.188.207.110:30303
Discovery    : udp://15.188.207.110:30303
Client id    : Nethermind/v1.25.4+20b10b35/linux-x64/dotnet8.0.2
Chainspec    : chainspec/volta.json
Chain head   : 0
Chain ID     : Volta
===================================================================================== 
05 Mar 13:54:17 | Changing state Disconnected to FastHeaders at processed: 0 | state: 0 | block: 0 | header: 0 | target block: 26907152 | peer block: 26907152 
05 Mar 13:54:17 | Sync mode changed from Disconnected to FastHeaders 
05 Mar 13:54:17 | Connected to 2 bootnodes, 7 trusted/persisted nodes 
05 Mar 13:54:20 | Changing state FastHeaders to FastSync, FastHeaders at processed: 0 | state: 0 | block: 0 | header: 26680000 | target block: 26907153 | peer block: 26907153 
05 Mar 13:54:20 | Sync mode changed from FastHeaders to FastSync, FastHeaders 
05 Mar 13:54:21 | Peers | with best block: 2 | all: 2 | eth66 (100 %) | Active: 2 Headers, 1 Bodies, 1 Receipts, 1 Blocks | Sleeping: None | OpenEthereum (100 %) 
05 Mar 13:54:21 | Old Headers       2,560 / 26,680,000 (  0.01 %) | queue     2,048 | current            0 Blk/s | total          640 Blk/s 
05 Mar 13:54:25 | Discovered new block 26907154 13:54:25 (0xbf2c2c...21b348), tx count: 0 miner 0xe6c064719623c5bc62ef51caa4639416f8634ab6, sent by [Peer|eth66|26907154|   3.121.165.10:30303| Out], with AuRa step 341929373 
05 Mar 13:54:26 | Old Headers       6,144 / 26,680,000 (  0.02 %) | queue         0 | current          717 Blk/s | total          683 Blk/s 
05 Mar 13:54:26 | Downloaded   26,680,637 / 26,907,154 ( 99.16 %) | current            0 Blk/s | total          128 Blk/s 
05 Mar 13:54:30 | Discovered new block 26907155 13:54:30 (0x702e54...a3e29f), tx count: 0 miner 0xc09e63b27775508b6599daf3b6dcbe09cf3f82ac, sent by [Peer|eth66|26907155|   3.121.165.10:30303| Out], with AuRa step 341929374 
05 Mar 13:54:31 | Old Headers       8,192 / 26,680,000 (  0.03 %) | queue         0 | current          410 Blk/s | total          585 Blk/s 
05 Mar 13:54:31 | Downloaded   26,681,653 / 26,907,155 ( 99.16 %) | current          203 Blk/s | total          167 Blk/s 
05 Mar 13:54:35 | Discovered new block 26907156 13:54:35 (0xa73994...be656b), tx count: 0 miner 0x20ea864187c1c1eaa613726ed4d211244209503c, sent by [Peer|eth66|26907156|   3.121.165.10:30303| Out], with AuRa step 341929375 
05 Mar 13:54:36 | Old Headers       9,728 / 26,680,000 (  0.04 %) | queue         0 | current          307 Blk/s | total          512 Blk/s 
05 Mar 13:54:36 | Downloaded   26,682,669 / 26,907,156 ( 99.17 %) | current          203 Blk/s | total          179 Blk/s 

Run a local node using Docker with Nethermind client

This section describes minimal setup to run an RPC node locally or on the server using Docker container run with docker-compose. This is solely for development purposes, it's not a production grade recommendation.

See Nethermind documentation for Docker: https://docs.nethermind.io/get-started/installing-nethermind#docker-container

Set up

1. Verify that prerequisites are installed:

docker --version 
docker-compose --version 

1. Create working directory

mkdir data_dir

1. Create docker-compose.yaml file

cat > docker-compose.yaml << 'EOF'
version: '3.8'
services:
  nethermind:
    image: nethermind/nethermind:1.25.4
    restart: always
    command:
      --config volta -dd /nethermind/data_dir
      # For EnergyWebChain network
      # --config energyweb -dd /nethermind/data_dir
    volumes:
      - ./data_dir:/nethermind/data_dir     
    ports:
      - 8545:8545
      - 8546:8546
      - 30303:30303
      - 30303:30303/udp
EOF

1. Start container:

docker-compose up -d

1. Examine logs:

docker-compose logs --tail 20 nethermind

The log output should be similar to the following

nethermind_1  | Mem est tx   :    40 MB
nethermind_1  | Mem est DB   :     8 MB
nethermind_1  | Genesis hash : 0xebd8b413ca7b7f84a8dd20d17519ce2b01954c74d94a0a739a3e416abe0e43e5
nethermind_1  | External IP  : 15.188.207.110
nethermind_1  | Ethereum     : tcp://15.188.207.110:30303
nethermind_1  | Discovery    : udp://15.188.207.110:30303
nethermind_1  | Client id    : Nethermind/v1.25.4+20b10b35/linux-x64/dotnet8.0.2
nethermind_1  | Chainspec    : chainspec/volta.json
nethermind_1  | Chain head   : 0 (0xebd8b4...0e43e5)
nethermind_1  | Chain ID     : Volta
nethermind_1  | ===================================================================================== 
nethermind_1  | 05 Mar 13:57:50 | Changing state Disconnected to FastSync, FastHeaders at processed: 0 | state: 0 | block: 26696639 | header: 26696639 | target block: 26907183 | peer block: 26907183 
nethermind_1  | 05 Mar 13:57:50 | Sync mode changed from Disconnected to FastSync, FastHeaders 
nethermind_1  | 05 Mar 13:57:51 | Connected to 2 bootnodes, 4 trusted/persisted nodes 
nethermind_1  | 05 Mar 13:57:54 | Peers | with best block: 2 | all: 2 | eth66 (100 %) | Active: 2 Headers, 1 Bodies, 1 Receipts, 1 Blocks | Sleeping: None | OpenEthereum (100 %) 
nethermind_1  | 05 Mar 13:57:54 | Old Headers     122,368 / 26,680,000 (  0.46 %) | queue         0 | current            0 Blk/s | total       30,593 Blk/s 
nethermind_1  | 05 Mar 13:57:54 | Downloaded   26,697,149 / 26,907,183 ( 99.22 %) | current            0 Blk/s | total          131 Blk/s 
nethermind_1  | 05 Mar 13:57:59 | Old Headers     130,048 / 26,680,000 (  0.49 %) | queue         0 | current        1,537 Blk/s | total       14,454 Blk/s 
nethermind_1  | 05 Mar 13:57:59 | Downloaded   26,698,165 / 26,907,184 ( 99.22 %) | current          203 Blk/s | total          173 Blk/s 
nethermind_1  | 05 Mar 13:58:00 | Discovered new block 26907185 13:58:00 (0x03214c...f02603), tx count: 0 miner 0x20ea864187c1c1eaa613726ed4d211244209503c, sent by [Peer|eth66|26907185|   3.121.165.10:30303| Out], with AuRa step 341929416 

Nethermind Configuration

• https://docs.nethermind.io/fundamentals/configuration

Background

Decarbonizing electric grids around the world is the single most impactful step we can take to mitigate climate change. Luckily, we are headed in the right direction: renewables and small scale clean energy assets called distributed energy resources or DERs—assets like electric vehicles, rooftop solar systems, batteries, and other flexible electric loads—are being deployed at an unprecedented rate. Unfortunately, it’s not fast enough: to achieve net-zero emissions by 2050, annual clean energy deployment needs to be three times higher than it is today through at least 2030. And if we want to get there, we have to overcome a serious obstacle: today’s electric utilities are not equipped with the tools needed to manage a renewable grid populated with millions upon millions of DERs.

The grid works by maintaining a precise balance between supply and demand. Today, utilities achieve this via a century-old model: generate power in large, centralized stations and feed it one-way to customers. This model assumes 1) utilities have direct visibility and control over generation (supply) and 2) customer demand for electricity is both passive and predictable. These axioms are no longer valid: renewable energy output is variable and largely a function of weather while demand for electricity from customers—who now own DERs capable of storing electricity, shifting when it’s used, or even injecting power back into the grid— is anything but predictable. A grid composed of vast amounts of renewables and DERs presents a complete paradigm shift for electric utilities.

Utilities have never faced a challenge like this before, nor are they equipped with the tools needed to manage this new paradigm. We aim to change this with a Digital Spine.

Digital Spine Overview

In its simplest form, a Digital Spine is a thin layer of interoperability that connects and communicates information between all of the hardware, software, and organizational systems comprising a grid in near real time. In contrast to the existing information technology landscape that utilities rely on today (which features limited information sharing between isolated and fragmented systems) a Digital Spine offers an open-access, cohesive infrastructure that is jointly governed and operated as a public good.

Today the concept of a Digital Spine - a common digital layer for transactions and interoperability for all actors and processes in an energy system - is being developed in multiple energy markets globally, most notably the UK.

Energy Web's Digital Spine toolkit includes four elements:

• Identity and Access Management (IAM): this component implements a unified authentication and authorization framework using self-managed, sovereign digital identities. This gives utilities and other grid participants the ability to mutually authenticate each other’s identity and authorize selective disclosure or communication of information based on their respective roles and responsibilities. A key benefit of this approach, in contrast to existing piecemeal systems, is delivering a “single sign on” user experience that improves interoperability and streamlines trusted integrations between devices, systems, and organizations without relying on a central administrator.

• Data and Message Exchange Module: this component is a secure, open-access messaging infrastructure that 1) allows market participants to send, receive, and authenticate messages based on the roles that have been issued to and associated with their self-managed identity; 2) allows market participants to exchange diverse datasets, ranging from real-time telemetry to bulk file uploads; and 3) requires only a single integration mechanism with a central infrastructure in order to communicate via one:one (unicast), one:many (broadcast), and many:many (multicast) channels.

• Data Hub Client Gateway: this component is an independent application that Digital Spine participants deploy in order to access the shared message broker. The Client Gateway provides a standardized interface to read and write messages in specific channels within the message broker.

• Joint Business Processing: for DERs to be fully utilized, in many instances information needs to be transmitted amongst three or more parties in a way that does not reveal all data to all parties. In these instances, Energy Web has developed an open source, decentralized technology called “Worker Nodes” that ingest data from external sources, execute custom workflows based on predefined business logic, and vote on results in order to establish consensus without revealing or modifying the underlying data. This technology borrows concepts from public distributed ledger solutions, namely distributed consensus protocols which use cryptographic techniques to establish provably correct and timely results.

Digital Spine Use Cases

Collectively, these four components provide a shared digital infrastructure that facilitates communication and coordination between utility hardware and software systems–from smart meters to network planning tools–and DERs and the companies who manage them. Ultimately, a Digital Spine exists to enable new applications provided by other software vendors and utilities themselves, including:

• Demand Response / Transactive Energy / Virtual Power Plants: Though there are many different names for it, the concept of using market mechanisms and dynamic pricing to influence DER behavior is well established globally. The Digital Spine enables distribution utilities to construct sophisticated transactive energy programs that procure grid services from DERs at specific locations and/or at specific times of day. For this use case, the role of the Spine is to facilitate data exchange and validation between the utility’s operations center and multiple third-party DER operators.

• Network Optimization via Operating Envelopes: Operating envelopes (also called Dynamic Line Ratings) are an emerging solution for dynamically modifying import (consumption) or export (generation) of DERs to the distribution network. The core function of an operating envelope is to define limits on how much power can be injected or drawn by DER based on physical constraints within the distribution system. For this use case, the role of a Digital Spine is to ingest and partition (i.e. route) operating envelopes to the appropriate DER operators so DER can safely sell services wholesale and to the distribution utility.

Moving forward, our full vision for a Digital Spine includes additional applications where consortium building and technology integrations with existing vendors is critical:

• Distribution network modeling / analytics solutions: Utilities need partners that can ingest both traditional system data and DER data to construct digital twins of entire networks in different ways and provide advanced analytical capabilities to utilities to support both operations and planning.

• Optimization solutions: Dynamic line ratings (also called operating envelopes) are one way of optimizing dispatch of DER at the distribution level. There are many other companies that offer solutions to help optimize dispatch and management of DER who can use a Digital Spine to efficiently communicate distribution network conditions and constraints to other market participants.

• Forecasting solutions: Today many companies offer forecasting capabilities (e.g. system demand, power flows within specific network lines, renewable output, etc.). A Spine can enhance forecasting capabilities by making additional datasets that are currently too complex or costly to integrate available to forecasting providers.

• Real time operations solutions: Today there are many companies offering DER management systems and advanced distribution network management systems, but they are not ubiquitous. A Spine could make it easier to bring these solutions to utilities who currently lack them.

When using Switchboard, users can create and update data that is stored in smart contracts on the Energy Web Chain. These actions require users to pay a small transaction cost. Users pay transaction costs using their cryptocurrency wallet such as MetaMask. Transaction costs on the Energy Web Chain are in Energy Web Token. Transaction costs on the Volta Test Network on are in Volta Tokens.

The transaction cost amount depends on what action the user is performing, and the current gas cost. Actions and their estimated associated total transaction cost are listed below. They are organized according to the three main domains of Switchboard: Enrolments, Governance and Assets.

Calculating Transaction Costs

The total costs calculated below is the sum of the cost to process the metadata and the current gas cost. The costs below are approximate values per operation. The total cost can change:

• Based on the user input data (e.g. number of input fields)

• Based on congestion (i.e. how many transaction requests are currently in the pool to be processed), which affects gas price

Enrolments

Switchboard is used to request, issue, publish and revoke role-based credentials. These credentials are persisted on the Energy Web Chain (read more about on-chain credentials here). As such, they require transaction costs to cover their on-chain lifecycle events.

My Enrolments

Revocable Enrolments

Governance

Switchboard is used to create and manage organizations, applications, and roles associated with them. These elements are persisted in Energy Web's Ethereum Name Service smart contract. ٍ Each time a user creates or updates one of these entities, they must pay a small transaction cost

Organizations

Applications

Assets

Switchboard is used to create (register), manage and transfer Assets. Each Asset is registered in a smart contract on the Energy Web Chain (read more about Assets as ownable smart contracts here.) Each time a user interacts with these contracts for Asset management, they must pay a small transaction cost:

Related Content

Overview

Validator Set contracts provide information on current validators and private functionality to add and remove validators.

Documentation and Source Code

• Energy Web Validator Set Contracts

• OpenEthereum documentation on Validator Set contracts

Components

For upgradeability purposes, the contracts are divided into 2 parts. See below Fig. 1.

RelaySet Contract

This contract implements the required reporting ValidatorSet interface expected by the engine and it is the contract defined in the chainspec seen by the engine. It relays most of the function calls to the RelayedSet contract, which holds the actual logic. The logic contract can be replaced (upgraded), so it is possible to change the behavior of validator management without conducting a hard fork.

RelayedSet Contract

This contract implements the logic and manages the validator list. The owner of the validator set interacts with this contract for managing the validators. This contract maintains two validator sets:

1. The current validator set (the validators who are actively sealing)

2. The migration validator set, which is the new set we migrate to in case of a change (validator addition or removal).

Validator States

Validators and potential validators have four states in these contracts:

1. Active validator: Validator is in the active validator set, sealing new blocks

2. Not a validator: The address nothing has to do with validation.

3. Pending To Be Added Validator: Validator is already added by the owner and their acceptance is pending, but not active yet until it is finalized. This implies that the validator cannot report, be reported, or produce blocks yet.

4. Pending To Be Removed Validator: Validator is pending to be removed (removed by the owner), but it is not finalized, and so is still active as a validator. This implies that as long as the removal is not finalized, the validator is actively producing blocks, can report and can be reported on.

Reporting

The RelayedSet contract logs malicious or benign reports by emitting corresponding log events that can be seen by anyone. Reporting can only be on and about active sealing validators.

event ReportedMalicious(address indexed reporter, address indexed reported, uint indexed blocknum);
event ReportedBenign(address indexed reporter, address indexed reported, uint indexed blocknum);

The events contain the reporter- and reported address, and the block number which the validator was reported on.

Interaction with RelayedSet (logic) Contract