Energy Web Documentation
  • Energy Web Ecosystem
  • Launchpad by Energy Web
  • EWC Validator Documentation
  • Community Ressources
  • Legacy documentation
  • Welcome to Energy Web
  • Glossary
  • Solutions 2023
    • ↔️Data Exchange
      • Data Exchange Overview
      • Data Exchange Architecture
      • Use Cases and Refrence Implementations
        • Digital Spine for Electricity Markets
          • Digital Spine Integration Client Deployment Guide - from Azure marketplace
        • E-Mobility Management
    • 🔌Open Charging Network
      • Create and Manage an OCN Identity
      • Connect an OCPI/OCN Party to a Node
        • 1. Make your backend service OCN-ready
        • 2. Select an OCN Node and register in OCN Registry
        • 3. Manage your Whitelist and Blacklist
        • 4. Connect your service to an OCN Node
      • Run an OCN Node
      • Use the OCN Service Interface
        • Offer an OCN Service
        • Sign up for an OCN Service
      • Develop on the Test Network
      • Develop on the Production Network
      • Open Source Development
        • Maturity Model, Feature Roadmap and Releases
        • Developer Community Calls
      • E-Mobility Dashboard v0.1
  • EW-DOS Technology Components 2023
    • EW-DOS Overview
    • Worker Nodes
      • Worker Node Process Diagrams
      • Worker Node Architecture
      • Worker Node Guides
        • Deploy Worker Nodes
        • Customize Worker Logic
    • Identity and Access Management (IAM)
      • IAM Guides
        • Implement an SSI Hub instance
        • Verifiable Credential API
        • Sign-In with Ethereum
        • Using Switchboard
          • Switchboard Transaction Cost Estimates
      • IAM Patterns
        • Assets as Ownable Smart Contracts
        • Credential Lifecycle
        • Credential Metadata
        • SSI Credential Governance using ENS Domains
      • IAM Libraries
      • SSI Hub
      • Switchboard Application
    • Decentralized Data Hub (DDHub)
      • DDHub Message Broker
      • DDHub Client Gateway
      • DDHub Patterns
        • Channels and Topics
      • DDHub Guides
    • Green Proofs Contracts
    • Energy Web X
    • The Energy Web Chain
      • EWC Overview
      • System Architecture
        • Proof-of-Authority Consensus Mechanism
        • System Contracts
          • Name Registry
          • Holding Contract
          • Block Reward Contract
          • Validator-Set Contracts
        • Validator Node Architecture
      • Energy Web Block Explorer
      • Validator Node Installation Specifications
        • Volta Test Network: Validator Node Installation
      • Energy Web Chain Governance
      • EWC Guides and Tutorials
        • Getting started with Energy Web Chain
        • Developing on the Volta Test Network and Main Network (Energy Web Chain)
        • Run a Local RPC Node
          • Run RPC Node using Nethermind client
        • Deploy a Smart Contract on Volta with Remix
        • Interacting with Smart Contracts in EW-DOS
        • Set up MetaMask to interact with Energy Web Chain
        • Using the Ethereum Name Service
        • Using Oracles
      • Energy Web Token (EWT)
  • 🧠Foundational Concepts
    • Open-Source Software
    • Scaling Access to Grid Flexibility
    • Facilitating Clean Energy Purchases
    • Ethereum
      • Transactions and Transaction Costs
    • Self-Sovereign-Identity
      • Self-Sovereign Use Case Interaction
    • Cryptocurrency Wallets
      • Software cryptocurrency wallets
        • Metamask
        • Mycrypto wallet
      • Hardware cryptocurrency wallets
      • Hierarchical Deterministic (HD) Wallets
Powered by GitBook
On this page
  • Transactions
  • Pending Transactions
  • Validated Transactions
  • Determining Transaction Cost
  • Transaction Cost Variables
  • 1. Gas Cost
  • 2. Gas Price
  • 3. Token Value
  • Calculating Transaction Cost
  • Gas Price, Gas Limits and Block Size
  • Keeping Public Blockchain Transaction Costs Low
  • If users desire a low-cost network, why do transaction costs rise in the first place?
  • Lessons from what we know about the Energy Web Chain
  • Additional Resources
Export as PDF
  1. Foundational Concepts
  2. Ethereum

Transactions and Transaction Costs

PreviousEthereumNextSelf-Sovereign-Identity

Last updated 3 years ago

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.

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

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

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.

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.

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.

You can see all block and transaction details for the Energy Web production chain at .

You can see all block and transaction details for the Volta Testnet at .

🧠
here.
gas
gwei
gas
https://explorer.energyweb.org/
https://volta-explorer.energyweb.org/
Energy Web blog post "How to Manage Transaction Costs on Public Blockchains"
"Chapter 6: Transactions" from Mastering Ethereum
Transactions
Blocks
Gas
transactions
blocks
gas
externally owned account
Proof-of-Authority
here.
below
Transactions
Transaction Cost Variables
Calculating Transaction Costs
Gas Price and Block Size
Keeping the Public Transaction Cost Low
Additional Resources
Transaction in pending state - from Energy Web Block Explorer
Gas price of .01 Gwei.
Block Details of a Single Block on the Energy Web Chain
validators