Ethereum - part 2 : Details

This is a sequel to Ethereum – Introduction where I covered Ethereum overview, transaction fees, smart contracts, blockchain trilemma and how Ethereum 2.0 solves that trilemma. In an earlier article Blockchain – How it works, I tried to explain how Bitcoin blockchain works. In this article (part 2 of the Ethereum series), I am explaining Ethereum specifics in little bit more detail.

Ethereum Entities

State Machine

As per yellow paper, Ethereum is a transaction-based state-machine. That means the state of the system is taken from A to B when transactions take place. In Ethereum, the state changes from block to block as per the predefined rules. Ethereum started with the genesis block and each incremental execution of transactions block morphs it into a new state. Every transaction modifies the state of accounts involved in that transaction.

Account

An Ethereum account is an entity that can receive and send transactions on Ethereum and can hold an Ether (ETH) balance. There are two types of accounts

1. Externally owned account: These are typically user accounts with 160-bit (40 characters) address derived from the private key of the holder.
2. Contract account: A smart contract deployed to the network. The account address is 160-bit and is generated at the time of creation taking into account the creator’s address and nonce.

Contents of the Account

Ethereum accounts have four fields

• balance: This denotes the balance of an account as number of WEI. One Ether has 1e+18 (one quintillion – billion billion) WEI.
• nonce: A counter that increments when a new transaction is sent by an account. It indicates the total number of transactions this account has sent till now. In a contract account this number indicates the number of contracts the account has created.
• storageRoot: This is a Keccak 256-bit hash of the storage content of the account and is empty when account is created. As the account state changes due to transactions, the storageRoot is recomputed and updated.
• codeHash: For contract accounts, this value is a 256-bit hash of the smart contract code. This code is executed when the contract account gets a message call. The code of smart contract is immutable, it cannot be changed once deployed, hence this value never changes. The codeHash for an externally owned account is equal to hash of an empty string.

World State

Collective state of all the accounts is the state of Ethereum as a whole. World state (or just state) is the mapping between account addresses and account states. The mapping implementation follows the Merkle Patricia tree (trie) structure and the root hash is stored as a stateRoot hash in the block headers. Thus, each block header secures the state which is stored off the chain. Most Ethereum clients use rocksdb or leveldb database to store the state trie.

Diagram adapted from link

How Ethereum is different than Bitcoin in this context? Bitcoin can be seen as a state transition system. An account in Bitcoin can have many UTXOs (unspent transaction outputs). Bitcoin blockchain doesn’t maintain the balance of each account as state. The account balance is computed as a sum of all UTXOs owned by it. The sum total of all the UTXOs of all accounts in the network is the state of the Bitcoin network as a whole. On the other hand, Ethereum stores the balances of each account as account state and the collective state of all accounts becomes the world state.

Transaction fee

In Ethereum, the transaction/network fee is charged with a pricing system called gas and must be paid upfront by the sender. Gas is calculated based on computation intensity of a transaction and space requirement of the output state. For example, a simple payment transaction requires 21,000 units of gas. If gas provided by sender is insufficient (runs out while running the transaction), an error of “Out of Gas” occurs and the transaction/smart contract execution halts and the state is reverted back to original. Such transactions are not included in the block.

Gas price is variable and is measured in terms of GWEI (giga-WEI).?Below are some unit conversions.

1 Gas = variable number of gwei;

1 Ether = 1 billion gwei; 1 gwei = 1 billion wei;

A simple transaction fee can be calculated as below assuming gas price at 150 gwei and Ether trading at US$ 4,500.

21,000 (gas) X 150 (gwei per gas) X 0.000000001 (Ether per gwei) X 4,500 (US$ per Ether) = 14.175 US$

Does it sound like the fee is high for a simple transfer, say 100 US$? Yes, it does. However, Eth2.0 is expected to have tremendous improvement in throughput (around 100,000 from current 14 transactions per second). This is expected to drastically bring down the transaction costs.

Ethereum Virtual Machine (EVM)

The Ethereum Virtual Machine is the runtime environment for executing smart contracts. Logically it does exist as a one single entity maintained by thousands of connected nodes running Ethereum client. All Ethereum clients implement EVM. Technically, EVM executes as a stack machine that runs transactions and contracts as EVM opcodes (code).

Transactions

Overview

An Ethereum transaction refers to an action initiated by an externally owned account. The simplest form of a transaction is transfer of ETH from one account to another. Contract accounts can not initiate transactions but they can send a message call to another contract account to execute.

When a sender submits a transaction, it includes the following information.

• nonce - a counter that indicates the number of transactions sent by the account (this is different from the nonce that PoW needs miners to find to solve the mining puzzle).
• from - the sender address, this can be only externally owned account.
• to - the receiver’s address.
• signature - is generated when the sender signs the transaction with their private key.
• value - is amount of WEI to transfer.
• data - optional field to include arbitrary data which can be parameters of a message call.
• init - optional field that specifies the EVM code for contract creation. This is provided in contract deployment type of transactions.
• gasLimit - the maximum amount of gas offered for transaction execution.
• maxPriorityFeePerGas - the maximum amount of fee per gas offered as a tip to the miner. Higher value incentivizes the miner to include the transaction in the next block.
• maxFeePerGas - the maximum amount of fee per gas, sender is willing to pay for the transaction inclusive of baseFeePerGas (comes from block header) and maxPriorityFeePerGas.

What is the different between baseFeePerGas and maxFeePerGas? The base fee is calculated for the next block based on the current block by the protocol. The base fee is not awarded to the miner but is burnt by the protocol, so what is the incentive for the miner to prioritize transaction? Here comes the priority fee as a guaranteed portion of the max fee the miner would receive. Still confused? Let us look at it in a little different way. A transaction sender must specify the gasLimit which covers the gas consumed by transaction. The price/fee for consumed gas is to be paid by the sender. For each gas unit, sender is willing to pay certain fee in GWEI. But the protocol sets the minimum fee as baseFeePerGas and that is burnt. However, sender can pay the tip to the miner with a priority fee @maxPriorityFeePerGas. Hence, the below equation always holds true.

maxFeePerGas >= baseFeePerGas + maxPriorityFeePerGas.

Transaction types

Regular transaction: This refers to transfer of ETH from one account/wallet to another, or a smart contract execution. These transactions can be initiated by externally owned accounts. A regular transaction results in a message call to either transfer ETH or execute a contract. Also, a contract can initiate a message call to execute another contract.

Contract deployment: A transaction containing the smart contract code to be deployed. This transaction does not contain the “to” address. As result deployment, a new address is generated and assigned to the newly created contract account. These transactions can be initiated by externally owned accounts only. Once deployed, the contract code cannot be changed or tampered, this is secured by the codeHash field in the account state, which is hashed in to the stateRoot.

Processing

Transaction processing takes place as below steps

• An externally owned account specifies the contents of the transaction as the from, to, value, gas, fee, data etc. then signs the transaction and submits it to the network.
• The transaction is broadcasted to the network and included in the transaction pool waiting to be included in a block. The waiting time depends on three factors like 1. How busy the network is at that time, 2. Amount of maxFeePerGas, 3. Amount of maxPriorityGasFeePerGas.
• Miners run proof-of-work algorithm to find a nonce that solves the puzzle and get the opportunity to mine the next block. A successful miner includes the transaction in the next block and propagates the block to the network.
• While assembling a block, miner executes the transactions and also updates the state of each account affected by the transaction and the world state thereby.
• After included in a block, transactions receive confirmations, which indicates the number of blocks created on top of that block.

Blocks

In an earlier article, I have explained in a bit detail about block mining and the consensus mechanisms. In this section let us see some more detail about Ethereum blocks.

An Ethereum block consists of header and transactions. I also mentioned that Ethereum is a state machine that maintains its state changes from block to block, so where is the state stored? State is stored as a separate database (implementation depends on Ethereum client - the Parity Ethereum uses rocksdb and Go Ethereum uses leveldb). However, the reference to the state is stored in the block header as stateRoot hash, this makes sure that state is not tampered by a malicious node.

Contents of Block

Each block contains the transactions that were picked by the miner from the transaction pool. A miner may not be able to include all the transactions in the pool, as there is a limit on the size of a block, explained below. Along with the transactions, an Ethereum block contains block header.

Below are some of the block header fields.

• timestamp – the time when the block was mined.
• blockNumber – the length of the blockchain in blocks.
• parentHash – hash of a previous block.
• baseFeePerGas - the minimum fee per gas required for a transaction to be included in the block.
• difficulty – a number that indicates the effort required to mine the block.
• stateRoot – hash of the world state trie root.
• transactionRoot – hash of the transactions trie root
• receiptsRoot – hash of the transaction receipts trie root
• mixHash – a unique identifier for that block.
• nonce - a number, when combined with the mixHash, proves that the miner has solved the computation puzzle and the block has gone through proof-of-work.

Block Time

Block time indicates the time it takes to mine a new block. While Bitcoin block time averages about 10 minutes, Ethereum block time averages between 12 to 14 seconds. The expected block time is set by the protocol and is compared with the current block time average. If the current block time average is shorter than the expected, protocol increases the difficulty to make it harder to mine a block.

Block Size

The block size is controlled by the gasLimit in the block header. Each block has a target size of 15 million gas units. If the network demand is high, the target size of the block can increase up to 30 million. The total amount of gas consumed by all the transactions in a block must be less than the target gas limit. This is important because the full nodes need to perform validation of a block when it is propagated by a miner. The validation process recomputes all the hashes and compares with the hashes included in the block header. If the block size is unlimited, then the less performant nodes may not be able to keep up with the process. Hence, it makes sense that the protocol specifies the size limit on each block.

References

https://ethereum.github.io/yellowpaper/paper.pdf

https://ethereum.org/en/whitepaper/

https://ethereum.org/en/developers/docs/