Transactions

The Ethereum Virtual Machine (EVM) does not run on its own—everything always starts with an EOA sending a transaction. Transactions are signed messages transmitted to the Ethereum network and are the only things that can change the world state. Only EOAs can initiate a transaction by signing a particular kind of message and sending it to a network node.

There are four types of transactions:

• Regular: A cryptocurrency transfer from one account to another.

• Contract deployment: A special transaction used to upload a smart contract code into the world state.

• Contract execution: A transaction used to execute the code of a deployed smart contract.

• Internal: Smart contracts can not initiate transactions, but when their execution is triggered (by an execution transaction), they can run other smart contracts by so-called internal transactions.

The London upgrade

In August 2021, The Ethereum London upgrade in changed the way transaction fees are calculated. The upgrade was introduced to address the scalability and fee market pressure of the Ethereum blockchain. Specifically, it realized a new fee market structure to replace the previous gas price auction mechanism.

Before the upgrade, the total transaction fee was calculated as:

After the upgrade, a single base fee is set by the protocol and adjusted periodically. The base fee changes according to the current network demand, which was intended to help reduce network congestion.

A sender can add a tip to the base fee. The tip is an incentive for the validator prioritize the transaction and for this reason, the tip is called a priority fee. The higher the tip, the more likely a transaction will be included in the block. The fee is now calculated as follows:

Finally, the base fee is burned rather than sent to validators (this is part of the burning process of Ethereum triple halving). Only the tip is used as a reward.

Transaction structure

Originally, Ethereum had a single transaction format, but evolved to support multiple types of transactions to be more flexible when new features are to be implemented (such as with the London upgrade).

The general structure of a transaction includes the following information:

• recipient: The recipient’s account address.

• signature: To confirm the sender has authorized a transaction.

• nonce: The number of transactions originated from the sender’s account.

• value: The amount of Wei to transfer to the recipient’s address.

• data: Encoded data payload.

• gasLimit: The maximum amount of gas units that the sender is willing to use for a transaction.

• maxPriorityFeePerGas: The maximum tip (in Wei) to give to the validator to encourage them to include the transaction in a block.

• maxFeePerGas: The maximum amount of Wei the sender is willing to pay for a gas unit (it includes both the base fee and the maxPriorityFeePerGas).

Note: Before the upgrade, the gasPrice field was used instead of maxPriorityFeePerGas and maxFeePerGas.

Something that might seem strange at first glance is the lack of the sender’s address in the transaction info. However, this information would be redundant because the EOA’s public key can be derived from the signature, and, in turn, the address can be derived from the public key.

Next, the transaction message’s structure is converted into a sequence of bytes (serialization). The serialization process does not lose information; the bytes can be converted back to the original message (deserialization). Serialization is used because it’s a more compact and convenient way to send messages over a network.

Regular transactions

Transferring Ethers from one account to another is the simplest transaction type on Ethereum. This transaction is better known as payment and always uses a fixed amount of gas units (21,000).

The transaction has the following characteristics:

• The recipient address must be an EOA.

• The value field must be greater than 0.

• The data field must be empty. 

A user has to pay attention to the recipient address being used because sending ethers to an unknown and casual account will probably render them forever inaccessible. It’s impossible to calculate the private key related to a casual address. Without the private key, it’s impossible to access the transferred funds and they will be rendered unspendable (burned).

The following example shows a payment transaction from Paul to Alice. Let’s suppose that:

• Paul sends 1 ETH to Alice

• baseFeePerGas is 150 Gwei

• maxPriorityFeePerGas is set to 10 Gwei

Paul pays a transaction fee of: