Developer Resources
Block ExplorerGitHubRun a NodeMigration GuideETN Testnet Faucet
  • Overview
  • Foundational topics
    • Intro to the Electroneum Smart Chain
    • Intro to ETN
    • Intro to dapps
    • Web2 vs Web3
    • Accounts
    • Transactions
    • Blocks
    • Electroneum Virtual Machine (EVM)
      • Opcodes
    • Gas and Fees
    • Nodes and clients
    • Networks
    • Consensus mechanisms
      • IBFT
  • Electroneum Stack
    • Intro to the stack
    • Smart contracts
    • Development networks
    • Development frameworks
    • Electroneum client APIs
      • JavaScript APIs
      • JSON-RPC
    • Storage
    • Integrated Development Environments (IDEs)
    • Metamask
  • Advanced
    • Bridges
    • Standards
      • Token standards
        • ERC-20 Fungible Tokens
        • ERC-721 NFTs
    • Oracles
    • Networking layer
      • Network addresses
    • Data structures and encoding
      • Patricia Merkle Trie
      • Recursive-length prefix (RLP)
      • Web3 secret storage definition
  • Design fundamentals
    • Intro to design and UX
  • ETN-SC Client
    • Getting started
      • Introduction
      • Hardware requirements
      • Instaling ETN-SC
    • Fundamentals
      • Command-line options
      • Security
      • Sync-modes
      • Account management
      • Databases
      • Backup & restore
      • Logs
      • Connecting to peers
      • Pruning
      • Private networks
      • Config files
      • Light client
    • Interacting with ETN-SC
      • JSON-RPC Server
        • Batch requests
        • Real-time events
      • JSON-RPC Namespaces
        • admin
        • clique
        • debug
        • eth
        • istanbul
        • les
        • miner
        • net
        • personal
        • txpool
      • JS Console
      • JS Console 2: Contracts
      • GraphQL Server
    • Developers
      • Introduction
      • Dapp developers
        • Dev mode
        • Go API
        • Go Account Management
        • Go Contract Bindings
      • EVM tracing
        • Introduction
        • Basic traces
        • Built-in tracers
        • Custom EVM tracer
        • Tutorial for JavaScript tracing
      • ETN-SC developer
        • Developer guide
        • Disclosures
        • DNS discovery setup guide
        • Code review guidelines
      • Contributing
    • Monitoring
      • Creating Dashboards
      • Understanding Dashboards
      • Ethstats
      • Metrics
    • Tools
      • Clef
        • Introduction
        • APIs
        • Rules
        • Setup
        • Datatypes
        • Tutorial
        • Clique-signing
      • abigen
      • devp2p
    • FAQs
  • Migration to Smart Chain
    • Overview
    • How to Migrate
      • ETN Online Wallets
      • Paper Wallets
      • CLI Wallet Users
      • Exchange Holders
      • Exchanges
    • Bridge Smart Contract
  • Misc. Guides
    • Set up Ledger + Metamask
  • MY.ELECTRONEUM.COM
    • Vendor API
Powered by GitBook
On this page
  • Prerequisites
  • What's a transaction?
  • The data field
  • Types of transactions
  • On gas
  • Transaction lifecycle
  • TYPED TRANSACTION ENVELOPE
  • Further reading
  • Related topics

Was this helpful?

  1. Foundational topics

Transactions

PreviousAccountsNextBlocks

Last updated 1 year ago

Was this helpful?

Transactions are cryptographically signed instructions from accounts. An account will initiate a transaction to update the state of the Electroneum network. The simplest transaction is transferring ETN from one account to another.

Prerequisites

To help you better understand this page, we recommend you first read and our .

What's a transaction?

An Electroneum transaction refers to an action initiated by an externally-owned account, in other words an account managed by a human, not a contract. For example, if Bob sends Alice 1 ETN, Bob's account must be debited and Alice's must be credited. This state-changing action takes place within a transaction.

Diagram adapted from

Transactions, which change the state of the EVM, need to be broadcast to the whole network. Any node can broadcast a request for a transaction to be executed on the EVM; after this happens, a validator will execute the transaction and propagate the resulting state change to the rest of the network.

Transactions require a fee and must be included in a validated block. To make this overview simpler we'll cover gas fees and validation elsewhere.

A submitted transaction includes the following information:

  • from – the address of the sender, that will be signing the transaction. This will be an externally-owned account as contract accounts cannot send transactions.

  • recipient – the receiving address (if an externally-owned account, the transaction will transfer value. If a contract account, the transaction will execute the contract code)

  • signature – the identifier of the sender. This is generated when the sender's private key signs the transaction and confirms the sender has authorized this transaction

  • nonce - a sequentially incrementing counter which indicates the transaction number from the account

  • value – amount of ETN to transfer from sender to recipient (denominated in WEI, where 1ETN equals 1e+18wei)

  • input data – optional field to include arbitrary data

  • maxPriorityFeePerGas - the maximum price of the consumed gas to be included as a tip to the validator

  • maxFeePerGas - the maximum fee per unit of gas willing to be paid for the transaction (inclusive of baseFeePerGas and maxPriorityFeePerGas)

Gas is a reference to the computation required to process the transaction by a validator. Users have to pay a fee for this computation. The gasLimit, and maxPriorityFeePerGas determine the maximum transaction fee paid to the validator.

The transaction object will look a little like this:

{
  from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",
  to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",
  gasLimit: "21000",
  maxFeePerGas: "300",
  maxPriorityFeePerGas: "10",
  nonce: "0",
  value: "10000000000"
}

But a transaction object needs to be signed using the sender's private key. This proves that the transaction could only have come from the sender and was not sent fraudulently.

An Electroneum client like etn-sc will handle this signing process.

{
  "id": 2,
  "jsonrpc": "2.0",
  "method": "account_signTransaction",
  "params": [
    {
      "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db",
      "gas": "0x55555",
      "maxFeePerGas": "0x1234",
      "maxPriorityFeePerGas": "0x1234",
      "input": "0xabcd",
      "nonce": "0x0",
      "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
      "value": "0x1234"
    }
  ]
}

Example response:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "raw": "0xf88380018203339407a565b7ed7d7a678680a4c162885bedbb695fe080a44401a6e4000000000000000000000000000000000000000000000000000000000000001226a0223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20ea02aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
    "tx": {
      "nonce": "0x0",
      "maxFeePerGas": "0x1234",
      "maxPriorityFeePerGas": "0x1234",
      "gas": "0x55555",
      "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
      "value": "0x1234",
      "input": "0xabcd",
      "v": "0x26",
      "r": "0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e",
      "s": "0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
      "hash": "0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e"
    }
  }
}
  • the tx is the signed transaction in JSON form

With the signature hash, the transaction can be cryptographically proven that it came from the sender and submitted to the network.

The data field

The first four bytes specify which function to call, using the hash of the function's name and arguments.

The rest of the data is:

0000000000000000000000004f6742badb049791cd9a37ea913f2bac38d01279
000000000000000000000000000000000000000000000000000000003b0559f4

Types of transactions

On Electroneum Smart Chain there are a few different types of transactions:

  • Regular transactions: a transaction from one account to another.

  • Contract deployment transactions: a transaction without a 'to' address, where the data field is used for the contract code.

  • Execution of a contract: a transaction that interacts with a deployed smart contract. In this case, 'to' address is the smart contract address.

On gas

So for Bob to send Alice 1 ETN at a baseFeePerGas of 190 gwei and maxPriorityFeePerGas of 10 gwei, Bob will need to pay the following fee:

(190 + 10) * 21000 = 4,200,000 gwei
--or--
0.0042 ETH

Bob's account will be debited -1.0042 ETN (1 ETN for Alice + 0.0042 ETN in gas fees)

Alice's account will be credited +1.0 ETN

The base fee will be burned -0.00399 ETN

Validator keeps the tip +0.000210 ETN

Gas is required for any smart contract interaction too.

Any gas not used in a transaction is refunded to the user account.

Transaction lifecycle

Once the transaction has been submitted the following happens:

  1. A transaction hash is cryptographically generated: 0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017

  2. The transaction is then broadcasted to the network and added to a transaction pool consisting of all other pending network transactions.

  3. A validator must pick your transaction and include it in a block in order to verify the transaction and consider it "successful".

  4. On Electroneum, the IBFT consensus mechanism provides 1-block finality for transactions, meaning that once your transaction is added into a block it is considered "final" and can never be changed or reversed.

TYPED TRANSACTION ENVELOPE

RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])

TransactionType || TransactionPayload

Where the fields are defined as:

  • TransactionType - a number between 0 and 0x7f, for a total of 128 possible transaction types.

  • TransactionPayload - an arbitrary byte array defined by the transaction type.

  • TransactionType = 0x40.

  • TransactionPayload = RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s, priorityV, priorityR, priorityS])

ETNIP-1 transactions are prioritised by the validators.

Further reading

Related topics

gasLimit – the maximum amount of gas units that can be consumed by the transaction. The specifies the units of gas required by each computational step

.

Example call:

the raw is the signed transaction in encoded form

The vast majority of transactions access a contract from an externally-owned account. Most contracts are written in Solidity and interpret their data field in accordance with the .

The rest of the calldata is the arguments, .

For example, lets look at . Use Click to see More to see the calldata.

The function selector is 0xa9059cbb. There are several . In this case has been uploaded to Etherscan, so we know the function is transfer(address,uint256).

According to the ABI specifications, integer values (such as addresses, which are 20-byte integers) appear in the ABI as 32-byte words, padded with zeros in the front. So we know that the to address is . The value is 0x3b0559f4 = 990206452.

As mentioned, transactions cost to execute. Simple transfer transactions require 21000 units of Gas.

Diagram adapted from

Ethereum originally had one format for transactions. Each transaction contained a nonce, gas price, gas limit, to address, value, data, v, r, and s. These fields are , to look something like this:

Ethereum has evolved to support multiple types of transactions to allow for new features such as access lists and to be implemented without affecting legacy transaction formats.

is what allows for this behavior. Transactions are interpreted as:

The Electroneum Smart Chain has introduced a new typed transaction in ETNIP-1, called Priority Transactions. This new transaction type follows the envelope, where:

EVM
More on Gas
JSON-RPC
Recursive Length Prefix (RLP)
application binary interface (ABI)
encoded as specified in the ABI specs↗
this transaction↗
known functions with this signature↗
the contract source code↗
4f6742badb049791cd9a37ea913f2bac38d01279↗
gas
RLP-encoded
EIP-1559↗
EIP-2718↗
EIP-2718
EIP-2718: Typed Transaction Envelope↗
Accounts
Electroneum Virtual Machine (EVM)
Gas and fees
Accounts
Introduction to the Electroneum Smart Chain
Ethereum EVM illustrated↗
Ethereum EVM illustrated↗