In order to better understand the Energy Web Ecosystem, this section provides a high level introduction to the core concepts and terminologies which will be used across this documentation.

Lowering is the exact opposite of token lifting. It is the process of migrating EWT from EWX to EWC. Normally, this will be used to withdraw rewards claimed after gaining them by operating worker nodes.

The Energy Web Chain (EWC) is a publicly-accessible EVM-based blockchain formed as a software infrastructure with permissioned validators hosted by EWF Affiliate organizations. It relies on a Proof-of-Authority consensus mechanism with capacity for a 30x performance improvement and 2-3 orders of magnitude lower energy consumption compared to Ethereum.

Ethereum

The Energy Web blockchain is derived from Ethereum blockchain 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 Ethereum Virtual Machine (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 decentralized applications (dapps). These programs are called smart contracts. 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 here.

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.

Read an overview of Ethereum and the Ethereum Virtual Machine on the Ethereum documentation's "What is Ethereum" section here.

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.

• Introduction to Ethereum

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

• Blocks

• Accounts

• Ethereum Virtual Machine

• Gas

• Smart Contracts

Additional Resources

• Ethereum Documentation: Ethereum development documentation | ethereum.org

• “Best Resources for Learning About Blockchain and Ethereum” on Medium

• Dapp University YouTube Series on building Dapps with Ethereum: Dapp University

• “The Ethereum Virtual Machine: How Does It Work?” on Medium

• Chapter 1: What Is Ethereum? · GitBook

• Chapter 2: Ethereum Basics · GitBook

Energy Web X is an ecosystem comprising multiple applications and services including but not limited to the EWX blockchain, EWX Token Bridge, Lift & Lower Pallets, worker nodes, and worker node networks.

EWX is a substrate-based blockchain under EWF. It is the backbone of the entire EWX ecosystem. The EWX Token Bridge is an EWC Smart Contract which facilitates the migration of EWT from EWC to EWX. The lift and lower pallets are equivalent to EVM-based smart contracts which enables the lifting and lowering of EWTs between EWC and EWX.

Lifting is the process of migrating EWT from EWC to EWX. EWT will be needed by participants to register as worker node operators and to stake to solution groups containing the Smart Flows.

The Energy Web Token (EWT) is the native utility token to access services and orchestrate stakeholders within its blockchain system. In the context of Energy Web Chain, EWT compensates validators for processing transactions, and are used to pay for transactions.

Energy Web X leverages and complements 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. 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: 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 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.

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.

A worker node is a decentralized application (dApp) which enables enterprises to construct distributed computing networks which securely execute sensitive business operations. Each worker node can execute multiple solutions at the same time; subject to the limits of each operator system.

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 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 processes are followed correctly, ensure computational outputs from business processes are correct, and preserve the privacy and integrity of underlying data for auditing purposes.

Currently, there are 2 types of worker nodes available:

1. Server-based Worker Node

2. Marketplace Desktop Application

The server-based worker node is a decentralized application mainly offered to enterprises to be deployed in highly configurable execution environments on-cloud or on-premises. Deployment can be done via Dockerization.

It is mainly composed of the worker node dApp and a Node RED server bundled in a single package. It automatically syncs the subscriptions of the worker node account set in its environment variable and subsequently runs any active solutions for diligent execution and submission of votes.

A vote is initiated upon the submission of the Merkle-tree root hash of the calculated data for each specific use-case. All votes are tied to a voting round.

A voting round is determined by the unique identifier provided by each BC when the Smart Flow fetches the data from the respective BC system for each specific use-case.

For the current implementation, each worker computes the consensus right after its successful submission of a vote in a voting round. The worker fetches the previous vote submissions from EWX under the current voting round. The worker groups the root hashes and counts the submissions from unique operators per unique root hash.

The consensus is determined when a particular root hash contains the majority of submitted votes.

When the majority of votes is not met, the voting round becomes stale and no response coming from the network of worker nodes is expected. However, this scenario may be confirmed externally by directly querying on-chain using a third-party application which will not be available in this phase.

EWF will develop a more robust consensus orchestrator environment and will be available towards Q4 2024. More details will be shared once requirements are finalized at EWF.

InEExS Project Consensus Mechanism

In the case of the InEExS Project, consensus is determined using the formula below:

M = TO * 0.5 + 1

Wherein, M = majority of votes, and TO = Total operators subscribed in the solution group.

A subscription is an EWT staking action initiated by the worker node operator to agree and commit in actively participating in executing a group of solutions subject to the solution group’s terms and conditions. In return, the operators expect to gain rewards by diligently performing the solution executions while having the possibility to get slashed when underperforming. The solution registrar sets the stake amounts and other configurations upon the creation of the solution group and solutions.

Reward period is the schedule for worker nodes to participate in vote submissions and gain rewards. The solution registrar defines the duration of reward periods. For example, if rewards are to be paid daily, the reward period needs to be set to a 24-hour estimated equivalent in blocks. Each block is approximately 12 seconds in duration.

A DID is an identifier that is user-generated and not coupled to any centralized authority. It can be used to identify any subject, such as a non-tangible asset, a customer, or an organization.

Unlike traditional forms of identification, DIDs are not generated by a central authority, such as a government-issued driver’s license, or a bank-issued account number, and they are not stored in a centralized database. A user can create a DID for themselves or an asset using cryptographic or other means.

A DID for a given system resides in a decentralized DID registry. DID Registries, like VCs and DIDs themselves, are developed according to W3C standards. Most DID registries live on a decentralized ledger, or a blockchain. In the case of EW-DOS, the DID registry is on the Energy Web Chain.

Learn more about DIDs

How are DIDs Created?

Public-Private Key Pairs

A DID is derived from a public-private key pair that is generated programmatically through a cryptographic algorithm. The algorithm produces a private key and a corresponding public key. Crypto wallets such as MetaMask will generate these keys for you on creation of an account. The public key can be exposed and shared with others, but the private key should not be shared with anyone. The algorithm used to generate the key-pair makes it virtually impossible for any outsider to guess your private key.

Your public key serves as your address on the blockchain, and your private key serves as your private identifier, similar to a password, and is used to sign transactions on the blockchain. The signature is proof that you initiated that transaction.

DID Format

DIDs are made up of a scheme, a method and a unique method identifier. There are many DID methods that are supported by different blockchain networks. You can see a full list here. DID methods define operations to create, resolve, update and deactivate DIDs and their associated DID Documents, which are discussed below. DID Methods are often associated with a verifiable data registry, which are registries with store DIDs and their data. If the registry is implemented on a blockchain, smart contracts usually serve as the data registry. An example of this is the did:ethr registry.

Energy Web Chain uses the ETHR DID Method Specification. The string that identifies this DID method is "ethr", and the method identifier is always the user’s public key (also known as an address.)

DID generated by ID Registry using ETHR DID Method Specification

DID Documents

Every DID resolves to a corresponding DID document, which contains metadata about the subject's authentication mechanisms and attributes, like its public key.

Below is a sample JSON document that was created by the EW-DOS DID library. For a list of required and possible DID Document properties, see the W3C documentation on DID Document Properties.

Copy

{
   "id":"did:ethr:0x17b65C8C9746F87c82cc6f7C4FC38fCA5f1AeB75",
   "authentication":[
      {
         "type":"owner",
         "validity":{
            "_hex":"0x1fffffffffffff"
         }
      }
   ],
   "created":null,
   "delegates":null,
   "proof":null,
   "publicKey":[
      {
         "id":"did:ethr:0x5B1B89A48C1fB9b6ef7Fb77C453F2aAF4b156d45#key-owner",
         "type":"Secp256k1veriKey",
         "controller":"0x5B1B89A48C1fB9b6ef7Fb77C453F2aAF4b156d45",
         "publicKeyHex":"0x02d0e12da3425d7b01fd2e49b283f939f3a13d71273d749dd8933d3b792bb20078"
      },
      {
         "id":"did:ethr:0x17b65C8C9746F87c82cc6f7C4FC38fCA5f1AeB75#key-owner",
         "type":"Secp256k1veriKey",
         "controller":"0x17b65C8C9746F87c82cc6f7C4FC38fCA5f1AeB75",
         "publicKeyHex":"0x020ee3388dd3db4e3e4da39f2fdc27113161d33579c4d0350b5672bcb654ceff98"
      }
   ],
   "updated":null,
   "@context":"https://www.w3.org/ns/did/v1"
}

Additional Resources on DIDs

• W3C DID Documentation

• Energy Web - DID Explainer

• EW’s DID Library is open-source

• Energy Web - “Digging Deeper into Self-sovereign Identity and Access Management” on Medium

• W3C, "A Primer for Decentralized Identifiers"

• “Everything you need to know about Self-Sovereign Identity and Decentralized Identifiers” (3 part series) on Medium

• Chapter 4: Cryptography · GitBook

Medium Series on private keys and their relevance in the Ethereum Network:

• Part One: Understanding Private Keys

• Part Two: Turning Random Numbers into an Ethereum Address

• Part Three: Creating and Signing Ethereum Transactions

MetaMask glossary on key terms:

• Public Key

• Private Key

The Marketplace App is a decentralized desktop application which provides an intuitive interface for the general community with limited technical background to easily participate in running worker nodes on their local machines. It also provides an interface to lift and lower EWTs. It supports Windows, MacOS, and Ubuntu systems.

A solution is a representation of a business case logic within the worker node networks. It is composed of the solution metadata and a Smart Flow definition file. The Smart Flow file is stored on a publicly available decentralized file system - IPFS (Interplanetary File System).

A solution group is a collection of solutions. Operators choose which solution group they opt to run and stake EWTs with. The worker node will run all active solutions under the subscribed solution group.

Smart Flows

A smart flow is a set of logical nodes that define a business use case. In EWX, smart flows are created and configured using Node RED which provides a browser-based flow editor that makes it easier for enterprises to wire together flows. However, contents of a Node RED node may be auto generated by any third party and be available as an independent, reusable node.

Smart flows are exported to JSON files and are stored on IPFS. Worker nodes of subscribed operators can automatically fetch these files and deploy into each respective instance.

An operator is an entity who participates in hosting worker nodes to execute business case logic in a network of worker nodes. The operator is represented by their dedicated EWX account.

An EWX account may be created using the publicly available Polkadot wallets. EWX is currently supported by below wallets:

1. Nova Wallet -

2. SubWallet -

The EWX account MUST NOT be used as a worker node account because they serve different purposes. The operator account nominates a worker node account which can represent the operator when submitting worker node results to EWX.

An EWX account can hold EWT for staking and claiming rewards.