Energy Web supports two distinct blockchain networks:

1. The Volta Test Network (Testnet)

2. The Energy Web Production Network (Mainnet)

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

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

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

Developing on Volta Test Network

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

Volta is used as a staging network to:

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

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

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

Get Started Using Volta

• Get Volta Tokens

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

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

Developing on Energy Web Main Network

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

Get Started Using the Energy Web Chain

• Get EWT

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

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

Related Content

1. Install MetaMask

2. Get Tokens

3. Using EW-DOS

Learn about Volta Testnet and Energy Web Mainnet

See an Overview of the EW-DOS Tech Stack

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

1. Configure MetaMask to connect to the Volta Test Network

2. Get Volta Tokens

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

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

5. Confirm the connection on MetaMask

You will need to confirm the connection to MetaMask.

6. Create a simple smart contract

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

In the .sol file, add the following code:

7. Compile the smart contract

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

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

9. Deploy the smart contract

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

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

Select EDIT

Select "Edit suggested gas fee"

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

Confirm the transaction in MetaMask

10. See and test the deployed transaction

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

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

11. See deployed contract on the Volta Block Explorer

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

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

12. Use your smart contract in dapps

2. Full specification for Nethermind configuration options can be found here:
3. Run the following command in your terminal -

Run RPC node in Volta Network

Run RPC node in EWC Network

Your local node should start:

Run a local node using Docker with Nethermind client

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

Set up

1. Verify that prerequisites are installed:

1. Create working directory

1. Create docker-compose.yaml file

1. Start container:

1. Examine logs:

The log output should be similar to the following

Nethermind Configuration

You have the option of running a full node of the Energy Web Chain main network or Volta test network locally. Running a local node does requires a degree of technical capability. It helps to understand the benefits of doing so, and the alternatives to running a full local node.

What does it mean to run a node?

A node is any machine that is actively running client software and is connected to the blockchain. Blockchain is often called a “peer-to-peer” network, because its network is made up of many peers running nodes simultaneously that are connected to each other.

Depending on the blockchain you are you connecting to, this can take up large amounts of space and take a long time to retrieve and sync the history of the chain on your machine. For example, synching with the Energy Web chain will require much less resources than syncing with the Ethereum mainnet, as it is a much larger and longer-running blockchain.

What do I need to run a node?

Benefits to Running a Local Node

1. The more nodes there are, the more secure the system is as a whole. Blockchains are decentralized technology, so by design the system performs better if there are multiple instances of it rather than just one. The more nodes there are, the less points of failure or opportunities for malicious action.

Alternatives to Running a Local Node

Running a local node is not necessary to use applications that run on the blockchain or transfer tokens.

Run a local node using the command line

Hardware Requirements

• Multi-core CPU

• 4GB RAM

• SSD drive and free space

  • EWC RPC node - 150 GB

  • Volta RPC node - 200 GB

• A decent DSL connection is required

Download Chainspec file

Download and save the chain config to your local machine.

Volta Testnet chainspec:

Energy Web Chain (production) chainspec:

Using OpenEthereum Client

3. Run the following command in your terminal. Provide the path to the chain config that you want to use. The following command references the Volta chain config.

Your local node should start:

Connect your local node to MetaMask

Get the URL of your MetaMask account. You can do this by clicking the settings dropdown and selecting "Expand View."

When the view is expanded, copy the URL in the browser

Run the following command in your terminal

Run a local node using Docker with OpenEthereum client

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

Prerequisites

Set up

1. Verify that prerequisites are installed:

2. Create working directory

3. Create docker-compose.yaml file

4. Download database snapshot - this takes some time and requires resources due to the size of the .tar file, but it will speed up synchronization process.

*Note that this step is optional. If you do not download the database snapshot, move to Step 6.

Volta (depending on your internet connection ~1 hour download time for us):

Energy Web Chain (production) (30 minutes download time for us):

5. Unpack database snapshot. This snapshot only works with OpenEthereum client.

*Note that this step is optional. If you did not complete Step 5, skip this step and move to Step 6.

Volta:

Energy Web Chain (production):

6. Set permissions:

8. Start container:

9. Examine logs:

The log output should be similar to the following (sometimes the logging output does not appear immediately, wait some time):

10. After some, you will sync with the network. Until a full sync, you will see be in a "syncing" state:

The output will show current synchronization status:

It will take some time to fully sync with the current state of the blockchain. When the synchronization is finished status will be:

Additional Resources

Blockchain Oracles

By themselves, smart contracts cannot access data outside of the blockchain or send its data to services outside of the blockchain. To do this, smart contracts use middleware called an oracles, which are third-party services that fetch and send data to and from smart contracts. Oracles are similar to traditional web-based API services.

Smart contracts can contain logic that triggers certain changes or actions based on external data from an Oracle. Without oracles, blockchains and their applications that cater to specific industries that rely on real-time changes such as finance, commodity trading, or IoT, would not have access to the data necessary to react to real-time external factors.

It's important to keep in mind that oracles are agnostic of the data they transmit - they are only responsible for fetching, verifying and relaying the data to and from the blockchain.

Inbound vs. Outbound Oracles

Inbound oracles send data to the blockchain. This is the most common type of oracle. Like traditional API services, the inbound data that the oracle provides can be anything that your smart contract needs for internal logic that it cannot access from the blockchain or the smart contract itself.

For example, you want to send 10 EWT to a friend's address when the price of a specific stock goes above $10 per share. An oracle will provide you with the data about stock price, and the blockchain logic will trigger the send when the oracle delivers data indicating that the price of a stock goes above $10.

Outbound oracles send data about events that happen on the blockchain to third party applications. For example, an account could receive a payment and trigger an outbound oracle to a mechanism that activates a pv solar panel.

Oracle Data Sources

Oracles can gather data from software and hardware. A software oracle interacts with and fetches data available from any web source that exposes its data. Some common examples are weather APIs, real-time stock information and exchange rates.

Hardware oracles interact with 'physical' data sources like sensors from IoT devices, QR codes or bar codes. Some examples could be reading the temperature from a smart thermostat or fetching data from a flood sensor..

Centralized Vs. Decentralized Oracles

Centralized oracles are developed, maintained and controlled by a single entity. One oracle is responsible for fetching data from one or many data sources, and then transmitting that data to the smart contract on the blockchain. You could liken this to using a centralized database for your smart contract's external data sources.

Decentralized oracles aggregate data from multiple sources using multiple oracle nodes, so that there is no single point of failure for data retrieval, and no single point of failure for the oracle itself. Decentralized oracles are more aligned with the wider community of public blockchain.

Fundamental Oracle Functionality

Regardless of the data source, or if it is centralized or decentralized, all oracles provide three main functionalities:

1. Listen to the blockchain network for incoming requests for off-chain data

2. Fetch data from the requested off-chain source

3. Transfer the data to the blockchain via a signed transaction

4. Insert the data into a smart contract’s local storage. Once the data is in the smart contract's storage, it can be used to trigger logic within that smart contract, or it can be available for other smart contract's to use

Oracle Design Patterns: Communicating Data To Smart Contracts

Depending on the nature of the data itself and how the smart contract uses the data, oracles can be designed to communicate with smart contracts using three main patterns:

1. Publish-subscribe: An oracle broadcasts data, and certain smart contracts are polling or "listening to" that oracle for changes in data. An example: "Poll the temperature of region X every 10 minutes. If the temperature is above 70 degrees celsius, turn the smart thermostat to 'on'."

2. Immediate-read: Oracles hold data in their storage and provide this data on request. Users or devices query the oracle for this data at the same time that it is needed. An example: "Is device X in a list of authorized devices to provide solar power to region Y."

3. Request-response: External accounts (via decentralized applications) interact with a smart contract and necessitate data from the oracle. The smart contract sends the data parameters to the oracle and performs the third-party data query. When the data is fetched, it sends the result back to the smart contract for the decentralized application to use. Because the decentralized application cannot always wait for the data, this occurs asynchronously. An example: A user selects from a dropdown on a decentralized application a date range to determine the average temperature of each day during the range. The start and end date are sent to the data oracle to fetch the temperatures for the days in the given date range. The data is sent back to the smart contract to perform necessary logic based on the data.

Tutorial: Using Chainlink with the Volta Test Network

Chainlink provides decentralized oracle networks. This tutorial covers:

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

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

• Design principles of Chainlink oracles

• Scenarios where it makes sense to use Chainlink

EW-DOS utility layer packages and SDKs interact with smart contracts that are deployed on the Energy Web Chain. To do this, they use API Client Libraries to connect to the blockchain and create instances of smart contracts to access their public functions.

Below we provide an overview of API Client libraries and a some code examples. Note that exact implementation varies in each package or SDK, but the fundamental concepts remain the same.

API Client Libraries

You can interact with smart contracts (i.e. call their public read and write functions) on the the Energy Web Chain and the Volta Test Network using any Ethereum API client library. Client libraries allow you to connect to and interact with the blockchain network. You can read about all the functionalities of Ethereum API client libraries in the Ethereum documentation here.

The most popular JavaScript libraries for interacting with Ethereum networks are ethers.js and web3.js. EW-DOS uses ethers.js, so below we will provide ethers.js examples, however concepts will be similar among different client libraries.

When interacting with a contract, you use a library to first create a Provider, which is a connection the blockchain. You then use the provider to create an instance of the smart contract that you want to interact with. Once this instance is created, you can call the public methods that are exposed in the smart contract.

1. Instantiate a Provider

A provider is a connection to the blockchain. It gives you an interface to interact with the network. To create a JSONRpcProvider, you will need the JSON RPC Url. To create an IPCProvider, you will need the path local IPC filename (this is only available in node.js).

You can see the full ethers.js documentation on Providers here.

import { providers, Signer, utils, errors, Wallet } from "ethers";
const { JsonRpcProvider } = providers;

this._provider = new JsonRpcProvider({ url: rpcUrl });

See source code here

2. Instantiate a Contract

To create a new instance of a contract that is already deployed on the blockchain, you need three pieces of information:

1. The contract's ABI- the ABI (Application Binary Interface). The ABI is a JSON object that provides the interface to your smart contract. It defines the contract's constructor, events and the behavior of its public functions. The contract's ABI is generated with the smart contract is compiled.

2. The contract's address - every smart contract has an address when it is deployed to the blockchain. You can deploy the same contract on multiple blockchains, but each contract will have a different address.

3. The provider

You can see the ethers.js documentation **** for creating a new instance of a deployed Contract here.

//pass in the smart contract address, smart contract ABI, provider:
this._contract = new Contract(settings.address, this.settings.abi, this._provider);

See source code here

2. Implement Contract Methods

The Contract method returns a new instance of that contract at the address passed in. Now that we have an instance of this contract, we can interact with its public methods:

    try {
      valid = await this._contract.validDelegate(identityAddress, bytesType, delegateAddress);
    } catch (error) {
      throw new Error(error);
    }

See source code here

EW-DOS Smart Contracts

For a tutorial on how to deploy a smart contract on the Volta Test Network or Energy Web Main Network, go here.

Connect MetaMask to the Energy Web blockchain

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

Option1: Automatic configurator

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

Option2: Manual configuration

Video Tutorial

The Energy Web blockchain uses the Ethereum Name Service (ENS) for name-spacing assets that are anchored on our blockchain. ENS is a critical part of providing user-friendly dApps. You can interact with the ENS contracts that are deployed on the Energy Web Chain in several ways.

Below we explain:

• The benefits of ENS

• The main components of ENS (Registry and Resolvers)

• Interacting with ENS on Energy Web Chain

Benefits of Ethereum Name Service

The Ethereum Name Service (ENS) is a distributed, open, and extensible naming system based on the Ethereum blockchain.

Machine-readable blockchain identifiers such as Ethereum addresses, content hashes and metadata are difficult to interact with in a user interface. ENS was developed to provide human-readable, user-friendly mapping for these identifiers, and to give users the ability to reserve domain names for our applications. To date, it is the most widely used blockchain naming standard.

ENS solves a similar problem that Domain Name Systems (DNS) provide. DNS lets us navigate to a website using human language and an intuitive format (www.energyweb.org), rather than using an IP address that is impractical to remember and has no association with the content that it directs you to (104.26.13.227). Similar to DNS, ENS supports a structure of dot notation for hierarchy and nesting.

Using ENS, you can create identifiers for the following blockchain content types:

• Address

• Reverse address (e.g. an address resolves to alice.eth)

• Content hash (e.g.: IPFS/Swarm hashes)

• ABI definitions

• DNS records

• Public keys

• Smart contract interfaces (see EIP 165)

• Text (email, physical address, geo location, metadata)

You can see a full list here in the ENS documentation, as well as the specifications for resolving each type.

Examples:

As a simple example, if you want to send funds to your friend Alice, you can specify the recipient as “alice.eth” instead of “0x0052569B2d787bB89d711e4aFB56F9C1E420a2a6”.

If you want to refer to a content hash of a report listed at your custom domain, you can refer to it has “myReport.myDomain”, instead of by the hash identifier.

The two main components of ENS, explained below, are responsible for storing the human-readable address in smart contract registry, and resolving it to its original content.

Main Components of ENS

ENS has two primary components: the Registry and the Resolvers.

Registry

A smart contract that holds all of the domains/subdomains, the owner of the domain, and the domain resolver (the method used to map it back to its original address.) You can see the ENS Registry smart contract here.

Resolvers

Methods that translate the human-readable names to their original address. A resolver has multiple methods, each of which are responsible for resolving different types identifiers (for example, one method is responsible for resolving contract ABI definitions , one method is responsible for resolving content hashes.)

• You can see the ENS smart contracts for all of the resolver types here

• You can read more about the Registry and Resolvers in the original documentation here

What’s important to take away is that the two primary components for ENS are smart contracts that hold a mapping for all domains/subdomains, and provide resolver methods for translating different address types to a human readable form. These contracts are extendible, so you can add your own resolvers for different address types.

ENS on the Energy Web Chain

Energy Web has deployed the ENS smart contracts on the Energy Web mainnet and Volta testnet. You have several options for interacting with ENS, depending on your use case.

Interact directly with the smart contracts on the blockchain

Use the Energy Web ENS Manager app

You can use this interface to search for available names in the Energy Web domain and register them to your address. Note that you will need to have sufficient funds in your wallet to do so as there is a fee for name registration.

Our management app is forked from the Ethereum Name Service Manager app.

Use a JavaScript library

There are a number of libraries that support ENS. These libraries have methods to configure your registry, and manage and resolve names. The IAM client library and IAM Cache server both connect to ENS using the ethers library. You can see the Ethers API support for ENS here.

For a full list of libraries that support ENS, see the ENS documentation here.

Additional Resources

• Ethereum Name Service (ENS) is now available for the Energy Web