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.

TECH STACK OVERVIEW

CONTENTS OVERVIEW

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 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.

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.

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.

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.

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 - https://novawallet.io/

2. SubWallet - https://www.subwallet.app/

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.

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

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 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.

The Energy Web Chain (EWC) is an open-source, public blockchain derived from Ethereum 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 decentralized identities (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 block in a blockchain 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 smart contracts 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 on-chain transactions. 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 Decentralized Identities (DIDs) that are created through EW-DOS's identity and access management library.

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

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

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

If you're not familiar with Smart Contracts, you can read Ethereum's introduction to smart contracts here.

You can see a list of repositories containing EW-DOS smart contracts here.

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.

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

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.

Energy Web has deployed OpenEthereum's Name Registry contract. This contract is identical to OpenEthereum's original contract, with the exception that it was made Ownable by Energy Web Foundation. Only Energy Web can reserve a name or drain funds from this contract.

There are two reasons for making this contract Ownable:

1. OpenEthereum's name registry might be needed for other OpenEthereum related system contracts later: e.g. service transaction checker, or auto updater.

2. We will have the official Ethereum Name Service system set up on the chain, so this contract is only needed for internal purposes and will not be used publicly.

The name registry is a placeholder for now. The contract can be found in our repo: https://github.com/energywebfoundation/ewc-system-contracts/tree/master/contracts/registry

Interacting with the Name Registry Contract

Contract Address and ABI

Callable Functions

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.

The Energy Web Chain (EWC) is a publicly-accessible-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.

System contracts are the Energy Web Chain's that implement OpenEthereum's protocols for .

Energy Web's smart contracts are open-sourced, and you can see them on github

• - manage validator permissioning and behavior

• - manages validator block rewards

• - manages the initial disbursement of pre-mined energy web tokens

Implementing Client Protocol

System contracts are the Energy Web Chain’s smart contracts that implement . These protocols determine what actions can be taken on the network.

In order to adhere to the expected protocol, the Energy Web Chain’s system contracts must implement the interfaces that are expected by the AuRa consensus engine, so that it can conform to the client’s protocols.

Let’s take contract as an example.

The OpenEthereum documentation specifies that “A simple validator contract has to have the following interface”

You can see that this smart contract implements all of the functions of the Validator-Set protocol interface that was specified above.

Energy Web System Contracts

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

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.

Below is the sample generic sequence diagram describing the process from fetching data from each respective business case provider system, processing the data, submitting the result to EWX, calculating the consensus, and forwarding the results back to the BC system. Business Case (BC) providers are those entities who have access to EWX Launchpad and define the logic of the Smart Flows.

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

Business case

Today worker nodes are implemented as independent off-chain computing nodes that communicate with a smart contract deployed on the Energy Web Chain. This approach is effective, but it is complex and labor-intensive to configure custom business logic, synchronize nodes, and apply appropriate governance such as defining eligibility requirements and service level agreements that worker nodes must adhere to. A more efficient solution is to implement worker nodes within a common environment where they can run independently but follow a unified set of rules. That is where Energy Wb X comes in.

In contrast to the Energy Web Chain, which is Ethereum based, Energy Web X is built with substrate technology. Its sole purpose is to coordinate, secure and make public the results of work performed by worker node networks.

View the EWX architecture

Current Challenges

Worker nodes in the Energy Web ecosystem today function as independent off-chain computing units. They communicate with smart contracts deployed on the Energy Web Chain (EWC), which uses Ethereum-based technology. While this design has been effective in facilitating off-chain computation, it has significant challenges:

1. Complexity in Configuration: Setting up custom business logic for each independent worker node requires substantial effort, making the process cumbersome for enterprises.

2. Synchronization: Ensuring consistent operation and data synchronization between worker nodes and the smart contracts is labor-intensive.

3. Governance Enforcement: Defining and monitoring adherence to eligibility requirements, service-level agreements (SLAs), and reward mechanisms require careful management, adding to operational overhead.

Energy Web X as a Unified Solution

Energy Web X addresses these challenges by providing a substrate-based platform that integrates worker nodes into a unified environment. Substrate’s modular framework allows for highly customizable blockchains tailored to specific use cases, making Energy Web X a robust alternative to the Ethereum-based EWC.

Key Benefits:

• Streamlined Governance: Worker nodes operating under Energy Web X follow predefined governance rules encapsulated in “pallets.” These pallets function like enhanced smart contracts, offering more flexibility and power to manage worker nodes collectively.

• Enhanced Efficiency: A common environment reduces the complexity of synchronization and management, enabling easier scalability for enterprises.

• Interoperability with EWC: Energy Web X is designed to complement EWC, enabling seamless interaction where worker nodes can migrate (“lift”) to Energy Web X for enhanced capabilities and revert (“lower”) to EWC as needed.

Worker Nodes in Energy Web X

Worker nodes remain essential as software packages operated by individuals or businesses. Energy Web X introduces features to make this ecosystem more appealing:

• Reward Systems: To attract operators, worker nodes are incentivized through rewards in EWT (Energy Web Token). These reward mechanisms can be customized based on performance metrics, such as quality and timeliness of work.

• Stake-Based Trust: To run a trusted worker node, operators are required to lock EWT, aligning their incentives with network reliability. This ensures that only committed entities contribute to critical computations.

More on Worker Nodes

Role of Solutions and Solution Groups

Energy Web X structures worker nodes into solutions and solution groups, providing a hierarchical approach to management:

• Solutions: Represent specific business applications or use cases powered by worker nodes.

• Solution Groups: Group similar solutions together and define shared governance rules, including operational criteria and reward structures.

Configurable Lifetimes and Rewards: Solution groups provide flexibility:

• Their lifetimes can be predefined but extended based on evolving business needs.

• Reward mechanisms can be dynamically adjusted to incentivize participation and ensure the alignment of worker nodes with enterprise objectives.

On-Chain Consensus for Off-Chain Work

The configurations within solutions and solution groups dictate how worker node outputs are validated on-chain:

• Eligibility Requirements: Define who can participate.

• Service-Level Agreements: Set performance benchmarks for the worker nodes.

• Consensus Mechanisms: Establish thresholds for accepting the results of off-chain computations as correct.

By formalizing these parameters, Energy Web X ensures:

• Accuracy: Only valid results from worker nodes are anchored on the blockchain.

• Trust: Enterprises and stakeholders can rely on a secure and tamper-resistant consensus process.

This structured and dynamic system makes Energy Web X a powerful platform for managing distributed worker nodes while reducing operational complexity and enhancing enterprise scalability.

The Balances Pallet is a core module in the Polkadot SDK, responsible for managing token balances, enabling secure transfers, and supporting the blockchain’s economic operations. It provides robust mechanisms for balance management, transaction fees, and account lifecycle, ensuring a stable and efficient economic framework for Substrate-based blockchains.

Key functionalities:

• Account Balances Management: Maintains and tracks balances for all accounts, divided into free balance (spendable) and reserved balance (locked for specific purposes).

• Token Transfers: Enables secure token transfers between accounts with features like keep-alive transfers to prevent accounts from being reaped.

• Locks and Imbalances: Introduces runtime locks to temporarily restrict access to balances during specific operations (e.g., governance or staking) and handles imbalances through secure issuance or burning of tokens to maintain economic integrity across the system.

The Worker Node Pallet provides essential functionalities for managing solution groups, solutions, and votes as outcomes of off-chain computation, along with mechanisms to ensure fair reward distribution.

Key functionalities:

• Solution Group Management: Enables registrars to create, register, and deregister solution groups. Funds are locked upon registration and become available for distribution once specific criteria are met.

• Solution Management: Each solution is an off-chain business unit requiring computation by worker nodes, with consensus achieved on computed results to ensure their validity.

• Operators and Workers: Operators join solution groups by locking their tokens, subscribing to groups, and running worker nodes. These nodes process and compute solutions off-chain and participate in on-chain voting to reach consensus on results, which in turn determines rewards eligibility.

• Reward Calculation & Distribution: Manages reward calculations for each solution group, including the handling of reward periods for distribution.

• On-Chain Voting (Consensus): Implements an on-chain voting system to reach consensus on solution results computed off-chain and submitted by workers. The consensus outcome determines eligibility for operator rewards, aligned with each solution group’s configuration to ensure fair reward distribution.

The Proxy Pallet is a versatile module in the Polkadot SDK that facilitates secure delegation of account operations. It allows users to authorize other accounts, called proxies, to perform specific actions on their behalf. This feature enables enhanced account management, operational flexibility, and secure delegation, particularly beneficial in multi-sig setups and automation scenarios.

Key functionalities:

• Account Delegation: Enables accounts to delegate specific operations to proxy accounts with configurable levels of permissions and supports use cases such as transaction signing, staking operations, and runtime-specific actions.

• Proxy Types and Permissions: Defines distinct proxy types to grant granular permissions, ensuring proxies can only execute authorized actions.

• Time-Limited and Announced Proxies: Introduces time-limited proxies that automatically expire after a predefined duration, enhancing security. It also implements delayed announcements for high-risk actions, allowing users to monitor and cancel actions if necessary.

• Security and Revocation: Includes mechanisms for account owners to revoke proxy permissions at any time, ensuring full control while it protects against unauthorized actions through runtime checks and adherence to defined proxy types.

The system architecture of a validator node on the Energy Web Chain is made up of two components:

1. The OpenEthereum Client

2. Telemetry monitoring system

Together these two components allow validators to run a local node of the chain, validate transactions, seal blocks, and monitor validator behavior and metrics.

OpenEthereum Client

A client is software that allows you to run a local node on your machine and interact directly with the blockchain. Every validator must run a full node in order to participate in validation.

Remember that the Energy Web Chain is derived from the Ethereum blockchain. Because of this we use an Ethereum client to connect with the chain called OpenEthereum. Anyone can create a client, as long as it implements the protocols laid out in Ethereum’s yellow paper, and there are a number of Ethereum clients to choose from.

Energy Web uses the OpenEthereum client because it supports the Authority Roundtable (AuRa), which is a consensus algorithm specifically for Proof-ofAuthority blockchains. OpenEthereum allows validators to connect to the chain, collect transactions and seal blocks according the AuRa consensus algorithm.

To read more about OpenEthereum, you can visit their wiki.

To read more about Ethereum clients, see the Ethereum documentation.

Telemetry Monitoring system

The monitoring system collects comprehensive, real-time data and metrics on validator performance and provides a user interface for viewing the data. It is important to gather as much data about the validator nodes as possible in order to ensure a secure and performant blockchain. To do so, we rely on well established industry solutions to transfer these metrics off the validator node to protect the sensitive nature of the data.

The use of the telemetry monitoring system is opt-in. Validators can disable it if they have their own monitoring system in place that allows for real time tracking of all relevant metrics.

Telemetry Architecture

There are four components involved in the data collection process:

• OpenEthereum client - monitors validator node behavior

• Telegraf: open-source server agent that collects data from the OpenEthereum client

• InfluxDB - open source database that stores the data collected from Telegraf

• Grafana - data visualization tool that queries the InfluxDB for data and provides graphical interface for data visualization

All components are run in separate docker containers managed by docker compose. For additional information on docker visit: https://docs.docker.com/ and https://docs.docker.com/compose/.

Data Collection Process Overview

1. The OpenEthereum client collects data on the validator node. Collected data includes:

   • CPU usage

   • Memory usage

   • Disk usage

   • Number of connected peers

   • List of visible P2P peers

   • Current block

   • Network latency to 3 different and major locations (e.g. cloudflare, google, amazon)

   • Network throughput

   • Network error rate

   • Number of SSH keys

   • Service status for SSH, docker and the parity container

   • SHA256 hashes of key system components/binaries

   • Current chain specification file (or hash)

2. Telegraf collects relevant metrics from the host machine and the custom-built OpenEthereum metrics collector. The metrics collector allows Telegraf to receive the metrics from the OpenEthereum client

3. The collected metrics are stored in an InfluxDB database and can be visualized using Grafana

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

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

Additional Resources:

• ****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

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

Learn about the EWC Governance and the role of Validators in depth in our .

The block explorer interface provides the most important on-chain information about blocks, transactions, accounts and Energy Web Token (EWT). 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: https://volta-explorer.energyweb.org/

• Main Network Block Explorer: https://explorer.energyweb.org/

Block Explorer Overview

Blocks

• 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

• Validated - transaction details for all validated transactions

  • Transaction address

  • Status

  • Block Number

  • Nonce

  • Transaction fee

  • Transaction Speed

  • Raw input

  • Gas

  • Internal Transactions

• Pending - transaction details for all pending transactions

  • Transaction address

  • Nonce

  • Gas limit

  • Internal Transactions

Accounts

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

• All

• Bridged from Ethereum

• Bridged from Binance Smart Chain

APIs

• GraphQL: GraphQL interface which you can use to query specific information that are on chain: https://explorer.energyweb.org/graphiql. To find out more about the possible queries visit: https://github.com/ConsenSys/ethql#query-handbook

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

Callable functions

Events you can listen to, in addition to report events:

event ChangeFinalized(address[] validatorSet);
event NewRelay(address indexed relay);

Interaction with Relay Contract

Callable functions

Events you can listen to:

event NewRelayed(address indexed old, address indexed current);

Each set of worker nodes deployed by Energy Web, Energy Web customers of any energy enterprise is governed and anchored to unique pallets on Energy Web X(in traditional Web 3 language a pallet on a substrate-based blockchain is similar to a smart contract on an EVM but more powerful and flexible). Whit this architecture in place, Energy Web has. scalable way to launch worker nodes.

Energy Web X’s purpose is to introduce new technical capabilities, leverage and complement the existing Energy Web Chain. To maximize the security of every Energy Web solution using worker nodes, EWT wis required to interact with worker nodes and Energy Web X that can be “lifted” from EWC to EWX and “lowered” back to EWC from EWX.

Worker Nodes are sofware packages that need to be run by individuals and/or businesses. In order to attract entities to run worker nodes, enterprises need to include rewards that pay worker node operator for performing their work. All worker node rewards are paid out in EWT.

In order to become a trusted part and run worker nodes, individuals and/or businesses require to lock EWT. Enterprises launching worker node networks can configure different thresholds and award schedules at their discretion.

In Energy Web X, solutions represent business applications or use cases that are implemented through worker node networks. These solutions can be grouped into solution groups, which define shared governance parameters, reward structures, and operational criteria. Solution groups are crucial for aligning the behavior of worker nodes across similar or related solutions.

The lifetime of a solution group is configurable, allowing enterprises to set specific timeframes during which worker nodes can participate and earn rewards. Solution groups also allow flexibility: their lifetimes can be extended to accommodate ongoing or evolving business needs, and their reward structures can be raised to incentivize higher performance or attract more participants. This dynamic lifetime and reward management ensure that worker nodes are continually aligned with the goals of the enterprises that rely on them.

Solutions and solution groups establish the configuration that governs how worker node submissions are evaluated and consensus is reached on-chain. This configuration includes eligibility requirements, service-level expectations, and thresholds for agreeing on the correctness of off-chain computed results. By leveraging these configurable parameters, Energy Web X ensures a robust and secure consensus mechanism that validates and anchors the outputs of decentralized off-chain computations. This process is critical to maintaining trust and accuracy across all solutions powered by worker nodes.

The Assets Pallet is a core component in the Polkadot SDK that provides comprehensive tools for managing and interacting with fungible token assets. This pallet enables the creation, transfer, and governance of assets on-chain, supporting decentralized ecosystems with robust asset functionality.

Key functionalities:

• Asset Creation and Registration: Allows users or entities to create new fungible assets with customizable properties such as total supply, name, and metadata. It also enforces administrative roles for managing the lifecycle of assets, including minting and burning.

• Asset Transfer and Balances Management: Enables secure and efficient transfer of assets between accounts and tracks account balances for each asset type, with configurable rules for minimum balances and dust handling.

• Minting and Burning Mechanisms: Provides authorized administrators the ability to mint new tokens to increase supply or burn tokens to reduce supply. It also ensures precise control over asset supply and its distribution across holders.

• Permissioned Operations: Supports a robust permissions system to define administrative roles such as asset owners, issuers, and freezers.

The Multisig Pallet in the Polkadot SDK provides a robust mechanism for multi-signature account management, enabling secure and coordinated actions among multiple participants. This pallet is integral for collaborative decision-making and securing high-value operations in decentralized ecosystems.

Key functionalities:

• Creation of Multisig Agreements: Facilitates the creation of multi signature agreements among multiple accounts with a defined threshold of required approvals. Supports both single-use and reusable multi signature setups for flexibility in different use cases.

• Threshold-Based Execution: Allows execution of transactions once the required threshold of signatures has been collected and ensures that no action is performed unless the predefined consensus is reached among signatories.

• Time-Locked Approvals: Introduces optional time-locks for multisig operations, giving signatories a limited window to approve or reject a proposal and ensures timely decision-making and reduces risks associated with prolonged inactivity.

The XCM Pallet is a critical module in the Polkadot SDK that facilitates Cross-Consensus Messaging (XCM), enabling secure and interoperable communication between different chains. This pallet is fundamental to Polkadot’s interoperability framework, allowing Parachains, relay chains, and other consensus systems to exchange messages and assets seamlessly.

Key functionalities:

• Cross-Consensus Communication: Implements a universal messaging protocol for interaction between different consensus systems and allows Parachains and relay chains to send and receive messages reliably, forming the backbone of Polkadot’s interoperability.

• Asset Transfer and Management: Supports transferring assets, such as tokens or NFTs, across chains using the XCM protocol.

• Instruction Execution: Provides an instruction set for executing operations on remote chains, such as account creation, staking, or governance participation.

• Fee Payment and Weight Management: Handles fee payments for executing XCM instructions, ensuring proper incentivization of involved parties.

The Scheduler Pallet provides a powerful framework for scheduling time-based and event-driven tasks within the runtime. It is integral for automating and orchestrating on-chain operations at specified block heights or based on dynamic triggers.

Key functionalities:

• Scheduled Task Management: Enables the scheduling of on-chain calls to execute at a specified block number or recurring intervals and supports delayed execution, enabling precise control over task timing for one-off or periodic operations.

• Flexible Call Dispatching: Allows scheduling of any callable extrinsics, making it versatile for automating runtime functionality. It also supports tasks requiring root-level permissions or limited by specific user-defined filters.

• Priority and Weight Control: Assigns priorities to scheduled tasks to determine execution order in case of conflicts and manages weight allocation to prevent overloading blocks with scheduled calls.

• Rescheduling and Cancellation: Provides mechanisms to modify or cancel scheduled tasks before execution.

The Offences Pallet is a critical component in the Substrate framework designed to detect, record, and manage misbehavior within the network. It ensures the integrity of the system by imposing penalties on validators and other actors who deviate from expected behavior, such as equivocation or inactivity.

Key functionalities:

• Misbehavior Detection: Facilitates the detection of offenses, such as double-signing or equivocation, leveraging integrated modules or external monitoring tools while it supports configurable offense types to adapt to specific network requirements and threat models.

• Offense Reporting and Recording: Provides a structured mechanism to report misbehavior, with offenses recorded on-chain for transparency and accountability. It also tracks offenders and their associated penalties to discourage repeated violations.

• Penalty Enforcement: Imposes penalties on validators or network participants based on the severity and frequency of their offenses. Penalties can include slashing, staking disqualifications, or temporary bans to maintain network integrity.

• Historical Tracking: Maintains a history of offenses and their resolutions to enable governance or runtime modules to make informed decisions regarding actors’ reliability. Supports configurable retention policies to manage storage efficiently while preserving essential historical data.

The Avn Pallet provides functionality that is common for other pallets such as handling offchain worker validations, managing a list of validator accounts and their signing keys.

Key functionalities:

• Validator List: Maintains a list of active validators, each represented by an address and a cryptographic key.

• Bridge Contract Address: Stores the address of an associated bridge contract on the Ethereum network.

• Off-Chain Worker Integration: Provides mechanisms for off-chain workers to run only once per block to avoid duplicate operations. Includes functionality for interacting with external services for retrieving finalized blocks and requesting signatures.

• Signature Verification: Offers tools to validate Ethereum ECDSA signatures, ensuring that signatures are produced by known validators.

The Preimages Pallet is a specialized component in the Substrate runtime that facilitates the storage, retrieval, and management of large data blobs (preimages) on-chain. It is particularly useful for governance and other modules requiring access to detailed proposals or large datasets while minimizing storage costs.

Key functionalities:

• Efficient Storage of Preimages: Allows users to submit and store large preimage data off-chain initially, ensuring cost-effective on-chain storage.

• On-Demand Retrieval: Enables on-chain modules, such as governance proposals, to reference and retrieve preimages only when they need to be executed or evaluated.

• Preimage Validation: Includes a framework to validate and verify the integrity of preimages against hashes before use and ensures that the preimage data corresponds accurately to its referenced hash.

• Access and Ownership Control: Supports fine-grained access controls, ensuring only authorized entities can submit or clear preimages and allows multiple modules and users to leverage preimages securely without conflict.

The Eth-Bridge Pallet is a component responsible for facilitating interactions between a Substrate-based blockchain and an Ethereum-based network. It implements the BridgeInterface and provides functionality for publishing transactions and generating lower proofs. This enables other pallets that implement BridgeInterfaceNotification to execute functions on the Ethereum-based smart contract or request proofs for token operations.

Key functionalities:

• Transaction Publishing and Management: Accepts and processes transaction requests from external pallets, handling them sequentially to ensure that they are executed in the order they are received. Publishes transactions by packaging and encoding them to be compatible with Ethereum, complete with timestamps and unique transaction IDs to track and verify their status.

• Consensus and Confirmation Collection: Manages the collection of ECDSA confirmations from authors to prove consensus for a transaction, ensuring that all required signatures are gathered before submission. Utilizes a confirmation system where authors can add their confirmations until the required threshold is met, after which the transaction is ready to be dispatched to Ethereum.

• Dispatching Transactions to Ethereum: Appoints an author responsible for sending a transaction to Ethereum once sufficient confirmations have been collected.

• On-Chain and Off-Chain Coordination: Integrates with off-chain workers (OCWs) to monitor unresolved transactions and prompt authors to act as needed. It also alerts the originating pallet with the outcome of a transaction through the BridgeInterfaceNotification callback, enabling state commitment or rollback based on the results.

The Token-Manager Pallet is designed for managing tokens and handling token operations within a Substrate-based blockchain. This pallet facilitates various features, including secure token transfers, scheduling of token “lowering” operations to Ethereum (tier1), and interaction with external token contracts. It also enables the governance of token-related actions through nonces and proofs, ensuring a seamless operation between blockchain tiers.

Key functionalities:

• Token Balance Management: Tracks the balances of individual accounts for different tokens. This allows the management and querying of token balances by specifying the token ID and account ID. Each account’s nonce is tracked, representing the number of transfers conducted, ensuring the integrity of transaction sequences.

• Lowering Operations: Supports “lowering” tokens from tier2 to tier1, interfacing with an Ethereum contract. This operation can be executed directly or scheduled for later execution. Lowering operations require confirmations and signatures, with proof requirements verified before sending transactions, ensuring secure, authenticated transfers.

• Proof and Transaction Management: Handles proofs for token transfers, including the ability to regenerate proofs for pending or failed lower transactions. Stores and retrieves data about lower transactions in various states: ready-to-claim, pending, and failed, providing robust tracking and error recovery mechanisms.

The Ethereum-events pallet handles the management of Ethereum events and their processing within the blockchain environment. It supports tracking event submissions, validation, and challenges while providing secure mechanisms for event processing and recording.

Key functionalities:

• Event Tracking and Management: Efficiently tracks and manages Ethereum events, including ingress counters, to maintain order and ensure unique identification of events.

• Event Validation Pipeline: Handles the lifecycle of Ethereum events from submission to processing, with mechanisms to mark events as unchecked, pending, or processed.

• Challenge and Validation System: Allows validators to challenge event validity, enforcing quorum-based decision-making for robust and decentralized validation.

• Event Integrity Protection: Ensures that events cannot be processed more than once, maintaining a consistent and secure state in the blockchain’s event records.

This section provides step by step instruction on how to use the Marketplace app.

Download and install the app now to get started.

The Marketplace App is a decentralized desktop application which provides an intuitive interface for the general community having limited technical background to easily participate in running worker nodes on their local machines.

It supports Windows, MacOS, and Ubuntu systems.

Download and Installation

Download and install the Marketplace app on your machine from the download links provided in the official EWX Website.

Below are some examples of how a worker node can actually work.

Prerequisites

Before using Ledger on the Marketplace App, the Polkadot app needs to be installed in the hardware wallet device. To do so, open the Ledger Live application in your computer and go to "My Ledger" section of the sidebar. Make sure your Ledger device is connected to the computer and unlocked when doing this.

In the "App Catalog" section, search for the Polkadot app and install it.

Confirm that the Polkadot app is correctly installed.

Now the device is ready to interact with the Polkadot chain, including the EWX chain.

Ledger Live app does not display EWX account and its balance as it is not yet supported. However, your EWX account and its balance may be confirmed on Polkadot Explorer or in the Marketplace App itself.

The Marketplace App directly communicates with your Ledger device without the need to use Ledger Live as long as Polkadot is installed.

Connect Operator Account using Ledger Device

The first step to use Ledger with the EWX Marketplace application is to connect your hardware wallet. In this case, the process is very similar to connecting any other browser or mobile-based wallet. The user needs to click on the “Connect” button that appears both in the top-right corner of the screen.

A dialog will pop up, and the user can choose its preferred method to connect the wallet - in this case, choose Ledger.

The user will be prompted to continue the connection process in the hardware device.

By default, the Ledger device will look like this when unlocked:

After starting the connection process, the user needs to open the Polkadot application on the Ledger device.

After opening the Polkadot app (pressing both buttons at the same time), this will appear on the device:

That means there is an ongoing operation that needs to approve. To do that, press the right button until the “Approve” screen is displayed.

After approval, below shows the confirmation that the user is connected to the Ledger account successfully.

Executing a transaction

The process is very similar to the browser-based wallet, and applies to all the different transactions available on the app: lowering, sign up as operator, subscribe, link worker account, unsubscribe, top-up stake and claim rewards. After initiating a transaction, for example - lowering, the user will see a ‘Pending confirmation’ screen. The user needs to confirm the operation using the same method used to connect to the wallet.

When this screen appears, open the Polkadot account on the Ledger device, just like before.

After opening the app, review and approve the operation.

The details of the transaction are displayed on the device just like on the next sample screens.

Proceed to approve the operation.

The progress screen on the app immediately changes, displaying the “Executing transaction” title. At this point, the transaction has been sent and is being processed on the blockchain.

If the transaction finished successfully, the success screen and the corresponding tx hash are displayed. This concludes the entire transaction process.

What are Worker Nodes?

To learn more about worker nodes, see Worker Nodes and Worker Node Networks.

Types of Worker Nodes

Currently, EWF provides two (2) implementations of Worker Nodes:

1. 🖥️ Marketplace Desktop Application

2. 🗄️ Server-based Worker Nodes

How does a Worker Node work?

In a nutshell, a Worker Node is a single processing unit in a network of nodes which has the ability to execute enterprise calculations, and submit votes to derive consensus-based, transparent results.

A general worker node typically involves below processes:

1. Sync operator subscriptions

2. Download and install solutions

3. Run solutions and cast votes

Sync operator subscriptions

The worker node periodically syncs on-chain data for operator subscriptions. The syncing process informs the worker node that either a set of solutions is available to be installed (new subscriptions) or uninstalled (unsubscription or subscription expiry).

Download and install solutions

Solution flows, which are currently in the form of Node RED flow JSON files, contain the actual detailed specifications and implementation of a specific business use-case. These are stored in a decentralized file storage called IPFS. The EWX registry stores the CID of the flow along with the rest of the solution metadata. These are stored locally in the worker node during the syncing process.

When the worker node is enabled to run the flows, it downloads the actual Node RED flow JSON files from IPFS using the CID. Subsequently, the flow files are installed in the local Node RED server bundled in the worker node itself.

Run solutions and cast votes

An enterprise use-case is considered executing when the flow files get installed and are running in the Node RED server of the worker node. Each solution flow determines when and how the solution flow produces a result, and when to use the result to cast a vote.

Casting a vote simply follows below steps:

1. A solution is triggered to process the flow

2. The flow gets executed to produce a result

3. The result is transformed in to a Merkle Tree Root Hash

4. The flow requests for the worker to submit the hash as a vote

5. The worker enqueues the voting request

6. The worker submits the vote to EWX

Why does the result gets transformed into a Merkle Tree Root Hash? EWX nor the Worker Node never stores raw or calculated data unless the solution flow created by the enterprise themselves are designed and approved to do so after an extensive audit. EWX as a chain only stores the result hash for optimum performance and data security.

The Merkle Tree Root Hash can represent the actual calculated data as a single, unique vote. However, an adversary can never reverse-engineer the hash to derive the calculated or raw data. This ensures that the entire EWX ecosystem is secure and robust.

Please refer to potential enterprise use-cases for some examples of what a worker node can actually do.

Server-based worker node accounts can be created manually or generated from Launchpad. In any case, below are the steps to guide you on how to setup your account.

Types of EWX Accounts

1. Operator Account - an EWX account which serves as the main account of the operator to be used in EWT management (lifting/lowering), subscriptions, rewards, etc

2. Worker Node Account - an EWX account with the sole purpose of casting votes on behalf of the operator

Prerequisites

1. Marketplace Desktop App - download the latest version from https://www.energywebx.com/

2. Public Address of the Worker Node Account - the worker node account must already be created from Launchpad or from any wallet which supports EWX

3. Operator Account with enough EWT balance - create an account from any wallet which supports EWX and make sure to lift enough EWT for signing-up as operator, linking worker account to operator, opting-in to solution groups, etc

Step by step guide to setup your worker node

Sign-up as operator

To sign-up as an operator, you must prepare your "operator" EWX account. This account is just a normal account created on EWX network via any supported Polkadot wallet. For now, we suggest to use Sub Wallet or Nova Wallet. Make sure to always keep your seedphrase copied and secured elsewhere. In addition, please ensure that your operator account has sufficient EWT balance to proceed with any on-chain transaction.

Please follow below steps to sign-up as an operator.

1. Connect your operator account
2. Approve the connection request in your wallet
3. Once connected, you will be redirected to the Discover page and you will see your "operator" public address in the upper right corner of the screen as highlighted below
4. Browse through any solution group and click on it. You will be redirected to its details page. Then, click on the "Opt-in" button
5. The sign-up operator dialog gets displayed. Input your details accordingly and approve the transaction in your wallet.

Subscribe to solution group

After the signing-up as an operator, you will be prompted to stake tokens to your selected solution group from the Discover page. Stake your desired amount and approve the transaction in your wallet.

Set worker node account

After subscribing to the solution group, you will be prompted whether to participate in a worker node network.

Link worker to operator

After setting your worker node public address above, you will be prompted to link your worker node account to your operator account.

The Operating Envelopes Partitioning is the most crucial step in the overall operating envelope passthrough process.

An "operating envelope passthrough" refers to a mechanism that allows for adjustments in the operational limits or envelopes of generating units or electrical systems. These envelopes define the safe operating conditions for various generation assets and network elements, helping ensure reliability and stability in the energy supply.

When unforeseen circumstances arise, such as significant changes in demand, generation availability, or system disturbances, the operating envelope can be exceeded. The passthrough mechanism enables market operators to make necessary adjustments to account for these situations, ensuring that the operation of the market remains secure and efficient. This process is vital for managing risks and maintaining grid reliability amidst changing conditions.

The process starts when the DNSP/DSO sends their operating envelope which needs to be partitioned accordingly, and forwarded to their respective aggregators. The partitioning process needs to take place in a fully trust-less and secured environment where data are pseudo-anonymized to protect aggregators' business interests.

OEP Solution

The OEP solution aims to test the above business case. Below are the steps which constitute the OEP solution flow:

1. Fetch OEP request from the operating envelope sender every 30 minutes

2. Parse the operating envelope into JSON Object

4. Partition the operating envelope according to the aggregator using the NMI to aggregator mapping

6. Submit the root hash to EWX as a vote by initiating the EWX Marketplace App Integration node

Here is a on how to deploy server-based worker nodes via .

Lifting & Lowering

What is lifting?

Lifting is the process of migrating EWTs from Energy Web Chain (EWC) to Energy Web X (EWX).

How long does it take to reflect my lifted EWT to my account?

Lifted tokens take approximately 30 minutes to reflect in your EWX account after successful transaction from the Marketplace app.

What is lowering?

Lowering is the process of migrating EWTs from Energy Web X (EWX) to Energy Web Chain (EWC).

How long does it take to reflect my lowered EWT to my account?

Lowered tokens take approximately 24 hours to reflect in your EWC account after successful transaction from the Marketplace app.

A ZEL Request refers to a "Zero Export Limit" request. This request is made by generators or dispatchable assets to set their output to zero, often indicating that they are not able to inject power into the grid for a specific reason.

ZEL Requests can be relevant in several scenarios, such as:

1. Maintenance: When maintenance is being conducted on a generator, it may need to curtail its output temporarily.

2. Technical Issues: If there are technical problems that prevent a generator from operating safely or effectively, a ZEL Request signals that they will not produce energy.

3. Market Conditions: During high levels of generation leading to potential oversupply in the grid, generators might reduce output to maintain stability.

Market operators use these requests to manage the overall balance of the electricity supply and demand, ensuring system security and reliability.

The process starts when a retailer sends their ZEL request which needs to be partitioned accordingly, and forwarded to their respective aggregators. The partitioning process needs to take place in a fully trust-less and secured environment where data are pseudo-anonymized to protect aggregators' business interests.

ZEL Request Partitioniong Solution

The ZEL Request Partitioning solution aims to test the above business case. Below are the steps which constitute its solution flow:

1. Fetch ZEL request from the request sender every 30 minutes

2. Parse the request into JSON Object

3. Fetch NMI to aggregator mapping from the NMI Registry. The NMI Registry is a backend API service which simply contains the mapping between NMI and aggregator.

4. Partition the ZEL request according to the aggregator using the NMI to aggregator mapping

5. Generate the Merkle Tree root hash of the partitioned data

6. Submit the root hash to EWX as a vote by initiating the EWX Marketplace App Integration node

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 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 power plants and 2) customer demand for electricity is fixed 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 fixed and 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.

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.

Overview

The idea behind the design and architecture of Digital Spine is very simple: develop a trust-less, schema-agnostic data exchange between self-sovereign participants through a shared infrastructure, and enable consortia and/or industry-driven standards creation and adoption

The main goal of creating Digital Spine is to develop and deploy an open-source, globally applicable infrastructure that gives governments, regulators, and electricity market participants the ability to see, to interact with, to plan for, and to take full advantage of the flexibility and value which Distributed Energy Resources (such as electric vehicles and their charging stations, distributed solar systems, batteries, heat pumps, etc.) can provide.

High Level Design

The Digital Spine is mainly composed of 4 major systems:

• Self-sovereign Identities Hub (SSI-Hub): for DID-based verifiable credentials management

• Decentralized Data Hub Message Broker:

• Decentralized Data Hub Client Gateway:

• Participant System: