1 of 100

Energy Web Ecosystem and Technologies

Documentation Overview

Welcome to Energy Web's documentation site. You will find here information about all our solutions, technologies and services!

CONTENTS OVERVIEW

Core Concepts

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.

Energy Web Chain

Energy Web X

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.

Energy Web Tokens

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.

Token Lifting

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.

Token Lowering

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.

Worker Nodes and Worker Node Networks

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:

Server-based Worker Node
Marketplace Desktop Application

Server-based Worker Node

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.

Marketplace App (desktop-based)

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.

Worker Node Operator

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:

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.

Smart Flows and Groups

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.

Subscription

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

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.

Voting and Consensus

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.

Ethereum

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

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

Ethereum Fundamentals

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

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

Additional Resources

Transactions and Transaction Costs

Transactions

Transferring tokens between accounts
Deploying new smart contracts or accounts
Calling or Interacting with existing smart contracts

Once confirmed by the initiator, transactions can be in two states: pending and validated.

Pending Transactions

Notice that the transaction fee of a pending transaction is not determined yet and the "Block Number" is pending.

Validated Transactions

After a transaction is validated by a validator, it is added to a block. The block is designated by a block number, shown in the image below. Each block in a blockchain is made up of strictly ordered, consecutive, validated transactions.

Notice that the transaction fee of a validated transaction is no longer 0, it has a value in EWT.

Determining Transaction Cost

Every transaction that updates the chain has a transaction cost (transactions that are "read only" - meaning they do not update the state of the blockchain - do not have a cost.) It’s important to keep in mind that all transactions are not created equal: some are more computationally intensive than others, some are more urgent, some require greater degrees of privacy.

For example, an interaction with a smart contract that has complex functionality and many internal variables to store will be more computationally intensive than a simple transfer of tokens from one account to another.

As we’ll soon see, these differences from one transaction to the next can have an impact on ultimate transaction cost.

Transaction Cost Variables

There are three key variables that influence transaction cost:

1. Gas Cost

2. Gas Price

To derive a concrete fee requires a gas price as well. Every user that initiates a transaction chooses a gas price they are willing to pay for that particular transaction, at that particular time. It is essentially a bid the user makes to have their transaction validated and added to the chain. Users that want to have their transaction expedited, for example, might bid a higher gas price to ensure that it’s included as soon as possible in the next available block.

You can specify a gas price in a transaction through MetaMask:

3. Token Value

Finally, token value—usually expressed in a fiat currency equivalent—translates virtual transaction cost into ‘real’ transaction cost. And when token value varies widely, perhaps due to token market volatility, resulting transaction costs can vary too.

Calculating Transaction Cost

Using the three variables above, you can calculate the total transaction cost:

TxCost(unit:fiat$) = GasCost(unit:gas) x gasprice(unit:token/gas) x tokenvalue($/token)

Here’s how a fee would be calculated for a hypothetical transaction on the Energy Web Chain:

50,000 gas x 1 gwei per gas = 50,000 gwei = 0.00005 EWT

If the market price of EWT was $1 at the time of the transaction, this would equate to $0.00005 fee. If the price of EWT was $10, this would equate to $0.0005.

Gas Price, Gas Limits and Block Size

Gas cost, as we've mentioned, represents the computational effort that validators undertake when validating transactions and sealing blocks. The gas price is denominated in EWT, which is paid to the validators for their work.

Each validator may set their own minimum gas price that they are willing to accept in order to include a transaction in their blocks. Currently on the EWC, the default is 0.1 gwei, but the overall range is between 0.01 gwei and 1 gwei. When initiating a transaction on the EW Chain, you should make sure that your gas price is at least 0.01 gwei, and if you want to ensure that your transaction is executed within the next 1-3 blocks (roughly 15 seconds), you should choose a higher gas price.

Because each transaction uses different amounts of gas, the number of transactions that fit on a block will vary.

Each block on the Energy Web Chain has a size limit of 8 million units of gas. Hypothetically, a single extremely computationally intensive transaction could consume 8M gas, but a simple transfer of EWT between two accounts (the most basic transaction type there is) consumes 21,000 gas. This is why a simple metric of “transactions per second” is misleading; not all transactions are created equal in terms of complexity (i.e. gas cost.) If many of the transactions that are waiting in the memory pool have low computational cost, you can fit more transactions in the block. If they are larger, the block will hold less transactions.

Take a look at the details of a block added to the Energy Web Chain:

From this we can see that:

This block includes 43 transactions
The gas limit for the block is 8,000,000 (this limit remains constant for every block)
Only 1,553,623 units of gas were used to create the block (less than 20% of its limit)
If there were more transactions waiting in the memory pool to be added to the block, this block could have processed ~6,446,377 units worth of gas.

Keeping Public Blockchain Transaction Costs Low

The same three variables above that define transaction cost also present opportunities to manage those costs and keep them low.

1. Lean smart contracts can help keep gas costs down: App developers and other smart contract writers are incentivized to write lean, efficient code—writing smart contracts and initiating transactions that are as computationally efficient as possible.

2. Gas price bids should remain low on networks with high transaction capacity: Of the three variables that contribute to transaction costs, gas prices are arguably the most powerful lever, since the bidded prices are solely at the discretion of the user submitting a transaction to the network. For reasons we’ll explore below, in the absence of sustained block “congestion”, gas prices can remain low and stable.

3. “Just in time” gas price calculations mitigate some risks of token value volatility: For a variety of reasons, some token markets are more volatile than others. But just because a token’s value relative to a fiat currency changes, it doesn’t mean that transaction fees similarly change without warning. Users calibrate gas price bids at the time of the transaction, and thus will bid a denomination of tokens relative to the token’s value at the time. While it is possible that a past transaction fee could end up being significantly more or less expensive relative to current (or future) token value, transaction fees at the time they are incurred should remain relatively stable as a function of fiat currency.

If users desire a low-cost network, why do transaction costs rise in the first place?

So why would anyone bid a high price for any transaction? Shouldn’t transaction fees remain very low, as rational users consistently attempt to minimize their costs? In reality, transaction fees vary precisely because of competition among users to get transactions confirmed.

At any given moment there may be hundreds or thousands of transactions waiting to be confirmed and formally added to the blockchain. These pending transactions sit in a memory pool, or "mempool", where they are ultimately selected by validators (miners in the case of proof-of-work blockchains) to be included in a block. But each block has a finite gas limit, meaning not all transactions can be confirmed at once. As a result, validators will typically give preference to the most-lucrative (or expensive, depending on perspective) transactions in the mempool. Transactions with lower fees may end up having to wait for their transaction to get confirmed.

Ultimately, fees are about transaction prioritization. The higher the gas price you pay, the faster your transaction will be confirmed. If you don’t care about the amount of time it takes to confirm your transaction, you can offer a very low (or no) gas price. However, with this strategy you run the risk that your transaction never gets confirmed, and just sits in the mempool queue indefinitely.

Lessons from what we know about the Energy Web Chain

At the most basic level, transaction fees on the EWC are determined as a function of supply (e.g., computational capacity of the network, as defined by block gas limit and block speed / time) and demand (i.e., number of pending transactions). Volatility comes into the equation because supply, namely block time and block gas limit, is essentially fixed, whereas demand fluctuates as a function of the number of users and and the volume and complexity of transactions in the memory pool at any given time. Occasionally, transaction fee trends diverge from transaction volume, but generally the two are correlated.

Looking at historical data since the launch of the EWC in June 2019, it’s fair to say that transaction fees are usually extremely low - with average block utilization (in terms of gas consumption) around 15-20% the minimum gas price of 0.1 gwei is almost always sufficient to ensure a transaction is validated within 2 blocks. Based on the historical market price of EWT, transaction fees expressed in terms of fiat currency are typically in the range of $0.0001 (or less).

Additional Resources

Ethereum documentation on

Decentralized Identifiers (DIDs)

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.

How are DIDs Created?

Public-Private Key Pairs

DID Format

DID Documents

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

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

EWC ECOSYSTEM

Energy Web Chain

The blockchain performs three key functions in EW-DOS:

Facilitates on-chain verification and transactions between parties
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:

Persistence on the Energy Web Chain

The Energy Web Chain stores the following information:

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.

System Architecture

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

System Components

Proof-of-Authority Consensus Mechanism

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 Energy Web Chain uses the Proof-of-Authority (PoA) consensus mechanism.

System Contracts

Implementing Client Protocol

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.

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

[
    {
        "constant": false,
        "inputs": [],
        "name": "finalizeChange",
        "outputs": [],
        "payable": false,
        "type": "function"
    },
    {
        "constant": true,
        "inputs": [],
        "name": "getValidators",
        "outputs": [
            {
                "name": "_validators",
                "type": "address[]"
            }
        ],
        "payable": false,
        "type": "function"
    },
    {
        "anonymous": false,
        "inputs": [
            {
                "indexed": true,
                "name": "_parent_hash",
                "type": "bytes32"
            },
            {
                "indexed": false,
                "name": "_new_set",
                "type": "address[]"
            }
        ],
        "name": "InitiateChange",
        "type": "event"
    }
]

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

pragma solidity 0.5.8;

import "../misc/Ownable.sol";
import "../interfaces/IValidatorSetRelay.sol";
import "../interfaces/IValidatorSet.sol";
import "../interfaces/IValidatorSetRelayed.sol";


/// @title Validator Set Relay contract
/// @notice This owned contract is present in the chainspec file. The Relay contract
/// relays the function calls to a logic contract called Relayed for upgradeability
contract ValidatorSetRelay is IValidatorSet, IValidatorSetRelay, Ownable {

    /// System address, used by the block sealer
    /// Not constant cause it is changed for testing
    address public systemAddress = 0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE;
    
    /// Address of the inner validator set contract
    IValidatorSetRelayed public relayedSet;

    /// Emitted in case a new Relayed contract is set
    event NewRelayed(address indexed old, address indexed current);

    modifier nonDefaultAddress(address _address) {
        require(_address != address(0), "Address cannot be 0x0");
        _;
    }

    modifier onlySystem() {
        require(msg.sender == systemAddress, "Sender is not system");
        _;
    }

    modifier onlyRelayed() {
        require(msg.sender == address(relayedSet), "Sender is not the Relayed contract");
        _;
    }

    constructor(address _owner, address _relayedSet)
        public
    {
        _transferOwnership(_owner);
        _setRelayed(_relayedSet);
    }

    /// @notice This function is used by the Relayed logic contract
    /// to iniate a change in the active validator set
    /// @dev emits `InitiateChange` which is listened by the Parity client
    /// @param _parentHash Blockhash of the parent block
    /// @param _newSet List of addresses of the desired active validator set
    /// @return True if event was emitted
    function callbackInitiateChange(bytes32 _parentHash, address[] calldata _newSet)
        external
        onlyRelayed
        returns (bool)
    {
        emit InitiateChange(_parentHash, _newSet);
        return true;
    }

    /// @notice Finalizes changes of the active validator set.
    /// Called by SYSTEM
    function finalizeChange()
        external
        onlySystem
    {
        relayedSet.finalizeChange();
    }

    /// @notice This function is used by validators to submit Benign reports
    /// on other validators. Can only be called by the validator who submits
    /// the report
    /// @dev emits `ReportedBenign` event in the Relayed logic contract
    /// @param _validator The validator to report
    /// @param _blockNumber The blocknumber to report on
    function reportBenign(address _validator, uint256 _blockNumber)
        external
    {
        relayedSet.reportBenign(
            msg.sender,
            _validator,
            _blockNumber
        );
    }

    /// @notice This function is used by validators to submit Malicious reports
    /// on other validators. Can only be called by the validator who submits
    /// the report
    /// @dev emits `ReportedMalicious` event in the Relayed logic contract
    /// @param _validator The validator to report
    /// @param _blockNumber The blocknumber to report on
    /// @param _proof Proof to submit. Right now it is not used for anything
    function reportMalicious(address _validator, uint256 _blockNumber, bytes calldata _proof)
        external
    {
        relayedSet.reportMalicious(
            msg.sender,
            _validator,
            _blockNumber,
            _proof
        );
    }

    /// @notice Sets the Relayed logic contract address. Only callable by the owner.
    /// The address is assumed to belong to a contract that implements the
    /// `IValidatorSetRelayed` interface
    /// @param _relayedSet The contract address
    function setRelayed(address _relayedSet)
        external
        onlyOwner
    {
        _setRelayed(_relayedSet);
    }

    /// @notice Returns the currently active validators
    /// @return The list of addresses of currently active validators
    function getValidators()
        external
        view
        returns (address[] memory)
    {
        return relayedSet.getValidators();
    }

    /// @dev The actual logic of setting the Relayed contract
    function _setRelayed(address _relayedSet)
        private
        nonDefaultAddress(_relayedSet)
    {
        require(
            _relayedSet != address(relayedSet),
            "New relayed contract address cannot be the same as the current one"
        );
        address oldRelayed = address(relayedSet);
        relayedSet = IValidatorSetRelayed(_relayedSet);
        emit NewRelayed(oldRelayed, _relayedSet);
    }
}

Name registry

There are two reasons for making this contract Ownable:

Interacting with the Name Registry Contract

Contract Address and ABI

Contract

Address

JSON ABI

SimpleRegistry

0x1204700000000000000000000000000000000006

Callable Functions

Function

Description

entries(bytes32)

Returns an entry based on the sha3 hash of the name registered.

reverse(address)

Reverse resolution of an address.

fee()

Returns the fee for reserving a name (not really relevant to public).

getData(bytes32,string)

Returns a string data value from an entry, given its key.

getAddress(bytes32,string)

Returns an address data value from an entry, given its key.

getUint(bytes32,string)

Returns an unsigned integer data value from an entry, given its key.

getOwner(bytes32)

Returns the owner of an entry.

hasReverse(bytes32)

Returns true if entry has a reverse address registered.

getReverse(bytes32)

Returns reverse address of an entry.

canReverse(address)

Returns true if address can have a reverse.

reverse(address)

Returns the reverse value of an address.

reserved(bytes32)

Returns true if the name (its sha3 hash) is already reserved.

Holding Contract

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

Check a Balance and Withdraw Funds

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

Enter your address in the lookup field to see your holding balance
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.

Interacting with the Holding Contract

Contract Address and ABI

Callable Functions

EWX ECOSYSTEM

ENERGY SOLUTIONS

Transactions and Transaction Costs

A transaction is any action that updates the state of the blockchain. There are costs associated with each transaction that cover the computational cost of processing that transaction. These costs are variable and dependent on several factors, which are discussed .

This page covers the basic functionality of transactions, how their associated costs are calculated, and where to see transaction data from the Energy Web Chain and Volta Testnet. If you want to read more about the fundamentals of transactions, see the Ethereum documentation on , , and ,

Transactions

A transaction is any ‘write’ operation that changes or updates the state of the blockchain. Transactions are always initiated by an , and they must be signed by the account owner that initiated the transaction in order to be completed. Examples of write transactions include:

Transferring tokens between accounts
Deploying new smart contracts or accounts
Calling or Interacting with existing smart contracts

Once confirmed by the initiator, transactions can be in two states: pending and validated.

Pending Transactions

In a consensus blockchain, take turn validating transactions and sealing blocks. Before a transaction is validated, it is in a "pending" state in the memory pool ("mempool"). The following image shows a transaction in a "pending" state. You can view all pending transactions on the Energy Web Block Explorer

Notice that the transaction fee of a pending transaction is not determined yet and the "Block Number" is pending.

Transaction in pending state - from Energy Web Block Explorer

Validated Transactions

The following image is a transaction in a "validated" state. You can view all validated transactions on the Energy Web Block Explorer

Notice that the transaction fee of a validated transaction is no longer 0, it has a value in EWT.

Determining Transaction Cost

As we’ll soon see, these differences from one transaction to the next can have an impact on ultimate transaction cost.

Transaction Cost Variables

There are three key variables that influence transaction cost:

1. Gas Cost

A transaction’s computational complexity is measured in, a unit that assigns a numeric value to each operational code, or instruction, that will be executed to complete the transaction. The gas cost of a transaction is determined by the amount and sophistication of code that needs to be executed as well as the amount and type of data that will be stored on the blockchain as a result. The more complex the transaction, the higher the gas cost.

2. Gas Price

Gas price is on the EW Chain is denominated in EWT (usually in minuscule units like , which represent one billionth of an EWT). The price is expressed in tokens (gwei) per unit of gas.

You can specify a gas price in a transaction through MetaMask:

Gas price of .01 Gwei.

3. Token Value

Calculating Transaction Cost

Using the three variables above, you can calculate the total transaction cost:

TxCost(unit:fiat$) = GasCost(unit:gas) x gasprice(unit:token/gas) x tokenvalue($/token)

Here’s how a fee would be calculated for a hypothetical transaction on the Energy Web Chain:

50,000 gas x 1 gwei per gas = 50,000 gwei = 0.00005 EWT

If the market price of EWT was $1 at the time of the transaction, this would equate to $0.00005 fee. If the price of EWT was $10, this would equate to $0.0005.

Gas Price, Gas Limits and Block Size

To ensure that block time remains consistent and to prevent any given block from being overloaded with transactions, the EW Chain has a predefined limit to the amount of that can be consumed in each block. Each block on the Energy Web Chain has a size limit of 8 million units of gas.

Because each transaction uses different amounts of gas, the number of transactions that fit on a block will vary.

Take a look at the details of a block added to the Energy Web Chain:

Block Details of a Single Block on the Energy Web Chain

From this we can see that:

This block includes 43 transactions
The gas limit for the block is 8,000,000 (this limit remains constant for every block)
Only 1,553,623 units of gas were used to create the block (less than 20% of its limit)
If there were more transactions waiting in the memory pool to be added to the block, this block could have processed ~6,446,377 units worth of gas.