šŸš€
Energy Web X Ecosystem
  • Documentation Overview
  • Core Concepts
    • Energy Web Chain
    • Energy Web X
    • Energy Web Tokens
      • Token Lifting
      • Token Lowering
    • Worker Nodes and Worker Node Networks
      • Server-based Worker Node
      • Marketplace App (desktop-based)
    • Worker Node Operator
    • Smart Flows and Groups
    • Subscription
    • Reward Period
    • Voting and Consensus
    • Ethereum
      • Transactions and Transaction Costs
    • Decentralized Identifiers (DIDs)
  • EWC ECOSYSTEM
    • Energy Web Chain
      • System Architecture
        • Proof-of-Authority Consensus Mechanism
        • System Contracts
          • Name registry
          • Holding Contract
          • Block Reward Contract
          • Validator-Set Contract
        • Validator Node Architecture
      • Energy Web Block Explorer
      • Energy Web Chain Governance & Validators
    • Energy Web Tokens
  • EWX ECOSYSTEM
    • Energy Web X
    • EWX: Architecture
    • Pallets
      • Worker Node Pallet
      • Balances Pallet
      • Proxy Pallet
      • XCM Pallet
      • Assets Pallet
      • Multisig Pallet
      • Scheduler Pallet
      • Preimages Pallet
      • Offences Pallet
      • Eth-Bridge Pallet
      • Token-Manager Pallet
      • Ethereum-events pallet
      • Avn Pallet
    • Worker Nodes
      • šŸ–„ļøThe Marketplace App
        • Operator and Worker Accounts
          • Creating an operator account
          • Funding an operator account
          • Connecting to operator account
          • Disconnecting an operator account
          • Creating a worker account
          • Importing worker account
          • Exporting worker account
          • Linking a worker account to an operator account
          • Unlinking a worker account from an operator account
        • How to use Ledger on Marketplace App
        • Token Management
          • Creating an EWC account
          • Managing EWC accounts
          • Lifting tokens
          • Lowering tokens
          • Tracking lifting and lowering transactions
          • Checking EWT balance
        • Subscriptions
          • Subscribing to a solution group
          • Topping-up subscription amount
          • Managing subscriptions
          • Unsubscribing from a solution group
          • Unsubscribing delay
        • Worker Node and Rewards
          • Configuring remote worker node
          • Switching worker node location to remote
          • Participating into worker node network
          • Votes casted per Period
          • Reward Period
          • Checking rewards
          • Claiming rewards
        • FAQ: Marketplace App
        • Location Services
      • šŸ—„ļøServer-based Worker Nodes
        • Deployment Guide
        • Bootstrapping Server-based Worker Node Accounts
        • FAQ: Server-based Worker Nodes
      • Worker Node use cases
        • Sample Enterprise Use-Cases
          • Operating Envelopes Partitioning
          • ZEL Request Partitioning
          • Green Proofs
            • SAFc
            • Green Proofs for Bitcoin (GP4BTC)
            • Green Proofs as a Service (GPSaaS)
            • Green Proofs for Electrical Vehicles (GP4EV)
  • ENERGY SOLUTIONS
    • Green Proofs by Energy Web
      • Green Proofs Overview
      • Green Proofs Architecure
      • Green Proofs Software Stack
      • Use Cases and Reference Implementations
        • 24x7 Renewable Electricity
        • Sustainable Aviation Fuel
        • Green Proofs for Bitcoin
          • GP4BTC Miner Guide
        • Decarbonizing Shipping
        • Green Proofs for Electrical Vehicles
        • Green Proofs as a Service (GPSaaS)
    • Digital Spine by Energy Web
      • Design and Architecture
      • Component Guides
        • Energy Web Name Service (ENS)
        • Self-Sovereign Identities
          • SSI-Hub
          • Technical Guide
            • Organizations
            • Applications
            • Roles and IAM
          • Deployment Guide
            • Deploy Identity Cache Server
            • Deploy Switchboard
        • DDHub Message Broker
          • Technical Guide
            • Authentication and Authorization
            • Topics
            • Messaging
          • Deployment Guide
            • Deploy DID Auth Proxy
            • Deploy Message Broker
        • DDHub Client Gateway
          • Technical Guide
            • Authentication and Authorization
              • Key Vault
            • Client Gateway Identity and VCs
            • Address Book
            • Topics
            • Channels
            • Integration Options
            • Messaging
          • Deployment Guide
            • Launchpad SaaS
            • Azure Marketplace
            • Self-Hosted
              • Deploy with Kubernetes
              • Deploy with Docker
            • Key Vault
              • Deploy with HashiCorp Key Vault
              • Deploy with Azure Key Vault
              • Deploy with AWS Secrets Manager
            • Rebranding and Whitelabelling
Powered by GitBook
On this page
  • Transactions
  • Determining Transaction Cost
  • Calculating Transaction Cost
  • Gas Price, Gas Limits and Block Size
  • Keeping Public Blockchain Transaction Costs Low
  • Additional Resources
  1. Core Concepts
  2. Ethereum

Transactions and Transaction Costs

PreviousEthereumNextDecentralized Identifiers (DIDs)

Last updated 5 months 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

Transaction in pending state - from Energy Web Block Explorer

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.

Gas price of .01 Gwei.

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.

Block Details of a Single Block on the Energy Web Chain

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 .

below
transactions
blocks
gas
Transactions
Transaction Cost Variables
Calculating Transaction Costs
Gas Price and Block Size
Keeping the Public Transaction Cost Low
Additional Resources
externally owned account
Proof-of-Authority
validators
here.
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