Ethereum & Solidity

Chapter 1
Blockchain and Ethereum Foundations

Diploma in Blockchain
Ethereum & Solidity • Diploma

Blockchain and Ethereum Foundations

Introduction and Context

Blockchain technology combines distributed computing, cryptography, economic incentives and software protocols to maintain a shared record without requiring one organisation to control every transaction. Ethereum extends this idea beyond a payment ledger: it provides a programmable environment in which users can deploy smart contracts and applications whose state is recorded by a network of independent computers.

Understanding these foundations is essential before learning Solidity. Solidity code does not execute in isolation. It is compiled into bytecode, deployed to the Ethereum network, executed by validators, and governed by protocol rules concerning accounts, transactions, fees, consensus and finality. A developer who understands only syntax may write code that compiles but misunderstands security, cost or trust assumptions.

Learning Objectives

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

explain distributed ledgers and the role of network nodes;
describe cryptographic hashing and public-key signatures;
distinguish centralised, distributed and decentralised systems;
explain consensus, immutability and smart contracts;
compare Bitcoin and Ethereum;
describe Ethereum’s Proof-of-Stake system, validators, staking and finality;
explain cryptoeconomic incentives, penalties and governance concerns;
identify practical limitations and appropriate use cases for blockchain systems.

1. Centralised, Distributed and Decentralised Systems

A centralised system has a primary authority that controls data, access and rule enforcement. A commercial bank, for example, maintains an authoritative database of account balances. Centralisation can provide speed, operational simplicity and clear accountability, but it creates dependence on the operator and a concentrated point of failure or control.

A distributed system consists of multiple computers that communicate over a network. Distribution improves availability and can support geographical redundancy, but it does not automatically remove central control. A company may operate a distributed database across many data centres while retaining complete authority over it.

A decentralised system distributes control among independent participants. No single participant should be able to rewrite the record or arbitrarily exclude valid users. Decentralisation is a spectrum rather than a binary property. It depends on factors such as the number and diversity of validators, client implementations, geographic distribution, concentration of infrastructure and governance power.

A blockchain is a type of distributed ledger. It stores records in ordered blocks, where each block refers cryptographically to the previous block. Nodes maintain copies or partial views of the ledger and use a consensus protocol to agree on its valid history.

2. The Blockchain Data Model

A blockchain ledger records transactions and the resulting state. In a simple payment system, state may consist of account balances. In Ethereum, state includes accounts, contract storage, balances, code and other protocol data.

A block generally contains:

a reference to a preceding block;
a set of transactions or transaction-related data;
consensus information;
commitments, such as a root that summarises a large state structure;
metadata used to validate ordering and protocol rules.

The exact structure changes as protocols evolve, so it is better to understand the principles than to memorise one implementation detail. A block is accepted only if it satisfies protocol rules and is connected to an accepted chain history.

Hash-linked records

A cryptographic hash function maps an input of arbitrary length to a fixed-length output. For a hash function H, a record may contain the previous block’s hash:

h_i = H(B_i)

where B_i is block i and h_i is its digest. The next block stores h_i, creating a dependency between blocks. If an earlier block changes, its hash normally changes, which breaks the reference held by the following block.

A secure cryptographic hash is expected to have:

determinism: the same input gives the same output;
preimage resistance: it is computationally infeasible to recover an input from its digest;
second-preimage resistance: given one input, it is infeasible to find a different input with the same digest;
collision resistance: it is infeasible to find any two different inputs with the same digest;
avalanche behaviour: a small input change produces a substantially different output.

These properties do not make data magically permanent. They make undetected alteration computationally difficult when combined with replicated records and consensus. Hashes also do not provide confidentiality: anyone who can read the input can usually compute its hash, and a hash does not encrypt the original data.

Merkle commitments

Blockchains often summarise many transactions or state entries using a Merkle tree. Pairs of items are hashed repeatedly until one root hash remains. A participant can prove that an item belongs to the committed set using a path of sibling hashes rather than downloading the entire set. This improves verification efficiency, although the complete security and performance properties depend on the particular data structure and protocol.

3. Public-Key Cryptography and Digital Signatures

Blockchain accounts use asymmetric cryptography. A user generates a private key and derives a public key from it. The private key must remain secret; the public key may be shared. A digital signature demonstrates control of the private key corresponding to a public key without revealing that private key.

A simplified signature relationship can be represented as:

σ = Sign(sk, m)

where sk is the private signing key, m is the message and σ is the signature. Verification tests whether:

Verify(pk, m, σ) = true

where pk is the corresponding public key. The notation describes the function, not a complete implementation. Real signature schemes require carefully generated keys, secure randomness or deterministic signing, domain separation and protection against implementation errors.

In Ethereum, a transaction is signed by an account holder. Nodes verify the signature and check protocol conditions such as the sender’s account state, nonce and ability to pay the required fee. A valid signature proves authorisation by the key holder; it does not prove that the transaction is wise, legal or free from phishing.

Private-key loss is also important. If a private key is lost, the network generally cannot identify the owner through personal identity records and restore access. If the key is stolen, an attacker may sign valid transactions. Hardware wallets, secure backups, multisignature controls and carefully designed operational procedures reduce these risks.

4. Consensus and Immutability

Consensus is the process by which independent nodes agree on the valid ordering and state of transactions. Consensus must address several problems:

Which transactions are valid?
In what order should valid transactions be processed?
Which proposed block should be accepted when multiple proposals exist?
How should dishonest or unavailable participants be handled?

Consensus is not the same as unanimity. Protocols define rules under which honest participants converge, even if some participants fail or behave maliciously, subject to stated assumptions.

Immutability as an economic and technical property

Blockchain immutability is best understood as resistance to unauthorised revision, not an absolute impossibility of change. An attacker would need to overcome cryptographic protections, consensus rules, network participation and economic incentives. Recent data is generally more vulnerable to reorganisation than strongly finalised data, and protocol upgrades can intentionally change rules.

Immutability has several dimensions:

cryptographic integrity: altered data produces invalid commitments or signatures;
replication: many participants hold and verify the record;
consensus integrity: invalid histories are rejected;
economic security: attacks impose costs or risk penalties;
social and governance stability: participants continue recognising the same protocol history.

A blockchain should therefore not be described as an unchangeable database in every circumstance. It is a shared record whose history is difficult to alter under specified technical, economic and social assumptions.

5. Smart Contracts

A smart contract is a program deployed to a blockchain address. It contains code and persistent state. Users interact with it by submitting transactions or, where permitted, by making read-only calls. Contract execution is deterministic: nodes must be able to obtain the same result from the same state and input.

Smart contracts can implement:

token balances and transfers;
escrow and conditional payments;
decentralised exchanges;
lending and collateral rules;
voting mechanisms;
digital collectibles;
identity or credential registries;
automated business workflows.

A contract is not necessarily legally a contract, and “smart” does not mean intelligent. It is software whose execution is enforced by a protocol. Once deployed, changing its behaviour may be difficult or impossible unless upgrade mechanisms were designed in advance.

Ethereum uses the Ethereum Virtual Machine (EVM), a deterministic execution environment. Computation consumes gas, a unit used to meter resources and discourage denial-of-service attacks. A transaction fee is commonly expressed as:

Fee = GasUsed × EffectiveGasPrice

where GasUsed is the gas consumed, measured in gas units, and EffectiveGasPrice is the price paid per gas unit, measured in ETH per gas unit. The result is denominated in ETH. The exact fee mechanism includes protocol rules concerning a base fee and, where applicable, an optional priority fee. The formula applies when the effective price is defined for the transaction; it does not imply that every transaction has the same price or consumption.

Because execution is public and costly, Solidity developers must consider input validation, access control, re-entrancy, arithmetic behaviour, oracle dependence, denial of service and upgrade risks. A contract can faithfully execute flawed instructions. Code review, testing, formal methods where appropriate and independent security audits are professional responsibilities.

6. Bitcoin and Ethereum Compared

Bitcoin introduced a widely adopted decentralised digital-money system whose primary design emphasis is scarce, censorship-resistant value transfer. Ethereum also supports native value transfer but was designed as a general-purpose programmable platform.

Dimension	Bitcoin	Ethereum
Primary orientation	Digital money and settlement	Programmable state and applications
Computation	More deliberately constrained scripting	General-purpose EVM execution within protocol limits
State model	Unspent transaction outputs (UTXOs)	Accounts and contract storage
Native asset	BTC	ETH
Consensus today	Proof of Work	Proof of Stake
Application ecosystem	More limited scripting and protocols	Smart contracts, tokens and decentralised applications
Typical design emphasis	Monetary predictability and security	Programmability, composability and shared state

The comparison should not be treated as a claim that one system is universally superior. Each reflects different priorities. Bitcoin’s constrained scripting can reduce complexity in some use cases. Ethereum’s programmability enables rich applications but introduces larger software, governance and security surfaces.

7. Ethereum Proof of Stake

Ethereum’s consensus mechanism is based on Proof of Stake (PoS). Participants known as validators deposit stake and perform protocol duties. They propose blocks when selected and attest to blocks proposed by others. Honest participation earns rewards under protocol rules; certain forms of misconduct or prolonged failure can result in penalties.

A validator is not simply a person who owns ETH. It is a protocol role implemented through software, keys, network connectivity and an eligible stake position. Professional operation requires monitoring, secure key management, reliable infrastructure, software maintenance and incident response.

Staking and validator incentives

Staking aligns economic exposure with network security. A validator that signs conflicting messages or violates specified rules may lose stake through slashing. A validator that is offline may lose expected rewards and incur penalties, although the precise outcome depends on the protocol and the scale of correlated failures.

The purpose of these mechanisms is cryptoeconomic: participants are encouraged to behave honestly because honest operation is profitable or preserves capital, while attacks impose financial costs. The model depends on assumptions about stake distribution, validator independence, software correctness, governance and the value of the underlying asset.

Slots, epochs and attestations

Ethereum organises time into protocol-defined intervals. Validators are assigned duties to propose or attest to blocks. Attestations express views about the chain and support checkpoint justification and finalisation. Exact timing and committee details are implementation and specification matters that can evolve; the central concept is that many validators contribute signed evidence supporting a common history.

Finality

A transaction may be included in a block before it is economically and protocol-level final. Probabilistic or fork-choice confidence increases as the chain receives further support. Finality is a stronger condition under which reverting a checkpoint requires violating protocol assumptions and generally causing substantial stake to be penalised.

Finality is not identical to legal irreversibility or absolute impossibility. A critical software defect, coordinated social decision, cryptographic break or governance intervention could affect the system. Nevertheless, finality gives applications a more meaningful settlement guarantee than simply observing a recent block.

A useful conceptual distinction is:

inclusion: a transaction appears in a proposed block;
confirmation: subsequent protocol activity supports that block;
finalisation: protocol conditions provide strong economic assurance against reversal.

Applications should choose operational policies appropriate to transaction value and risk rather than treating every included transaction as equally settled.

8. Cryptoeconomic Security

Cryptoeconomics studies how economic incentives interact with cryptographic protocols. Ethereum’s security is not supplied by cryptography alone. Signatures prevent unauthorised use of keys, but incentives and consensus determine which signed messages become part of the accepted history.

Important security questions include:

How much stake is controlled by one entity or coordinated group?
Are validators geographically and operationally diverse?
Can liquid-staking or custodial services create concentration?
Are penalties sufficient to deter equivocation or censorship?
Can an attacker profit through market manipulation even when protocol rules are followed?
What happens during a major client bug or network partition?

Economic incentives can produce unintended consequences. For example, delegators may prefer a large staking provider because it appears reliable, increasing concentration. Operators may also face pressure to maximise returns in ways that increase correlated infrastructure risk. Decentralisation must therefore be assessed in practical, not merely theoretical, terms.

9. An Illustrative Applied Case: University Certificate Registry

Background

A university wants graduates to prove that a certificate was issued without requiring every employer to contact the registrar. It considers storing certificates directly on a public blockchain.

Problem

Directly publishing names, grades or document files could expose personal information and create compliance problems. The university also needs a process for correcting administrative errors and revoking invalid certificates.

Analysis

A blockchain can provide a timestamped, publicly verifiable commitment, but it is not necessarily an appropriate repository for personal records. A cryptographic hash of a certificate can be stored on-chain while the certificate itself remains in a controlled database or is held by the graduate. Verification software hashes the presented document and compares the result with the registered commitment.

This design still requires careful analysis. If the original document is predictable, an attacker may infer information by hashing possible documents. A randomised salt or privacy-preserving commitment may be necessary. The institution must also manage key security, revocation, data retention, legal rights and the possibility that the blockchain record cannot be deleted.

Approach and solution

The university deploys a narrowly scoped registry contract with functions to:

register a certificate commitment;
identify an issuing authority;
record an issuance timestamp;
mark a certificate as revoked;
restrict administrative actions through role-based access control.

The contract stores no unnecessary personal data. The university publishes verification software and maintains an off-chain governance process for corrections. Multiple authorised administrators use a multisignature arrangement for high-risk operations.

Outcome

Employers can independently verify that a presented certificate matches a registered commitment and has not been revoked. The blockchain supplies integrity and shared verification, while institutional systems retain responsibility for identity, privacy, correction and legal compliance.

Learning points

Blockchain is a trust-reduction tool, not a replacement for every institution.
On-chain data is difficult to erase; privacy must be designed before deployment.
Smart-contract access control and key management are as important as hashing.
A hybrid architecture may be more suitable than putting all data on-chain.

10. Limitations, Governance and Responsible Use

Blockchain systems have significant limitations. Public networks can experience congestion, unpredictable fees and limited throughput. Smart contracts are difficult to modify after deployment. Oracles that provide prices, weather data or real-world events introduce external trust assumptions. Bridges connecting blockchains have historically created complex security risks.

Privacy is another limitation. Public ledger transparency can conflict with data-protection principles, commercial confidentiality and personal autonomy. Pseudonymous addresses are not necessarily anonymous; transaction analysis can associate addresses with individuals or organisations.

Governance operates at several levels:

protocol developers and client teams maintain software;
validators and node operators implement and enforce rules;
users and application developers choose which software and chain history to recognise;
token holders or other communities may influence proposals;
regulators and courts may impose external obligations.

The existence of a technically valid transaction does not remove obligations concerning fraud, sanctions, consumer protection, taxation, securities regulation, money laundering or data protection. Organisations should obtain appropriate legal advice and conduct risk assessments before deployment.

Best practices for students and developers

Treat private keys as high-value credentials.
Use established cryptographic libraries rather than implementing primitives yourself.
Separate testing, staging and production environments.
Apply least privilege to contract administration.
Document assumptions about oracles, upgrades and emergency controls.
Test failure cases, not only successful transactions.
Monitor deployed contracts and prepare incident procedures.
Minimise personal data stored on public networks.
Use independent review for contracts controlling significant value.
Explain clearly what is on-chain, what is off-chain and who remains trusted.

Contemporary Developments

Ethereum continues to evolve through protocol upgrades, improved execution and consensus clients, scaling systems and layer-2 networks. Layer-2 systems execute or batch activity outside the main chain while using Ethereum for settlement or security, although their trust and data-availability assumptions differ. Account-abstraction approaches seek to make wallets more programmable, potentially improving recovery, fee payment and user experience.

These developments do not eliminate foundational questions. Developers must still understand what is being secured, which actors can intervene, how data becomes available, what finality means for the application and which assumptions users are accepting.

Chapter Summary

A blockchain is a replicated ledger whose records are linked by cryptographic commitments and accepted through consensus. Hashes provide integrity but not confidentiality, while digital signatures demonstrate control of private keys. Consensus determines valid ordering, and immutability is a conditional technical, economic and social property rather than an absolute guarantee.

Ethereum differs from Bitcoin primarily in its emphasis on general-purpose programmable state and smart contracts. Smart contracts execute deterministically in the EVM and consume gas. Ethereum’s Proof-of-Stake system uses validators, staking, attestations, rewards and penalties to support consensus. Inclusion, confirmation and finality represent different settlement conditions.

Effective blockchain design requires more than deploying code. It requires analysis of decentralisation, keys, incentives, privacy, governance, legal obligations, oracles, upgrades and operational failure. Hybrid architectures often provide better practical outcomes than placing all information on a public chain.

Key Terms

Distributed ledger: A shared record maintained and verified by multiple network participants.

Centralised system: A system controlled by a primary authority.

Decentralisation: Distribution of control among independent participants.

Blockchain: An ordered, hash-linked distributed ledger.

Cryptographic hash: A fixed-length digest produced from input data by a hash function.

Collision resistance: The difficulty of finding two different inputs with the same hash.

Public key: A key that may be shared and used for signature verification.

Private key: A secret key used to authorise digital signatures.

Digital signature: Cryptographic evidence that a message was authorised by a private key.

Consensus: Rules and processes through which participants agree on valid ledger history.

Immutability: Resistance to unauthorised alteration of accepted records.

Smart contract: Blockchain-deployed software with persistent state.

Ethereum Virtual Machine: Ethereum’s deterministic execution environment.

Gas: A unit that measures computational work and limits resource use.

Validator: A Proof-of-Stake participant performing consensus duties.

Staking: Locking or committing assets to support protocol participation.

Slashing: A protocol penalty for specified validator misconduct.

Finality: A strong protocol and economic guarantee against reversal.

Cryptoeconomics: The study of incentives and economic security in cryptographic systems.

Oracle: A mechanism that supplies external information to a smart contract.

Review Questions

Short Answer Questions

What is the difference between a distributed system and a decentralised system?
Why does changing an earlier block normally affect later blocks?
What does a digital signature prove, and what does it not prove?
What is gas used for in Ethereum?
Distinguish transaction inclusion from finality.

Long Answer Questions

Explain how hashing, replicated data and consensus work together to support blockchain integrity.
Compare Bitcoin and Ethereum in terms of purpose, state model, computation and consensus.
Describe Ethereum Proof of Stake, including validators, attestations, rewards and penalties.
Explain why smart contracts create both opportunities and new security responsibilities.
Discuss privacy, governance and legal limitations of public blockchain systems.

Analytical / Application Questions

A company proposes storing employee identity documents directly on a public blockchain. Analyse the technical, privacy and governance risks and recommend an alternative architecture.
A staking provider controls a rapidly increasing proportion of validators. Evaluate the possible effects on decentralisation, censorship resistance and operational risk.
Design a settlement policy for a high-value Ethereum application. Explain when it should treat a transaction as included, confirmed or finalised, and identify assumptions that could invalidate the policy.

Multiple Choice Questions with Answers

Question 1

Which property makes it difficult to find two different inputs producing the same hash?

A. Confidentiality

B. Collision resistance

C. Availability

D. Key delegation

Correct Answer: B. Collision resistance

Question 2

What does a valid digital signature primarily demonstrate?

A. That the transaction is profitable

B. That the message was authorised by the corresponding private key

C. That the message is legally valid

D. That the sender is a known person

Correct Answer: B. That the message was authorised by the corresponding private key

Question 3

What is the principal role of consensus in a blockchain?

A. To hide all transaction data

B. To create private keys

C. To agree on valid transaction ordering and state

D. To eliminate the need for software

Correct Answer: C. To agree on valid transaction ordering and state

Question 4

Which feature most clearly distinguishes Ethereum from Bitcoin?

A. Ethereum has no native asset

B. Ethereum provides a general-purpose smart-contract execution environment

C. Bitcoin uses account balances while Ethereum uses only UTXOs

D. Bitcoin cannot record transactions

Correct Answer: B. Ethereum provides a general-purpose smart-contract execution environment

Question 5

In Ethereum, gas primarily measures:

A. The market value of ETH

B. The computational work and resource use of execution

C. The number of validators owned by a user

D. The age of a transaction

Correct Answer: B. The computational work and resource use of execution

Question 6

What is the role of a validator in Proof of Stake?

A. To issue government licences

B. To propose and attest to blocks according to protocol duties

C. To decrypt all private transactions

D. To replace every smart contract

Correct Answer: B. To propose and attest to blocks according to protocol duties

Question 7

What can slashing do to a validator?

A. Reward it for being offline

B. Penalise specified dishonest behaviour by destroying or reducing stake

C. Make its public key private

D. Guarantee a higher ETH price

Correct Answer: B. Penalise specified dishonest behaviour by destroying or reducing stake

Question 8

Which statement best describes blockchain immutability?

A. Data can never be changed under any circumstances

B. Data is resistant to unauthorised alteration under technical, economic and social assumptions

C. Data is automatically confidential

D. Only one computer stores the data

Correct Answer: B. Data is resistant to unauthorised alteration under technical, economic and social assumptions

Question 9

Why might a university store a certificate hash rather than the certificate itself on-chain?

A. To avoid all verification

B. To reduce exposure of personal information while enabling integrity checks

C. To make the certificate editable by anyone

D. To prevent the use of cryptography

Correct Answer: B. To reduce exposure of personal information while enabling integrity checks

Question 10

Which sequence represents increasing settlement assurance?

A. Finality, inclusion, confirmation

B. Confirmation, finality, inclusion

C. Inclusion, confirmation, finality

D. Inclusion, finality, confirmation

Correct Answer: C. Inclusion, confirmation, finality

Ethereum & Solidity
Chapter 1 of 15

Chapter 1 Blockchain and Ethereum Foundations