Ethereum
Unit II Ethereum deck (architecture, transaction lifecycle, blocks and confirmations, gas and fees, Proof of Stake, state, applications) plus the exam-relevant parts of Buterin's 2014 Ethereum white paper: Bitcoin Script limits, accounts, messages and transactions, the state transition function, EVM code execution, block validation, ether units and applications.
What is EthereumSearch on YouTube
Ethereum is a decentralized blockchain network and programmable platform.
- It supports ETH transfers and interactions with smart contracts.
- Smart contracts are programs executed by the Ethereum Virtual Machine (EVM).
- Applications include dApps, DeFi, tokens, NFTs and DAOs.
Bitcoin is a shared ledger of who owns which coins. Ethereum is a shared computer: its ledger also stores programs and their data, and every node runs the same program to agree on the result.
High-level Ethereum architectureSearch on YouTube
- Users and wallets create and sign transactions.
- The Execution Layer processes transactions and smart-contract code through the EVM.
- The Consensus Layer coordinates validators and supports agreement and finality.
- Blocks record chain activity and state transitions.
The deck's figure shows three blockchain layers of Ethereum:
| Layer | Contains |
|---|---|
| Layer 1 | Hardware (network) |
| Layer 2 | Software (smart contracts) |
| Layer 3 | Applications (dApps) |
Ethereum transaction lifecycleSearch on YouTube
- Create and sign the transaction.
- Broadcast it to the network. It may wait in the transaction pool.
- A validator includes it in a block.
- The transaction executes and changes Ethereum state.
- Later blocks provide confirmations.
Some Boys Invent Electric Cars: Sign, Broadcast, Include, Execute, Confirm.
Ethereum blocksSearch on YouTube
- A block is a unit of blockchain data processed by the network.
- It contains transactions and execution and consensus-related information.
- Blocks are linked sequentially using cryptographic references (the parent hash).
- The block number identifies a block's position in the chain.
Block number vs confirmationsSearch on YouTube
Example: a transaction is included in block 20,000,000.
| Block | Confirmations |
|---|---|
| 20,000,000 | Included |
| 20,000,001 | 1 |
| 20,000,002 | 2 |
| 20,000,003 | 3 |
| 20,000,004 | 4 |
This is the common counting. Some explorers count the inclusion block as the first confirmation.
Gas and transaction feesSearch on YouTube
Gas is the unit that measures the computational work an Ethereum transaction needs. Users pay fees for the resources their transactions consume.
| Operation | Approximate gas |
|---|---|
| ETH transfer | About 21,000 gas |
| Simple smart-contract operation | More than 21,000 |
| Complex DeFi transaction | Can require much more |
Gas limit, gas used and gas priceSearch on YouTube
- Gas limit: the maximum gas the sender allows the transaction to consume.
- Gas used: the actual gas consumed.
- Gas price: how much ETH is paid per unit of gas, usually quoted in Gwei.
Values from the deck's transaction.
Step 1. Gas limit = 29,022. Gas used = 29,010. Unused gas = 29,022 − 29,010 = 12.
Step 2. Percentage used = (29,010 / 29,022) × 100 ≈ 99.96%. The transaction used almost all of its limit.
Step 3. Gas price = 0.882463951 Gwei = 0.000000000882463951 ETH.
Step 4. Fee = 29,010 × 0.882463951 Gwei ≈ 25,600.28 Gwei ≈ 0.0000256 ETH. The deck shows 0.00002560027921851 ETH, about $0.07.
The fee uses gas used, not gas limit. Unused gas is not charged. But if execution runs out of gas, the state changes revert and the gas is still paid.
How gas regulates cost and inclusion timeSearch on YouTube
- Every EVM operation has a fixed gas cost, so heavier computation costs more.
- The gas limit stops infinite loops: execution halts when gas runs out.
- Validators prefer transactions paying a higher gas price (tip). Offering a higher price usually gets a transaction into a block sooner; a low price may wait longer in the pool.
- Each block has a gas limit, so block space is scarce and priced by demand.
Ethereum consensus: Proof of StakeSearch on YouTube
- Ethereum uses Proof of Stake (PoS).
- Validators participate by staking ETH and following protocol rules.
- Validators propose and attest to blocks.
- Consensus helps the network agree on a canonical chain and supports finality.
Finality is distinct from confirmations. Confirmations count blocks built on top. Finality is a protocol guarantee from the consensus layer that a block will not be reverted.
Ethereum 2.0 (exam context)Search on YouTube
These points go beyond the deck but answer the "Ethereum 2.0" question in past papers.
- "Ethereum 2.0" is the upgrade that split Ethereum into the execution layer and the consensus layer (Beacon Chain) and moved it from PoW to PoS in The Merge (September 2022).
- A validator stakes 32 ETH. Time is divided into slots of 12 seconds, with one proposer per slot and a committee of attesters.
- Misbehaving validators lose part of their stake (slashing).
- Energy use fell by about 99.95%, since no mining is needed.
- Scaling relies on rollups (Layer 2) and data sharding, which raise throughput for large deployments such as IoT.
Ethereum stateSearch on YouTube
- Ethereum keeps a global state: account information, balances, contract code and contract storage.
- Transactions cause valid state transitions.
- Programmability lets contracts make complex state changes beyond simple transfers.
Ethereum applicationsSearch on YouTube
- Decentralized Finance (DeFi)
- Stablecoins and tokenization
- NFTs and digital assets
- DAOs and governance systems
- Gaming and decentralized applications
- Identity and other programmable blockchain services
Key takeaways from the deckSearch on YouTube
- Ethereum is a programmable blockchain platform.
- Blocks organize and record chain activity.
- Block number identifies a block's position.
- Confirmations count blocks built after a transaction's block.
- Gas measures computational work and supports fee payment.
- Proof of Stake coordinates consensus; finality is distinct from confirmations.
- Smart contracts execute through the EVM.
White paper: why EthereumSearch on YouTube
Vitalik Buterin's 2014 white paper argues that Bitcoin's scripting language has four limitations:
| Limitation | Meaning |
|---|---|
| Lack of Turing-completeness | No loops, to avoid infinite loops during verification. Loops must be unrolled, which makes scripts space-inefficient |
| Value-blindness | A UTXO script cannot finely control the amount withdrawn; UTXOs are all-or-nothing |
| Lack of state | A UTXO is either spent or unspent; no multi-stage contracts with internal state |
| Blockchain-blindness | Scripts cannot see blockchain data such as the nonce and previous hash, a useful source of randomness |
Ethereum's answer is a blockchain with a built-in Turing-complete programming language. Anyone can write smart contracts and decentralized applications with their own rules for ownership, transaction formats and state transition functions.
The Very Smart Blockchain: Turing-incomplete, Value-blind, Stateless, Blockchain-blind.
White paper: Ethereum accountsSearch on YouTube
The state is made of accounts. Each has a 20-byte address. State transitions are direct transfers of value and information between accounts.
An account has four fields:
- Nonce: a counter so each transaction is processed only once.
- Ether balance.
- Contract code, if present.
- Storage (empty by default).
Ether is the internal crypto-fuel of Ethereum, used to pay transaction fees.
| Externally owned account (EOA) | Contract account | |
|---|---|---|
| Controlled by | Private key | Its contract code |
| Code | None | Yes |
| How it acts | Sends messages by creating and signing a transaction | Code activates each time it receives a message; it can read and write storage, send messages and create contracts |
White paper: messages and transactionsSearch on YouTube
Messages are like Bitcoin transactions, with three differences:
- A message can be created by an external entity or a contract. A Bitcoin transaction can only be created externally.
- Messages can explicitly contain data.
- If the recipient is a contract, it can return a response. So messages also act as function calls.
A transaction is the signed data package that stores a message sent from an externally owned account. It contains:
| Field | Purpose |
|---|---|
| Recipient | Address of the message receiver |
| Signature | Identifies the sender |
| Amount of ether | Value to transfer |
| Data | Optional input (for example function arguments) |
| STARTGAS | Maximum number of computational steps the transaction may use (today called the gas limit) |
| GASPRICE | Fee paid to the miner per computational step |
- STARTGAS prevents exponential blowup and infinite loops.
- If execution runs out of gas, all state changes revert except the fee payment.
- If execution halts with gas left, the remaining fee is refunded to the sender.
- A contract-creation transaction has its own type. The contract's address is calculated from the hash of the account nonce and transaction data.
Contracts have the same powers as external accounts (the "first class citizen" property): they can send messages and create other contracts.
White paper: state transition functionSearch on YouTube
The state transition function APPLY(S, TX) -> S':
- Check the transaction is well-formed, the signature is valid, and the nonce matches the sender's account nonce. If not, return an error.
- Calculate the fee as STARTGAS × GASPRICE. Find the sender from the signature. Subtract the fee from the sender's balance and increment the sender's nonce. If the balance is too low, return an error.
- Initialize GAS = STARTGAS and subtract a quantity of gas per byte to pay for the bytes in the transaction.
- Transfer the value from sender to receiver. Create the receiving account if it does not exist. If the receiver is a contract, run its code to completion or until gas runs out.
- If the transfer failed (not enough money) or code ran out of gas, revert all state changes except fee payment, and add the fees to the miner's account.
- Otherwise, refund the fees for remaining gas to the sender and send the fees for gas consumed to the miner.
The white paper's worked example. Contract code (Serpent): if contract.storage[msg.data[0]] is empty, set it to msg.data[1]. Transaction: 10 ether value, 2000 gas, 0.001 ether gas price, data [2, 'CHARLIE'].
Step 1. Check the transaction is valid and well-formed.
Step 2. Sender needs at least 2000 × 0.001 = 2 ether; subtract 2 ether.
Step 3. gas = 2000. The transaction is 170 bytes and the byte fee is 5, so subtract 850. 1150 gas left.
Step 4. Subtract 10 more ether from the sender and add it to the contract.
Step 5. Run the code: storage index 2 is unused, so set it to CHARLIE. This takes 187 gas, leaving 1150 − 187 = 963.
Step 6. Refund 963 × 0.001 = 0.963 ether to the sender. Return the new state.
White paper: code execution (EVM)Search on YouTube
Contract code is a low-level, stack-based bytecode called EVM code. Each byte is an operation. Execution repeatedly runs the operation at the program counter (starting at zero) and increments it, until the end of the code, an error, or a STOP or RETURN instruction.
Operations can store data in three places:
| Space | Description | Lifetime |
|---|---|---|
| Stack | Last-in-first-out container of 32-byte values | Resets after computation |
| Memory | Infinitely expandable byte array | Resets after computation |
| Storage | Contract's key/value store; keys and values are 32 bytes | Persists long term |
Code can also read the incoming message's value, sender and data, and block header data. It can return a byte array.
The EVM's full state is the tuple (block_state, transaction, message, code, memory, stack, pc, gas). Examples: ADD pops two items, pushes their sum, reduces gas by 1 and increments pc by 1. SSTORE pops two items and stores the second at the index given by the first, costing up to 200 gas.
White paper: blockchain and miningSearch on YouTube
Unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state. Blocks also store the block number and difficulty.
Block validation:
- Check the referenced previous block exists and is valid.
- Check the timestamp is greater than the previous block's and less than 15 minutes into the future.
- Check the block number, difficulty, transaction root, uncle root and gas limit are valid.
- Check the proof of work is valid (the 2014 design used PoW; today this is PoS).
- Let
S[0]be the STATE_ROOT of the previous block. - For each transaction,
S[i+1] = APPLY(S[i], TX[i]). Return an error if any fails or total gas exceeds GASLIMIT. - Let
S_FINALbeS[n]plus the block reward paid to the miner. - The block is valid if
S_FINALequals the block's STATE_ROOT.
The state is stored in a Patricia tree (a modified Merkle tree that supports efficient insert and delete). Adjacent blocks share most of the tree, so storing state each block is cheap.
White paper: ether denominationsSearch on YouTube
| Unit | Value in wei |
|---|---|
| wei | 1 |
| szabo | |
| finney | |
| ether |
Gwei (giga-wei, wei) is the unit used for gas prices today.
White paper: applicationsSearch on YouTube
Three categories of applications:
- Financial: sub-currencies, financial derivatives, hedging contracts, savings wallets, wills, employment contracts.
- Semi-financial: money is involved but there is a heavy non-monetary side, for example self-enforcing bounties for computational problems.
- Non-financial: online voting and decentralized governance.
| Application | Idea |
|---|---|
| Token systems | A database with one operation: subtract X from A and give X to B, if A has at least X and A approved it |
| Financial derivatives and stable-value currencies | Hedging contract: A and B each deposit 1000 ether; after 30 days A gets back the original USD value using a price data feed, B gets the rest |
| Identity and reputation | Namecoin-like name registration: register a name once, it sticks forever |
| Decentralized file storage | "Decentralized Dropbox": split and encrypt the file, build a Merkle tree, pay whoever proves they still hold a random block |
| DAOs | Members (for example a 67% majority) control the funds and can modify the code |
| Further applications | Savings wallets, crop insurance, decentralized data feeds (SchellingCoin), smart multisignature escrow, cloud computing, peer-to-peer gambling, prediction markets, on-chain marketplaces |
Bitcoin vs EthereumSearch on YouTube
| Feature | Bitcoin | Ethereum |
|---|---|---|
| Main purpose | Digital currency | Programmable platform for smart contracts and dApps |
| Consensus | Proof of Work | Proof of Stake (since 2022) |
| Block producers | Miners | Validators staking ETH |
| Block time | About 10 minutes | 12-second slots |
| Ledger model | UTXO | Accounts (EOA and contract) with global state |
| Scripting | Bitcoin Script: stack-based, not Turing complete | EVM bytecode (Solidity): Turing complete, bounded by gas |
| Fees | Input minus output value | Gas used × gas price |
| Currency | BTC, fixed supply of 21 million | ETH, units wei to ether |
Quick self-testSearch on YouTube
What are the two layers in Ethereum's architecture and what does each do?
The execution layer processes transactions and contract code in the EVM. The consensus layer coordinates validators and supports agreement and finality.
List the five steps of the Ethereum transaction lifecycle.
Create and sign; broadcast (may wait in the pool); validator includes it in a block; it executes and changes state; later blocks give confirmations.
A transaction is in block 100 and the current block is 106. How many confirmations?
106 − 100 = 6 confirmations.
Gas used is 21,000 and the gas price is 10 Gwei. What is the fee?
21,000 × 10 = 210,000 Gwei = 0.00021 ETH.
What happens if a transaction runs out of gas?
All state changes revert, but the fee for gas consumed is still paid to the block producer.
Name the four fields of an Ethereum account.
Nonce, ether balance, contract code (if any) and storage.
How do EOAs and contract accounts differ?
An EOA is controlled by a private key and has no code. A contract account is controlled by its code, which runs whenever it receives a message.
Name the four limitations of Bitcoin Script from the white paper.
Lack of Turing-completeness, value-blindness, lack of state and blockchain-blindness.
What are the three data areas of the EVM and which one persists?
Stack, memory and storage. Only storage persists after execution ends.
How does Ethereum's consensus differ from Bitcoin's?
Bitcoin uses Proof of Work with miners. Ethereum uses Proof of Stake: validators stake ETH, propose and attest to blocks, and the consensus layer provides finality.
- Ethereum is a programmable blockchain; smart contracts run on the EVM.
- Architecture: wallets sign; execution layer runs the EVM; consensus layer (PoS) gives agreement and finality.
- Lifecycle: sign, broadcast, include, execute, confirm; confirmations = current block − transaction block.
- Fee = gas used × effective gas price; 1 Gwei = 10⁻⁹ ETH; a plain transfer costs about 21,000 gas.
- Accounts: nonce, balance, code, storage; EOAs use keys, contracts use code.
- APPLY(S, TX): check, charge STARTGAS × GASPRICE, transfer, run code, revert on failure, refund unused gas.
- The white paper fixes Bitcoin Script's four limits with a Turing-complete language bounded by gas.