Ethereum and Smart Contract Platforms

Introduction

Ethereum extended the blockchain idea from transferring digital currency to executing general-purpose programs. Its central innovation was a replicated execution environment in which independently operated computers process the same program and agree on its resulting state. These programs, commonly called smart contracts, can hold assets, enforce rules, emit records of activity, and interact with other contracts without a central operator.

Ethereum is therefore both a blockchain network and a programmable settlement platform. Its design combines accounts, transactions, the Ethereum Virtual Machine (EVM), a fee market, cryptographic signatures, event logs, token standards, and a consensus mechanism based on Proof of Stake (PoS). Understanding these components is essential for evaluating decentralised applications (dApps), decentralised finance (DeFi), non-fungible tokens (NFTs), and competing smart-contract platforms.

This chapter explains how Ethereum executes programs and compare its programmability, composability, cost, security, performance, and ecosystem trade-offs with other major platforms.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the EVM and Ethereum’s account and state model.
2. Distinguish externally owned accounts from contract accounts.
3. Describe transactions, gas, fees, receipts, logs, and events.
4. Explain common token standards, including ERC-20, ERC-721, and ERC-1155.
5. Describe Ethereum’s Proof-of-Stake consensus process and its security assumptions.
6. Analyse composability, scalability, programmability, and cost trade-offs.
7. Compare Ethereum with major smart-contract platforms.
8. Identify practical, governance, security, and regulatory risks.

1. Ethereum as a State-Transition System

A blockchain can be modelled as a sequence of states. Let Sₜ represent the complete system state at time t and Tₜ a valid transaction or ordered set of transactions. The protocol applies a deterministic transition function:

Here, Υ is the state-transition function. The result must be deterministic: honest nodes processing the same valid prior state and transactions should obtain the same next state. Ethereum’s state includes account balances, contract code, contract storage, and transaction-related information.

This model differs from a simple payment ledger. A payment system primarily records ownership changes, whereas Ethereum records the outcome of arbitrary, bounded computations. The computation is bounded because every operation consumes gas. Without such a limit, a malicious program could run indefinitely and prevent blocks from being processed.

Ethereum does not store every possible intermediate computation as permanent state. Instead, transactions cause changes to the current state, while blocks provide an ordered, authenticated history of those changes. Nodes validate the proposed block by re-executing transactions according to protocol rules.

2. Accounts and Addresses

Ethereum uses two fundamental account types.

2.1 Externally Owned Accounts

An externally owned account (EOA) is controlled by a private key. The corresponding public key and address identify the account, while the private key authorises transactions. EOAs:

• initiate transactions;
• hold Ether and tokens;
• have no smart-contract code; and
• rely on digital signatures for authorisation.

A private key is not a password that can be reset by Ethereum. Loss or compromise of the key generally means loss of control over the account. Wallet software normally manages keys and constructs transactions, but the user remains responsible for custody unless a custodial service is used.

2.2 Contract Accounts

A contract account is created at an address and contains:

• executable bytecode;
• persistent key-value storage;
• a balance; and
• protocol-defined account metadata.

A contract account cannot initiate a transaction independently. It acts when called by a transaction from an EOA or by another contract. Its code executes exactly according to the deployed bytecode, subject to the EVM rules. Contract addresses are deterministic in certain creation mechanisms, which is useful for deployment systems and account abstraction designs.

2.3 Account State

Conceptually, an account contains a nonce, balance, storage root, and code hash. The nonce prevents replay of a transaction and helps order actions from an account. The balance is denominated in wei, the smallest standard unit of Ether:

The storage of a contract is persistent between calls. Temporary memory and the execution stack are not persistent and disappear after execution.

3. The Ethereum Virtual Machine

The EVM is a deterministic, stack-based virtual machine. Contract source code, often written in Solidity or Vyper, is compiled into EVM bytecode. Nodes execute this bytecode using the same instruction semantics.

3.1 EVM Data Areas

The EVM uses several distinct data areas:

The stack has a bounded depth, and EVM instructions operate primarily on stack values. Storage is persistent but comparatively expensive because it contributes to the replicated state maintained by the network. Memory is temporary and expanded as needed during execution.

3.2 Determinism and Isolation

A contract cannot safely depend on arbitrary external information such as a website response during execution. Blockchain nodes must reach the same result, so external data enters through controlled mechanisms such as signed oracle reports. Block-related values, including timestamps, may be available, but they must not be treated as perfectly random or fully trustworthy.

A contract call can invoke another contract. This creates powerful composability but also introduces risks: reentrancy, unexpected return behaviour, gas exhaustion, and dependence on another contract’s availability or upgrade process.

3.3 Compilation and the ABI

The application binary interface (ABI) describes how applications encode function calls and decode results. A function call typically includes a selector derived from the function signature followed by ABI-encoded arguments. The ABI is not itself executable code; it is a communication convention between software and contracts.

The contract’s deployed bytecode is stored on-chain, while source code and metadata may be published separately for verification. Verification improves transparency but does not prove that a contract is safe.

4. Transactions, Calls, and Gas

A transaction is a cryptographically authorised request submitted to the network. It may transfer Ether, deploy a contract, or call a contract function. A transaction commonly specifies a recipient, value, input data, nonce, gas limit, and fee parameters.

A read-only call made locally or through an RPC provider can simulate contract execution without being included in a block. Such a call does not normally change state or incur an on-chain fee. A state-changing operation requires a transaction and must pay for the computation and resources it consumes.

4.1 Gas as a Resource Measure

Gas measures computational and storage work, rather than directly measuring time or Ether. Each EVM operation has a protocol-defined gas cost. Let Gᵤ be the gas actually used and Pᵍ the effective gas price in wei per unit of gas. The execution fee is:

F is measured in wei. The formula assumes that the transaction executes under the stated fee rules and excludes any separate application-level charges.

Under Ethereum’s EIP-1559-style fee market, a transaction specifies a maximum fee per gas and a priority fee per gas. The effective gas price is conceptually:

where Pₘₐₓ is the user’s maximum fee per gas, B is the block base fee per gas, and Pₚᵣᵢₒᵣᵢₜᵧ is the chosen priority fee. The base-fee component is burned, while the priority component is paid to the validator, subject to protocol rules. If the transaction’s maximum fee is below the required amount, it cannot be included under those conditions.

The user generally reserves gas_limit × Pₘₐₓ, but unused gas is not charged as execution cost. A transaction that runs out of gas reverts its state changes, although the consumed gas is still paid. A deliberate revert also consumes the gas used up to the point of failure.

4.2 Worked Example: Estimating a Fee

Suppose a transaction uses 80,000 gas. The base fee is 20 gwei and the priority fee is 2 gwei, so the effective gas price is 22 gwei, assuming the maximum fee is at least 22 gwei.

This is an estimate under the stated assumptions. The actual cost can differ if the transaction uses a different amount of gas or is included under different fee conditions.

Gas serves two related purposes: it allocates scarce block execution capacity and deters denial-of-service attacks. A poorly designed contract may be functionally correct but economically unusable if its gas consumption is excessive.

5. Transactions, Receipts, Events, and Logs

A transaction’s outcome is represented through its execution result and receipt. A receipt may include status, gas used, the resulting contract address for a deployment, and event logs. The transaction itself records the request; the receipt records important execution consequences after inclusion.

Events are Solidity-level abstractions over EVM logs. They are intended primarily for off-chain applications such as wallets, indexing services, analytics systems, and user interfaces. For example, a token transfer event allows an indexer to discover transfers efficiently.

Events are not a substitute for contract state. Contracts cannot normally query past logs as ordinary on-chain storage. Applications that require a value during contract execution must store or pass that value through state or call data. Indexed event fields, commonly called topics, support filtering but do not make events freely searchable by contracts.

Developers should emit events for important state changes, use stable and meaningful schemas, and avoid claiming that an event alone proves a business outcome. Off-chain systems must still verify the transaction, contract address, chain, confirmation status, and relevant state.

6. Smart-Contract Design and Security

Smart contracts are programs controlling assets under adversarial conditions. Common risks include:

• reentrancy, where an external call causes control to return before internal state is safely updated;
• incorrect access control;
• arithmetic or accounting errors;
• oracle manipulation;
• denial of service and gas exhaustion;
• unsafe upgrade mechanisms;
• signature replay or domain-separation errors;
• price and liquidity manipulation; and
• dependence on privileged administrators.

A standard defensive pattern is checks-effects-interactions: validate conditions, update internal state, and only then interact with external contracts. This is not a universal solution, but it reduces a common class of reentrancy vulnerabilities. Other practices include independent review, automated testing, invariant testing, formal verification where feasible, emergency controls with transparent governance, and careful dependency management.

Immutability is not absolute in all systems. Proxy contracts, multisignature administrators, governance modules, and upgrade keys can alter behaviour. Users should therefore assess both code and control structure.

7. Token Standards

Token standards are interfaces and conventions that allow independently developed applications to interoperate.

7.1 ERC-20 Fungible Tokens

ERC-20 defines common functions such as balance queries, transfers, approvals, and delegated transfers. Fungible tokens are interchangeable: one unit is intended to have the same type and value as another unit of that token.

The approval model can create risks. A user grants a spender an allowance, and the spender may later transfer up to that amount. Interfaces should make allowances visible, and users should avoid unnecessary unlimited approvals when practical.

7.2 ERC-721 Non-Fungible Tokens

ERC-721 represents individually identifiable tokens. Each token has a unique identifier within a contract. Ownership, transfer, approval, and metadata conventions enable uses such as digital collectibles, certificates, and tokenised access rights. Ownership of an NFT does not automatically establish copyright ownership or authenticity of every off-chain asset associated with it.

7.3 ERC-1155 Multi-Token Standard

ERC-1155 supports multiple token types in one contract, including fungible, non-fungible, and semi-fungible assets. Batch operations can reduce repeated transaction overhead. Its flexibility is useful in games and marketplaces, but applications must correctly interpret the contract’s metadata and supply rules.

Standards improve composability but do not guarantee quality, value, legal enforceability, or security. An application must distinguish an interface standard from the economic and governance assumptions of a particular token.

8. Composability and Decentralised Applications

Composability means that one contract can use another contract as a building block. A lending protocol may use a token contract, a price oracle, a decentralised exchange, and a liquidation module. This can accelerate innovation because developers reuse tested primitives rather than recreate entire systems.

Composability creates systemic dependencies. If a widely used oracle is corrupted, many applications may fail simultaneously. If a token’s transfer behaviour is unusual, an integrating protocol may become insolvent. Thus, composability is both a productivity advantage and a risk multiplier.

A dApp normally includes on-chain contracts, a user interface, wallet integration, RPC access, indexers, and sometimes centralised or decentralised storage. The user experience may appear centralised even when asset settlement is on-chain. Analysts should identify which components are permissionless, upgradeable, censored, or dependent on a single provider.

9. Ethereum Proof of Stake

Ethereum uses Proof of Stake to select validators and secure block production. Validators deposit stake, operate software, propose blocks when selected, and attest to blocks proposed by others. Consensus protocols determine which chain is final and how conflicting proposals are handled.

PoS replaces much of the energy expenditure of Proof of Work with economic collateral and penalties. A validator that behaves dishonestly or violates protocol rules may lose stake through penalties or slashing. A validator that is offline may lose rewards or incur relatively small losses, depending on the circumstances.

The security model depends on assumptions about stake distribution, validator participation, software correctness, network communication, and the ability to identify and penalise conflicting behaviour. PoS does not eliminate centralisation risk. Large custodians, staking pools, liquid-staking providers, and correlated software clients may create concentration or common-mode failure.

Finality should not be confused with instant irreversibility in every practical sense. Applications choose confirmation policies according to transaction value, network conditions, and their tolerance for reorganisation or operational risk. Validators and staking providers also face governance, custody, regulatory, and operational responsibilities.

10. Scaling and Layered Execution

Ethereum’s base layer provides broadly shared settlement and security, but block capacity is limited. High demand can increase fees and delay inclusion. Scaling approaches include:

• rollups, which execute transactions outside the base layer and publish data or proofs to Ethereum;
• sidechains, which use a separate consensus and security model;
• state channels, which move repeated interactions off-chain; and
• application-specific chains.

Rollups can reduce per-user costs, but users must consider bridge risk, withdrawal delays, sequencer operation, data availability, upgrade keys, and the maturity of fraud-proof or validity-proof systems. A cheaper transaction is not automatically equivalent to a transaction with Ethereum’s full security properties.

11. Comparing Smart-Contract Platforms

No platform simultaneously maximises decentralisation, throughput, low cost, simplicity, liquidity, and mature tooling. Comparison must specify the workload and security requirement.

11.1 Programmability

EVM-compatible systems provide portability of tools, languages, wallets, and contract patterns. However, compatibility is not perfect: opcode support, precompiles, fee schedules, execution limits, and bridge behaviour may differ. Solana’s account model and programming environment can support high-performance applications but requires different design assumptions. UTXO-derived models can provide explicit transaction structure and parallelisation advantages, but developers must reason differently about state and contract interaction.

11.2 Composability and Liquidity

A platform with many users, assets, stablecoins, exchanges, wallets, auditors, and developers may offer strong network effects. Yet composability within one chain is generally simpler than cross-chain composability. Bridges introduce additional contracts, validators or relayers, message-ordering assumptions, and failure modes.

11.3 Cost and Performance

Cost should be evaluated as total economic cost, including transaction fees, failed transactions, data publication, bridging, latency, slippage, and operational complexity. High throughput can lower nominal fees but may involve stronger hardware requirements or a smaller validator set. Conversely, stronger decentralisation may impose capacity limits.

11.4 Security and Governance

Security is not a single metric. It includes consensus security, client diversity, validator distribution, smart-contract quality, key management, upgrade governance, oracle reliability, and incident response. A chain’s technical design should be evaluated together with its actual operating ecosystem.

12. Illustrative Case: A Tokenised Equipment-Leasing dApp

Background

A university equipment cooperative wants members to reserve laboratory devices and pay deposits using a blockchain application. It proposes an ERC-20 deposit token, an ERC-721 token representing each reservation, and an automated refund process.

Problem

The cooperative needs transparent reservations, prevention of double booking, refundable deposits, and a way to handle damaged equipment. It also wants transaction costs low enough for students.

Analysis

A fully on-chain design can represent reservations and escrow conditions transparently. However, physical damage cannot be determined solely by code. The system therefore needs an authorised inspection process or oracle. The cooperative must also decide who can pause contracts, resolve disputes, and upgrade software.

Approach

The design uses:

1. an ERC-721 reservation token with a unique equipment and time-slot identifier;
2. an escrow contract holding deposits;
3. role-based permissions for equipment managers;
4. events for reservation, release, refund, and dispute actions;
5. a dispute deadline and multisignature approval for exceptional refunds; and
6. deployment on an Ethereum rollup after testing on a test network.

The contract checks that a time slot is unused before minting a reservation token. It updates reservation status before making an external payment call. The user interface displays the rollup, contract address, fee estimate, administrator powers, and dispute rules.

Outcome

The blockchain improves auditability and prevents unauthorised changes to recorded reservations, but it does not solve the physical inspection problem. The system remains dependent on the cooperative’s governance, key security, oracle process, and availability of the user interface. A rollup reduces routine costs but adds bridging and infrastructure considerations.

Learning Points

The case illustrates that smart contracts are strongest where rules are objective and digitally observable. They are weaker where facts depend on physical events, subjective judgement, or legal interpretation. Tokenisation creates interoperability only when the token’s rights and governance are clearly defined.

13. Governance, Legal, Ethical, and Professional Issues

Blockchain applications raise issues beyond code. Public transaction histories may expose financial or behavioural information. Data protection principles such as purpose limitation and data minimisation can conflict with permanent public records. Sensitive personal data should generally not be written directly to a public blockchain.

Token classification, consumer protection, taxation, anti-money-laundering obligations, securities regulation, and licensing vary by jurisdiction. Developers and organisations must obtain appropriate legal advice rather than assuming that decentralisation removes responsibility.

Ethically, teams should disclose administrator privileges, upgradeability, risks, fees, oracle dependencies, and conflicts of interest. Interfaces should not conceal irreversible transactions or use misleading claims of guaranteed returns. Accessibility matters because complex wallet flows can cause users to lose assets through phishing or signing errors.

Professionally, blockchain engineers need competence in secure software development, cryptography, distributed systems, economic incentives, incident response, and governance. Code audits are valuable but are not warranties. Responsible teams maintain deployment records, monitor events, document assumptions, and prepare recovery procedures.

14. Best Practices for Evaluation and Development

When evaluating a smart-contract platform or dApp:

1. Define the required trust and security model.
2. Identify which data and actions must be on-chain.
3. Estimate normal, peak, and failure-case transaction costs.
4. Examine contract permissions, upgradeability, and emergency controls.
5. Check oracle, bridge, RPC, indexer, and wallet dependencies.
6. Review token standards and non-standard token behaviour.
7. Test failure paths, reentrancy, access control, and economic manipulation.
8. Document governance, legal, privacy, and operational responsibilities.
9. Compare settlement security rather than headline throughput alone.
10. Communicate risks clearly to users.

A sound architecture minimises unnecessary on-chain data, separates critical roles, uses tested libraries, emits useful events, and treats private-key management as a primary security concern.

Contemporary Developments

Current platform development is increasingly multi-layered. Ethereum-compatible rollups, account abstraction, improved wallet recovery, zero-knowledge proofs, modular data availability, and cross-chain messaging are changing how users interact with applications. These developments may improve usability and scalability, but they also create additional trust assumptions and technical dependencies.

Account abstraction can make wallets behave more like programmable accounts, supporting sponsored fees, spending limits, and recovery mechanisms. Its benefits depend on wallet implementation, bundler or relayer infrastructure, and contract security. Zero-knowledge systems can prove computational claims without revealing all underlying data, but their cryptographic assumptions and operational complexity require careful assessment.

The central engineering question remains unchanged: which parties must be trusted, which rules must be independently verifiable, and what costs are acceptable for the application?

Chapter Summary

Ethereum is a programmable blockchain whose state changes through deterministic execution in the EVM. EOAs are controlled by private keys, while contract accounts contain code and persistent storage. Transactions request state changes; calls can simulate read-only execution. Gas measures computational and storage work, and transaction fees depend on gas used and the effective gas price.

Events and logs provide efficient records for off-chain applications but are not a replacement for contract state. ERC-20, ERC-721, and ERC-1155 establish widely used token interfaces, improving interoperability while leaving economic rights and security assumptions to individual implementations. Ethereum’s Proof-of-Stake system uses validators, attestations, economic incentives, and penalties, but its security still depends on decentralisation, software diversity, governance, and operational competence.

Smart-contract composability accelerates innovation but creates dependency and systemic risks. Platform comparison must consider programmability, composability, cost, throughput, settlement security, ecosystem maturity, governance, and cross-chain assumptions. Ethereum mainnet offers deep liquidity and mature tooling; rollups reduce costs with additional assumptions; alternative platforms may offer performance or customisation at different decentralisation and ecosystem trade-offs. Effective blockchain engineering combines technical design with economic, legal, ethical, and governance analysis.

Key Terms

Account: An Ethereum entity capable of holding assets and participating in state transitions.

ABI: A convention for encoding contract calls and decoding their results.

Composability: The ability of software components, especially contracts, to interact as reusable building blocks.

Contract account: An account containing executable bytecode and persistent storage.

EIP-1559 fee market: A fee mechanism using a base fee and priority fee.

ERC-20: A common interface for fungible tokens.

ERC-721: A common interface for individually identifiable non-fungible tokens.

ERC-1155: A multi-token interface supporting multiple asset types.

Event: A contract-level representation of an EVM log intended mainly for off-chain consumers.

Externally owned account: An account controlled by a private key.

Gas: A protocol unit measuring computational and storage work.

Layer 2: A system that processes transactions using infrastructure connected to a base blockchain.

Nonce: An account value used to order transactions and prevent replay.

Oracle: A mechanism that supplies externally observed data to a blockchain application.

Proof of Stake: A consensus approach using staked economic collateral and validator participation.

Rollup: A scaling system that executes transactions separately and posts data or proofs to a base layer.

Smart contract: Deterministic blockchain-resident software that can control assets and update state.

State transition: The protocol-defined transformation from one valid blockchain state to the next.

Validator: A participant that helps propose or attest to blocks in a Proof-of-Stake system.

Wei: The smallest standard denomination of Ether, with 10¹⁸ wei equal to one Ether.

Review Questions

Short Answer Questions

1. What is the difference between an externally owned account and a contract account?
2. Why is gas necessary in the EVM?
3. What information do events and logs provide to off-chain applications?
4. Distinguish ERC-20, ERC-721, and ERC-1155 tokens.
5. What is the role of a validator in Ethereum Proof of Stake?

Long Answer Questions

1. Explain the EVM’s stack, memory, storage, calldata, code, and log areas.
2. Describe Ethereum transaction execution, including nonce, gas limit, effective gas price, receipt, and possible reversion.
3. Analyse the advantages and risks of composability in decentralised applications.
4. Compare Ethereum mainnet, Ethereum rollups, and one alternative smart-contract platform in terms of cost, performance, security, and ecosystem.
5. Explain how Proof of Stake changes Ethereum’s security and energy model while introducing new centralisation and governance concerns.

Analytical / Application Questions

1. A dApp uses 120,000 gas at an effective price of 15 gwei. Calculate the fee in ETH and explain the assumptions behind the calculation.
2. Design an architecture for a blockchain-based equipment-rental application. Identify which rules can be automated and which require an oracle or human governance.
3. A protocol depends on one price oracle, one upgrade administrator, and a cross-chain bridge. Assess its main technical and governance risks and recommend mitigations.

Multiple Choice Questions with Answers

Question 1

Which Ethereum account type is controlled directly by a private-key signature and contains no contract bytecode?

A. Externally owned account

B. Contract account

C. Validator registry

D. Event account

Correct Answer: A. Externally owned account

Question 2

What is the primary purpose of gas in Ethereum?

A. To encrypt contract source code

B. To measure and price computation and storage work

C. To determine token ownership

D. To replace digital signatures

Correct Answer: B. To measure and price computation and storage work

Question 3

A transaction uses 50,000 gas at an effective price of 20 gwei. What is the execution fee?

A. 0.0001 ETH

B. 0.001 ETH

C. 0.01 ETH

D. 1 ETH

Correct Answer: B. 0.001 ETH

Question 4

Which standard is primarily associated with fungible tokens?

A. ERC-20

B. ERC-721

C. ERC-1155 only for non-fungible tokens

D. ABI-1

Correct Answer: A. ERC-20

Question 5

What is a principal limitation of blockchain events?

A. They cannot be observed by off-chain applications

B. They automatically become contract storage

C. They are not normally queryable by contracts as ordinary state

D. They can only contain Ether balances

Correct Answer: C. They are not normally queryable by contracts as ordinary state

Question 6

Under the EIP-1559-style fee model, which component is generally burned?

A. The nonce

B. The base fee

C. The contract bytecode

D. The event topic

Correct Answer: B. The base fee

Question 7

What is the main function of Proof-of-Stake validators?

A. To host all user interfaces

B. To propose and attest to blocks using staked economic collateral

C. To create private keys for users

D. To determine copyright ownership of NFTs

Correct Answer: B. To propose and attest to blocks using staked economic collateral

Question 8

Which feature best describes composability?

A. The inability of contracts to interact

B. The reuse and interaction of contracts as software building blocks

C. The conversion of all tokens into Ether

D. The removal of all governance

Correct Answer: B. The reuse and interaction of contracts as software building blocks

Question 9

Which token standard is designed to support multiple token types and batch operations?

A. ERC-20

B. ERC-721

C. ERC-1155

D. EVM-0

Correct Answer: C. ERC-1155

Question 10

Which statement is the most accurate comparison of smart-contract platforms?

A. Higher throughput always means stronger decentralisation

B. All EVM-compatible networks have identical security assumptions

C. Platform choice requires evaluating cost, programmability, security, governance, and ecosystem trade-offs

D. A token standard guarantees that a token has legal value

Correct Answer: C. Platform choice requires evaluating cost, programmability, security, governance, and ecosystem trade-offs