Ethereum Fundamentals
Ethereum World Computer denotes the blockchain network formed by connecting individual machines spread across the globe. These machines connected by the network are termed as nodes. The blockchain ledger is equipped to store smart contracts. Whenever a smart contract is deployed, each node in the network also gets a copy of the smart contract. If someone tries to invoke a function in the smart contract, this information is passed to all the nodes in the network. Each node can independently execute the function with the given input in their local copy of the smart contract and verify the result. The function invocations and their results are recorded as transactions on the blockchain ledger. Altogether this network simulates a single computer.
Such a decentralized global computer requires some properties for persistent functioning.
- Determinism
- Isolation
- Terminability
Any operation in Ethereum should give the same output for a given set of inputs in any distinct blockchain node. The network can’t reach a consensus if the outputs are different. As a result, there will be an inconsistency regarding the ledger entry.
As a public network, anyone can deploy smart contracts in Ethereum. If such programs contain malicious code, they may hamper the whole network. Similarly, other programs in the node should not affect the Ethereum network. Hence, an isolated environment is required for the secure functioning of Ethereum.
Being self-executing programs, there is no way to intervene and terminate a smart contract from execution. If the code contains an infinite loop, all the nodes attempting that specific code may also get trapped in an endless loop, which would eventually cause the Ethereum network to come to a halt. Thus, there should be checks to ensure terminability of operations.
To ensure the above properties, it is critical for a contract to be kept isolated in a sandbox to save the entire ecosystem from any negative effects. This sandbox environment is called Ethereum Virtual Machine.
The Ethereum Virtual Machine (EVM) is the runtime environment for smart contracts in Ethereum.
EVM Architecture
The components within an EVM may belong to a volatile machine state, a persistent world state or a virtual ROM.
This area corresponds to elements which depict the state of a smart contract execution. This is a volatile area and it changes with each instruction executed by the EVM.
- Program Counter stores the address of the next instruction to be executed.
- Stack is used by EVM for storing intermediate values in computations. It can hold 256-bit words and has a maximum size of 1024 elements.
- Gas available refers to the amount of gas paid by the originator of a transaction. Each basic instruction in a smart contract has an estimated effort (gas) assigned to it.
- The memory area holds temporary variables of a smart contract. It is only accessible during contract execution and the contents get removed between calls.
The machine state is cleared after processing each transaction.
Virtual ROM is an immutable area to which the code of the smart contract being executed is loaded. The smart contracts compiled into EVM bytecode are permanently stored in the blockchain, and loaded into virtual ROM whenever required for execution.
Ethereum’s world state is defined by the account balances, contract storage and more. The world state is persistent, the data will be retained as long as the blockchain is live.
Ethereum is a transaction-based state machine. Any network participant can initiate a transaction which may cause a state change. When a smart contract code is executed, the EVM updates the Ethereum state by computing valid state transitions as defined by the Ethereum protocol.
Before executing a transaction, the EVM is initialized with the required data. The ROM will be loaded with the code of that specific smart contract in bytecode format. The program counter is set to zero. The smart contract’s state will be loaded to the storage and the memory is initialized to all zeros. The gas available is set to the amount of gas paid by the transaction sender. As code execution progresses, the gas is reduced according to the cost of the required operations. If the gas hits 0, the execution will be halted. Otherwise, if the execution completes successfully, the remaining gas (if any) will be returned to the sender. Finally, the world state will be updated to reflect the state changes imposed by the transaction.
EVM has a pre-defined instruction set that supports only deterministic operations. The EVM executes smart contracts in an isolated environment which doesn't have direct access to the network, data or any other processes. A fee-meter mechanism is used to ensure program terminability. Consequently, each transaction execution has an associated fee corresponding to the total effort required. This pre-paid fee is represented in Ethereum’s native currency- Ether. The execution stops when the cost exceeds the pre-paid fee.
Thus EVM enforces the key properties required to maintain a decentralized world computer.
Gas refers to the unit that measures the computational effort required to execute specific operations on the Ethereum network. Just like how electricity is measured in units, fuel consumption is measured in litre, computational effort in Ethereum is measured in units of Gas. Once the effort is measured in gas, the fee for those specific units of gas is calculated in Ether, the native cryptocurrency of Ethereum. Gas fees are usually represented in wei, the smallest denomination of Ether.
Ether (ETH) is the native currency of Ethereum. Ether is a metric unit and it has different denominations. The smallest denomination or base unit is known as Wei. The denominations are named after the names of people who played important roles in the evolution of computer science and crypto-economics.
| Unit | Wei Value | Wei |
|---|---|---|
| wei | 1 wei | 1 |
| Kwei (babbage) | 1e3 wei | 1,000 |
| Mwei (lovelace) | 1e6 wei | 1,000,000 |
| Gwei (shannon) | 1e9 wei | 1,000,000,000 |
| microether (szabo) | 1e12 wei | 1,000,000,000,000 |
| milliether (finney) | 1e15 wei | 1,000,000,000,000,000 |
| ether | 1e18 wei | 1,000,000,000,000,000,000 |
Transactions are interactions among accounts in the Ethereum ecosystem. In our example, Alice is trying to transfer certain amount of Ether to Bob. This is an example for a transfer transaction, where a certain amount of Ether is transferred from one account to another. Let us see how this transaction is initiated and committed in Ethereum.
Transaction Flow
Alice used her Ethereum account to manage her Ether and perform the transactions. Basically, one requires an Ethereum account to interact with the network. An Ethereum account can hold or send Ether to another account on the Ethereum blockchain network. Ethereum has two main types of accounts: externally owned accounts (EOAs) and contract accounts. EOAs represent individual users and contract accounts represent a smart contract code. An account address may be generated offline. It gets recorded in the blockchain only if a transaction (Ether transfer or a code deployment) becomes associated with it.
- EOA can be created at no cost.
- Each EOA is controlled by a specific private key.
- They have no code associated with them.
- They can initiate a transaction- an Ether transfer or contract execution.
- Only Ether transfer can occur between EOAs.
- They have an associated code.
- Contract code execution is triggered by transactions received from other contracts or externally owned accounts.
- Contract accounts can be created using contract deployment transactions and have an associated cost.
- Contract accounts are controlled by contract code logic.
- They can only send transactions in response to another transaction.
Both account types can
- Receive, hold and send ETH and tokens.
- Interact with deployed smart contracts.
Ethereum contracts live in virtual ROM inside the Ethereum Virtual Machine and execute its functions when triggered by a transaction from an Externally Owned Account.
Address generation of EOA and contract account
In the case of externally owned accounts, the address is derived from the public key, which is, in turn, derived from the private key. The public key resembles a bank account number. Similarly, the private key corresponds to the secret PIN. The private key allows access to the account the same way a secret PIN does for the bank account. A private key is just a randomly picked 256-bit number. The public key is calculated from the private key using an irreversible function. EOA addresses are derived from the last 20 bytes of the Keccak-256 hash of the public key. EOAs are also termed user accounts, as these are controlled by users who own the private key.
The addresses of contract accounts are derived from the sender’s address (who has deployed the contract) and the nonce value associated with the sender's address.
Ethereum accounts have four fields:
- nonce - is a counter used to keep track of the number of transactions sent from a particular account address. This ensures that transactions are only processed once. In the case of a contract account, this value keeps track of the number of contracts created by the account.
- balance - the amount of Ether owned by the address, which is always specified in Wei. Wei represents the smallest denomination of Ether (ETH) where 1e18 wei is one Ether.
- codeHash - refers to the hash of the code associated with an account in the Ethereum Virtual Machine. Contract accounts have value in the codeHash field. Once assigned, this value cannot be changed. The codeHash value for externally owned accounts is the hash of an empty string.
- storageRoot - The 256-bit hash of the root node of a Merkle Patricia Trie, a structure used to represent the account storage.
The world state is represented by a data structure called modified Merkle Patricia Trie. It is stored by the nodes in a database, and the hash of the root node of this structure is used to identify the entire state.
Ethereum transactions are actions initiated by externally owned accounts. Transactions are the only elements that can change or update the Ethereum state. These transactions are broadcast to all the nodes in the Ethereum network.
A basic Ethereum transaction has the following attributes.
- nonce: Nonce in a transaction is a sequence number of transactions from an Ethereum account.
- gasLimit: It is the maximum amount of gas the user is happy to spend on a specific transaction.
- maxPriorityFeePerGas: the maximum amount of gas to be included as a tip for the validator.
- maxFeePerGas: the maximum amount of gas willing to be paid for the transaction (inclusive of baseFeePerGas and maxPriorityFeePerGas).
- to: destination account address; this is either an externally owned account (EOA) or a contract account.
- value: it represents the amount of Ether to be transferred from the sender to the receiver.
- digital signature: the digital signature generated by signing the transaction using the private key of the sender.
- data: the data field is for contract activities (deployment or execution of the contract).
Apart from the above basic structure, there are some specific types of transactions which have additional fields based on their purpose.
If you need to perform a transaction in Ethereum, a fee must be paid. Setting a fee for transaction executions prevents malicious actors from spamming the network. It also helps to prevent accidental infinite loops and encourages developers to create optimized code for execution in the EVM. In any case, the unused gas will be returned to the user. The gas is also a way in which EVM ensures the terminable nature of Ethereum World Computer i.e. once the allocated gas for an operation is consumed, the operation stops, irrespective of its completion status.
The base fee is the minimum price per unit of gas the user has to pay. The base fee will be burnt (destroyed by removing from circulation), so users are expected to include a tip (priority fee) in their transactions. The tip incentivizes validators to process transactions and is usually set automatically by wallets. The burning of the base fees is intended to make ETH deflationary.
Gas fees are usually represented in wei. Gas for every single operation is fixed. However, the smart contract code can be complex. For instance, a small piece of code can generate a lot of computational work if its underlying EVM instructions are costly. Similarly, a long piece of code can generate less computational work if its underlying EVM instructions are less expensive. Due to this factor, EVM expenses are calculated based on the measure of work done by the EVM.
Ethereum represents the state changes caused by transactions using a record-keeping method called the account-balance model. This system is similar to the traditional banking system.
The global state stores a list of accounts with balances, codes, and internal storage. A transaction is valid if the sending account has enough balance to pay for it. Once the transaction is processed, the value is debited from the sending account, and the receiving account is credited with the amount/value.
This simple record-keeping model is helpful for developers who develop complex smart contracts, mainly those that require state information. It also helps validate the sender's balance prior to transaction processing.
The Account-Balance Model may be exposed to double-spending attacks. Such attempts are prevented using an incrementing nonce. Each account has a globally accessible nonce, which is a sequence number. Every time a transaction is made from an account, the nonce is increased by one. This nonce value will also be included in the transaction. Even if double spending is attempted, the nonce mismatch can be used to detect it. A block having a transaction with an incorrect nonce is considered invalid.
The transactions are committed to the ledger in batches called blocks. A block may contain an ordered list of transactions along with some metadata. They are created by validators selected by the proof of stake consensus.
The blocks are strictly ordered in order to maintain the transaction history. Every new block will have a reference to the parent block (previous block). These references are hashes that are cryptographically derived from the data of the block. This prevents fraudulent activities because any change in the block data will change the hash and this can be detected. Thus Ethereum blockchain securely stores the transaction details in its blocks.
Ethereum uses multiple Merkle Patricia Tries to represent actual data corresponding to its state and transactions. The Keccak-256 hash of the root of these trie structures are inserted in the blocks. A detailed structure of the Ethereum block is available here.
The blocks are bound by a size limit. Each block has a gas limit, which is the total amount of gas that can be spent by all transactions in the block. Though the target size is 15 million gas, the size of blocks may vary according to network demands. It can increase until the maximum block limit of 30 million gas. The size limitation is imposed since processing an arbitrarily large block may limit the Ethereum network performance. Ethereum protocol will work properly only if all the participants in the network have the exact same copy of the blockchain ledger. This is ensured by the consensus mechanism.
The consensus mechanism defines the rules by which the participants agree on the same copy of the ledger. At the time of launch, Ethereum was based on proof of work consensus, where a miner was responsible for block creation. Later, a multi-stage upgrade plan for changing the consensus to proof of stake was devised. The first phase of the upgrade established the Beacon chain as a separate blockchain that runs on Proof of Stake consensus. Ethereum switched its consensus mechanism from proof of work to proof of stake once the merge between the beacon chain and the Ethereum mainnet was complete on September 15, 2022. Under the proof of stake consensus, a group of validators is responsible for creating blocks.
The Beacon Chain is the consensus engine, that enforces the proof of stake consensus in Ethereum. The beacon chain randomly selects validators for a block based on a pseudorandom process called RANDAO and manages the consensus mechanism. It stores a registry of validator addresses, the state of each validator, attestations (validator votes), and blob data. The Ethereum Beacon Chain is named after the randomness beacon, a cryptographic service that provides a public source of random numbers.
One can become a validator by depositing 32 ETH using a specific transaction in the deposit contract in the Ethereum mainnet. Once the deposit is made and detected by the nodes, the validator is activated. The validators are responsible for creating new blocks (block proposer) and voting on a proposed block (committee). When the block gets approved, the validators get a specific amount of newly created Ether as a reward. Validators are rewarded for honest behaviour and also penalized for dishonest behaviour. The rewards and penalties are decided based on the specific scenario. Accordingly, each validator’s deposit rises and falls with rewards and penalties.
Lifecycle of a validator
The validators are the participants in the proof of stake consensus. Under this scheme, time is divided into epochs, which are further subdivided into 32 slots of 12 seconds each. Before the start of an epoch, each slot is assigned a validator as a block proposer, and a specific group of validators(minimum 128) as validator committee. A validator can only be in one committee per epoch. There can also be more than one committee per slot. All the committees must be of the same size.
Working of proof of stake consensus in Ethereum
During each slot, its block proposer will select a block to append to the existing chain, and the committee will vote to add this to the main chain. These votes are termed attestations and are weighted by the validator’s deposit. The validators broadcast their votes, and a block that gets a two-thirds majority of validator votes is accepted. The majority is decided based on the weight of deposits rather than the number of validators. 2/3 rd majority refers to a set of validators whose total deposit size equals 2/3 of the total deposit size of that set of validators. The first block in an epoch is termed as a checkpoint. Only checkpoints can be justified and finalized.
The validator rewards in each epoch is calculated from a value called base reward. The base reward represents the average reward received by a validator per epoch. It is a dynamic value which depends on validator's effective balance and the number of active validators.
