Coding insights: What happens during a transaction in Ethereum?

Transactions are the core component of a blockchain, they are literally its building blocks. In this article we are going to look closely at the Ethereum transaction and figure out, what it consists of, how it is formed and happens to it during the life cycle.

Transaction properties

Every time when we send Ether to a friend, deploy a smart contract or call its function we send a transaction to the blockchain. Although content of this transaction may vary depending in the each of these use cases, it always have the same inner structure. So typically from the developer’s point of view Ethereum transaction is a JSON object











  1. from – address that will be used to sign transaction.

  2. nonce – a serial number of transaction sent from a particular address. So this is not a unique identifier in terms of the whole blockchain. But it is unique within that particular address, its sender. It starts with 0 and usually is incremented by 1 for every next transaction (if you’d like to be processed as soon as possible). For example, Alice want to send some Ether to Bob and her last transaction had nonce of 10. Though it isn’t a mistake for her to specify transaction nonce as 12 and not 11, such transaction will not be processed prior to transaction with nonce 11. That means sooner or later Alice wants to send transaction with nonce of 11.

  3. data – information about function to be called or contract to be deployed. If transaction is standard Ether transfer the data is “0x0”. We’ll speak more about how data is formed a bit later.

  4. gas – amount of gas you provide for transaction execution. This may vary from a couple of thousands for simple ether transfer to several millions in case of big smart contracts deployment. The more complicated transaction work is, the more gas is required. If you provide not enough gas for the transaction to have its ‘job’ executed the whole transaction will fail and revert. Moreover the gas fee will not be refunded. However if you provide more gas than needed, the unspent gas will be refunded back to you.

  5. gasPrice – how much wei you are going to pay for one gas unit. In order for the transaction to be processed and included in the blockchain you should pay some fee to the miners – those who create new blocks. The more you pay, the faster your transaction will be processed. But there is no point in paying too much, usually it is enough to pick standard price at

  6. value – amount of wei to send with transaction. This amount will be transferred to the destination address. Please note that just like gasPrice this is amount of wei, not ether. 1 ether is 1000000000000000000 wei (1e18 wei).

  7. to – destination address. In case of ether transfer it is the address of receiver. In case of contract’s function call, it is the address of smart contract, in case of new contract deployment this parameter is omitted.


The ‘data’ field

Unlike other intuitive fields, transaction data is a bit trickier. Its value depends on transaction purpose. If transaction is meant to execute contract’s function, data should be set to function selector concatenated with encoded function input parameters. That way destination contract is told what function to execute and what its parameters are.

For example we have function

function setBoolData(bool value)

and we want to call setBoolData(true)

To determine its selector keccak256 hash function is applied to its name and parameter types. First 4 bytes (8 hex symbols) is selector.

keccak256(‘setBoolData(bool)’) =  224a898cf0cd7a3e89ba88d71c6c8ae796289ee4dc37fdf7e246725b450e5366

 Function selector for this function is 0x224a898c. Next we should encode bool parameter to 32-bytes integer, which is


 so the data field for this call should be set to


In case of contract deployment data field should contain the whole contract’s bytecode concatenated with constructor parameters. .

How it is signed, broadcasted and mined

At last our transaction is formed. Can it be sent directly to blockchain? No.

First it should be signed. That way everybody can be ensured that you have permissions to act on behalf of the from address.There are several ways to sign the transaction:

  1. If you have local node like Geth or Parity and appropriate private keys are stored there, then transaction signing could be handled by these programs. They sign and broadcast your transaction.
  2. Not everyone wants to run a local node but probably everyone heard about Metamask. These web browser extension not only creates new wallets from the initial seed phrase, it also is capable of importing already known private keys and existing keystore files. Metamask also can sign your transaction if private key is stored there and broadcast it to its remote nodes.
  3. Finally you can save transaction to text file and sign it on any other device, even disconnected from any network. For example it may contain offline version of MyEtherWallet or similar software for signing the transaction. You also may connect hardware keystores like Trezor or Ledger to it and sign the transaction even more securely.

After the transaction is signed it should be broadcasted to the network. It can be done either in automatic mode (if using local node or Metamask extension) or manually (if it was signed offline). For example, provide such service.

Finally transaction is picked by a miner node and included in new block. For simplicity we’ll omit the details on how this process looks. From that moment on transaction is a part of blockchain forever. 

Searching for expert coding insights or to provide your programming skills? Learn more:

Comments are closed.