CoEEC – Computer Science Department

Introduction to Blockchain — Chapter 7 Study Guide | Page 1

 TABLE OF CONTENTS
PART 1 STUDY NOTES Smart Contracts, Ethereum, Solidity, dApps, Security

PART 2 PRACTICE QUESTIONS 70 Exam-Style Questions (MC, Fill-in, Explain)

PART 3 ANSWER KEY Full Answers to All 70 Questions

PART 4 RAPID REVIEW SHEET Quick-Reference for Last-Minute Study

■ NOTE: Only Chapter 7 slides were uploaded. This guide covers all content from those 18 slides in full
depth. If your instructor also assigned a separate PDF/textbook reading for Ch.7, review it alongside this
guide.

Introduction to Blockchain — Chapter 7 Study Guide | Page 2

 PART 1: COMPREHENSIVE STUDY NOTES

1.1 Smart Contracts — Core Concepts

✔ DEFINITION: A smart contract is a secure and unstoppable computer program representing an
agreement that is automatically executable and enforceable.

Key Characteristics
Decentralized Program
Runs on a decentralized network; does NOT necessarily require a blockchain, but blockchain is the
standard execution platform due to its security benefits.
Business Logic
Contains some business logic and a limited amount of data. The logic executes only if specific criteria
are met.
Deterministic
Smart contracts are not "smart" in the AI sense — they are highly reliable and deterministic programs.
Autonomous
Can be used by actors/participants OR can run autonomously on behalf of network participants.
Immutable once deployed
Once deployed on the blockchain they cannot easily be modified — making pre-deployment security
critical.

Historical Origin — Nick Szabo

Smart contracts were first theorized by Nick Szabo in the late 1990s in an article titled "Formalizing and
Securing Relationships on Public Networks." It was ~20 years before real potential was appreciated with
Bitcoin's invention and blockchain's development.

Szabo's Definition of a Smart Contract

"A smart contract is an electronic transaction protocol that executes the terms of a contract. The general objectives
are to satisfy common contractual conditions (such as payment terms, liens, confidentiality, and even enforcement),
minimize exceptions both malicious and accidental, and minimize the need for trusted intermediaries. Related
economic goals include lowering fraud loss, arbitrations and enforcement costs, and other transaction costs."

✔ EXAM TRAP: Smart contracts were theorized in the LATE 1990s (not 1980s or 2000s). Nick Szabo —
not Satoshi Nakamoto — is the originator of the concept.

1.2 Smart Contract Languages

Most current smart contract use cases are in the financial industry, because blockchain first found
widespread use there.

Domain-Specific Languages (DSLs) vs. General-Purpose Languages (GPLs)

Domain-Specific Language (DSL) General-Purpose Language (GPL)

Developed for a specific application area Used for any programming task

Introduction to Blockchain — Chapter 7 Study Guide | Page 3

Limited expressiveness by design Broad expressiveness (Python, Java, C++)

Example: Solidity, Vyper, LLL Example: Python, JavaScript, C++

Better for writing smart contracts Not ideal for smart contract constraints

Smart Contract Languages for Ethereum

Language Description

Solidity High-level, JavaScript-like syntax. PRIMARY language for Ethereum. Object-oriented, statically
typed. Compiled by solc into EVM bytecode.

Vyper Newer language built from scratch for security, simplicity, and auditability. Alternative to Solidity.

Serpent Python-like high-level language for writing Ethereum smart contracts.

LLL Low-level Lisp-like Language. Another option for smart contract code.

✔ KEY ACRONYM: solc = Solidity Compiler. Converts Solidity source code → EVM bytecode.

1.3 Ethereum and the EVM

Conceptualized by
Vitalik Buterin, November 2013
Core Innovation
Turing-complete language enabling development of arbitrary programs (smart contracts) — contrast
with Bitcoin's limited scripting language
Ethereum as State Machine
Described in the Ethereum Yellow Paper by Dr. Gavin Wood as a transaction-based state machine
State Transitions
Genesis state → transformed into final state by executing transactions incrementally → accepted as
absolute undisputed version of state
The Merge (Sep 15, 2022)
Ethereum transitioned from Proof-of-Work (PoW) to Proof-of-Stake (PoS)
Energy Reduction
The Merge reduced energy consumption required to secure Ethereum by 99.95%
Result of The Merge
Ethereum became a low-carbon blockchain with improved security and scalability

Ethereum Virtual Machine (EVM)

The EVM (Ethereum Virtual Machine) is the runtime environment that executes smart contract bytecode.
High-level languages (Solidity, Serpent, LLL, Vyper) are compiled into EVM bytecode. For human
readability, bytecode can be converted to Opcode.

✔ EXAM FACTS: (1) Ethereum yellow paper author = Dr. Gavin Wood. (2) Ethereum conceptualized =
Nov 2013. (3) The Merge = Sep 15, 2022. (4) Energy saved = 99.95%.

1.4 Solidity In Depth

Introduction to Blockchain — Chapter 7 Study Guide | Page 4

 ✔ DEFINITION: Solidity is a domain-specific, object-oriented, statically typed, high-level
contract-oriented language for implementing smart contracts on the Ethereum blockchain.

Core Properties of Solidity

Object-Oriented
Contracts in Solidity are equivalent to classes in other OOP languages.
Statically Typed
Variable type checking is done at compile time. Every variable (state or local) must have a declared
type. Catches certain bugs early.
Contract-Oriented
Also called contract-oriented language; contracts are the central construct.
Supports
Inheritance, libraries, and complex user-defined types.
Compiler: solc
Converts Solidity source → EVM bytecode, which is executable by the EVM on the blockchain.
Syntax Style
JavaScript-like syntax.
Use Cases
Voting, crowdfunding, blind auctions, multi-signature wallets.
Data Type Categories
Two categories: (1) Value Types (2) Reference Types

Data Types in Solidity — Complete Reference

Data Type Description

uint Unsigned integer, non-negative, up to 256 bits. Variants: uint8, uint16 … uint256

int Signed integer (positive or negative), up to 256 bits. Variants: int8 … int256

bool Boolean type: holds true or false

address 20-byte Ethereum address

address payable Same as address but allows sending Ether

enum User-defined named constants (e.g., enum Status {Pending, Approved, Rejected})

bytes1–bytes32 Fixed-size byte arrays, 1 to 32 bytes

arrays Fixed-size (e.g., uint[5]) or dynamic-size (e.g., uint[])

struct Groups related variables into a custom data structure

mapping Key-value store (e.g., mapping(address => uint))

string Dynamic-sized UTF-8 text for human-readable data

bytes Dynamically-sized byte array

function References to internal or external functions

Sample Solidity Program (as shown in slides)

// SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract Test1 { uint public x =
2; // State variable function addition1(uint _input) public pure returns (uint) { uint
result = _input + 2; return result; } }

Introduction to Blockchain — Chapter 7 Study Guide | Page 5

After writing, this is compiled to bytecode (hexcode). For EVM it can be converted to a human-readable
Opcode.

ERC-20 Token Standard

✔ DEFINITION: ERC-20 is a widely adopted technical standard for creating and managing fungible
tokens on the Ethereum blockchain. It defines rules and functions that ensure compatibility and
interoperability between tokens and dApps.

■ KEY TERM: ERC-20 = Ethereum Request for Comment 20. Tokens following this standard are called
fungible tokens (each unit is identical/interchangeable).

1.5 Decentralized Applications (dApps)

✔ DEFINITION: A dApp is an Internet application whose backend runs on a decentralized peer-to-peer
network and whose source code is open source. No single node has complete control over the dApp.

The Four Requirements for a dApp (Johnston et al., "The General Theory of
Decentralized Applications")
1. Open Source & The dApp must be fully open source and autonomous. No single entity should
Autonomous control a majority of its tokens. All changes must be consensus-driven based
on community feedback.

2. Cryptographically Data and records of operations must be cryptographically secured and stored
Secured Data on a public, decentralized blockchain to avoid central points of failure.

3. Cryptographic Token A cryptographic token must be used by the application to provide access and
rewards to those contributing value (e.g., miners in Bitcoin).

4. Standard Cryptographic Tokens must be generated by the dApp according to a standard cryptographic
Algorithm for Token algorithm. Token generation acts as proof of value to contributors (e.g.,
Generation miners).

Advantages vs. Disadvantages of dApps

<b>Advantages</b> <b>Disadvantages</b>

<b>Fault-tolerant:</b> No single point of failure (distributed by

<b>Hard
default)to fix bugs:</b> Every peer must update their node software

<b>Censorship resistant:</b> No central authority can be pressured

<b>Identity
to remove
verification
content
(KYC):</b> No central authority to verify user ident

<b>No single IP/domain:</b> Government cannot block via IP

<b>Complex
or domain (only
to build:</b>
individual
Complex
nodes) consensus protocols; must be built to

<b>Trustworthy:</b> Not controlled by a single authority that<b>API

could cheat
independence:</b>
users Should not depend on centralized APIs — lim

<b>Ecosystem immaturity:</b> Small dApp ecosystem makes coupling to

✔ EXAM TRAP: dApps CAN depend on other dApps (in theory), but NOT on centralized APIs.
Practically, tight coupling between dApps is very difficult.

1.6 Security & Vulnerabilities in Smart Contracts

Smart contracts are prone to vulnerabilities due to their immutable nature once deployed. Bugs or
exploits can lead to irreversible financial losses or system failures.

Introduction to Blockchain — Chapter 7 Study Guide | Page 6

The Five Common Vulnerabilities
1. Re-entrancy Attacks Occurs when an external contract repeatedly calls back into the original contract
before the initial execution completes. This can allow attackers to drain funds.

2. Integer Overflow / Occurs when arithmetic operations exceed the maximum or minimum limits of a
Underflow variable type (e.g., uint goes above 2^256-1 or below 0).

3. Unchecked External Calling external contracts without proper validation can lead to unexpected behavior
Calls or attacks.

4. Front-Running Attackers exploit transaction ordering by observing pending transactions and

submitting their own with higher gas fees to be processed first.

5. Timestamp Using [Link] for critical logic can be manipulated by miners, since miners
Dependence have limited control over the timestamp.

1.7 Smart Contract Auditing

✔ DEFINITION: A smart contract audit is a systematic review of a smart contract's codebase to identify
vulnerabilities, inefficiencies, and compliance issues. Conducted by experienced auditors or automated
tools.

Auditing is critical because once deployed, smart contracts cannot easily be modified. Issues must be
identified and fixed BEFORE deployment.

Types of Audits
Manual Audits
Performed by human experts who analyze code logic, edge cases, and potential exploits.
Automated Audits
Use tools like Slither, MythX, or Oyente to scan for common vulnerabilities.
Formal Verification
Mathematically proves the correctness of a contract against its specification. Highest level of assurance.

✔ MEMORIZE: Audit tools = Slither, MythX, Oyente. Formal Verification = mathematical proof of
correctness.

1.8 Best Practices for Secure Smart Contracts

Code Simplicity
Keep contracts simple and modular to reduce complexity and attack surfaces.
Minimize External Calls
Limit interactions with external contracts to trusted ones only.
Use Established Libraries
Leverage well-audited libraries like OpenZeppelin for common functionalities.
Gas Optimization
Optimize code to reduce execution costs while maintaining security.
Immutable Design
Plan for immutability by using proxy patterns for upgradable contracts.
Input Validation

Introduction to Blockchain — Chapter 7 Study Guide | Page 7

 Validate all inputs to prevent invalid or malicious data from breaking the contract.
Event Logging
Emit events for critical actions to provide transparency and traceability.

✔ REMEMBER: OpenZeppelin is the recommended library for well-audited smart contract components.
Proxy patterns are used to achieve upgradeability despite immutability.

Introduction to Blockchain — Chapter 7 Study Guide | Page 8

 PART 2: PRACTICE QUESTIONS (70 Questions)
Questions are organized by type, matching your exam format exactly. Attempt each before checking the
Answer Key in Part 3.

SECTION A — Multiple Choice Questions (25 Questions)

Circle the best answer for each question.

1. Who first theorized the concept of smart contracts?

A. Vitalik Buterin
B. Nick Szabo
C. Satoshi Nakamoto
D. Dr. Gavin Wood

2. In which article did Nick Szabo introduce smart contracts?

A. Bitcoin: A Peer-to-Peer Electronic Cash System
B. The General Theory of Decentralized Applications
C. Formalizing and Securing Relationships on Public Networks
D. Ethereum: A Next-Generation Smart Contract Platform

3. What is the primary execution platform for smart contracts due to its security benefits?
A. Cloud computing
B. Traditional servers
C. Blockchain
D. Virtual machines

4. Which programming language is described as having JavaScript-like syntax for Ethereum

smart contracts?
A. Vyper
B. Serpent
C. LLL
D. Solidity

5. What does "solc" stand for and what does it do?

A. Solidity Compiler — converts Solidity to EVM bytecode
B. Smart Online Ledger Contract — stores contracts on chain
C. Solidity Controller — manages EVM execution
D. Secure Open-Ledger Code — encrypts contract data

6. Ethereum was conceptualized by Vitalik Buterin in which year?

A. 2008
B. 2011
C. 2013
D. 2015

Introduction to Blockchain — Chapter 7 Study Guide | Page 9

7. The Ethereum Yellow Paper was written by:
A. Vitalik Buterin
B. Nick Szabo
C. Dr. Gavin Wood
D. Satoshi Nakamoto

8. What happened to Ethereum on September 15, 2022?

A. Ethereum was first launched
B. Ethereum transitioned from PoW to PoS
C. ERC-20 was introduced
D. Solidity 1.0 was released

9. By what percentage did "The Merge" reduce Ethereum's energy consumption?

A. 50%
B. 75%
C. 90%
D. 99.95%

10. In Solidity, type checking is performed at:

A. Runtime
B. Compile time
C. Deployment time
D. Transaction execution time

11. What is the "address payable" data type used for in Solidity?
A. Storing a 20-byte Ethereum address that cannot send Ether
B. Referring to contract functions
C. Storing a 20-byte Ethereum address that allows sending Ether
D. Mapping keys to user balances

12. Which Solidity data type is used to create a key-value store?

A. struct
B. enum
C. mapping
D. bytes

13. ERC-20 is a standard for:

A. Non-fungible tokens on Bitcoin
B. Fungible tokens on Ethereum
C. Smart contract auditing
D. dApp governance protocols

14. Which of the following is NOT a requirement for a dApp according to Johnston et al.?
A. Must be fully open source
B. Must have a centralized authority to resolve disputes
C. Must use cryptographic tokens
D. Data must be stored on a decentralized blockchain

Introduction to Blockchain — Chapter 7 Study Guide | Page 10

15. A re-entrancy attack occurs when:
A. A miner manipulates transaction timestamps
B. An external contract repeatedly calls back into the original contract before initial execution completes
C. Arithmetic operations exceed variable type limits
D. An attacker submits transactions with higher gas fees

16. Which vulnerability involves an attacker submitting their own transaction with higher gas
fees to be processed first?
A. Re-entrancy
B. Integer overflow
C. Front-running
D. Timestamp dependence

17. Formal Verification in smart contract auditing means:

A. Running automated scanning tools like Slither
B. Human experts reviewing code logic and edge cases
C. Mathematically proving the correctness of a contract against its specification
D. Testing the contract on a testnet before mainnet deployment

18. Which of the following is a well-known automated smart contract auditing tool?
A. OpenZeppelin
B. Vyper
C. MythX
D. solc

19. What is the main purpose of OpenZeppelin in smart contract development?

A. It is an EVM bytecode executor
B. It is a well-audited library providing common smart contract functionalities
C. It is a blockchain consensus protocol
D. It is a dApp frontend framework

20. Which of the following is a DISADVANTAGE of dApps?

A. They are censorship resistant
B. They have no single point of failure
C. Fixing bugs requires every peer to update their node software
D. They are trustworthy because no single authority controls them

21. Which language is described as being built "from scratch" to achieve security, simplicity,
and auditability?
A. Solidity
B. LLL
C. Serpent
D. Vyper

22. In Ethereum, the genesis state is:

A. The final agreed state after all transactions
B. The initial state before any transactions are executed
C. The state after The Merge

Introduction to Blockchain — Chapter 7 Study Guide | Page 11

 D. The state recorded in the ERC-20 standard

23. Solidity contracts are equivalent to what concept in other OOP languages?
A. Functions
B. Variables
C. Classes
D. Modules

24. What does "uint" represent in Solidity?

A. A signed integer
B. An unsigned non-negative integer up to 256 bits
C. A boolean type
D. A 20-byte Ethereum address

25. Which of the following best describes a Domain-Specific Language (DSL)?

A. A language developed for any programming task
B. A language with broad expressiveness used across industries
C. A language developed with limited expressiveness for a specific application area
D. A language that compiles to machine code directly

Introduction to Blockchain — Chapter 7 Study Guide | Page 12

SECTION B — Complete the Scenario (20 Questions)
Each question provides a word bank of 10 words and a scenario with 10 blanks. Fill each blank with the
correct word from the bank.

Scenario 1: Smart Contract Fundamentals

Word Bank: Nick Szabo | deterministic | blockchain | business logic | intermediaries | immutable | autonomous
| criteria | decentralized | enforceable

A smart contract is a ___[1]___ program that runs on a ___[2]___ network. Although smart contracts do
not necessarily require a blockchain, ___[3]___ has become the standard execution platform. The contract
usually contains some ___[4]___ that executes only when specific ___[5]___ are met. Smart contracts are
highly reliable and ___[6]___ programs — not "smart" in the artificial intelligence sense. They minimize the
need for trusted ___[7]___ in executing agreements. The concept was first theorized by ___[8]___ in the
late 1990s. Once deployed, smart contracts are ___[9]___ and cannot easily be changed. A smart contract
is described as automatically executable and ___[10]___.

Scenario 2: Ethereum and EVM

Word Bank: Vitalik Buterin | Turing-complete | Gavin Wood | Proof-of-Stake | genesis | bytecode | Opcode | solc
| The Merge | 99.95%

Ethereum was conceptualized by ___[1]___ in November 2013. The key innovation was a ___[2]___
language enabling arbitrary smart contract programs. Ethereum is described in the Yellow Paper by Dr.
___[3]___ as a transaction-based state machine. In this model, a ___[4]___ state is transformed into a
final state through incremental transactions. Solidity source code is compiled by ___[5]___ into EVM
___[6]___, which can further be translated to human-readable ___[7]___. On September 15, 2022,
Ethereum underwent ___[8]___, transitioning from Proof-of-Work to ___[9]___. This upgrade reduced
energy consumption by ___[10]___.

Scenario 3: dApp Requirements

Word Bank: open source | consensus | cryptographic token | decentralized | majority | central points of failure |
cryptographic algorithm | proof of value | KYC | autonomous

According to Johnston et al., for an application to qualify as a dApp, it must be fully ___[1]___ and
___[2]___. No single entity should control a ___[3]___ of its tokens. All changes must be ___[4]___-driven
based on community feedback. Data must be cryptographically secured on a public, ___[5]___ blockchain
to avoid ___[6]___. A ___[7]___ must be used to provide access and rewards to contributors. These
tokens must be generated according to a standard ___[8]___ to serve as ___[9]___ to contributors. Note
that requiring identity checks (___[10]___) is actually a challenge for dApps, not a requirement.

Scenario 4: Smart Contract Vulnerabilities

Word Bank: re-entrancy | integer overflow | front-running | timestamp dependence | gas fees | immutable |
unchecked external calls | irreversible | [Link] | miners

Introduction to Blockchain — Chapter 7 Study Guide | Page 13

Smart contracts are prone to vulnerabilities partly because of their ___[1]___ nature once deployed.
Exploits can lead to ___[2]___ financial losses. A ___[3]___ attack occurs when an external contract
repeatedly calls back into the original contract. When arithmetic operations exceed variable limits,
___[4]___ occurs. Calling outside contracts without validation (___[5]___) can lead to attacks. Attackers
can exploit transaction ordering — called ___[6]___ — by observing pending transactions and submitting
their own with higher ___[7]___. Using ___[8]___ for critical logic is risky because ___[9]___ can
manipulate it. This vulnerability is called ___[10]___.

Scenario 5: Smart Contract Auditing & Best Practices

Word Bank: Manual Audits | Automated Audits | Formal Verification | OpenZeppelin | proxy patterns | Slither |
Gas Optimization | Input Validation | Event Logging | MythX

Auditing smart contracts is critical before deployment. ___[1]___ are performed by human experts
analyzing code logic and edge cases. ___[2]___ use tools such as ___[3]___ and ___[4]___ to scan for
common vulnerabilities. ___[5]___ mathematically proves contract correctness against its specification.
Best practices include using well-audited libraries like ___[6]___ for common functionality. ___[7]___
reduces execution costs while maintaining security. ___[8]___ prevents malicious data from breaking the
contract. ___[9]___ emits events for critical actions to provide transparency. Upgradability is achieved
despite immutability through ___[10]___.

Introduction to Blockchain — Chapter 7 Study Guide | Page 14

SECTION C — Briefly Explain (15 Questions)
Provide a concise explanation for each (3–5 sentences is ideal).

Q1. What is a smart contract? Why is it called "unstoppable"?

Q2. Explain the difference between a Domain-Specific Language (DSL) and a General-Purpose
Language (GPL). Give an example of each.

Q3. What is the Ethereum Virtual Machine (EVM) and what role does it play in executing smart
contracts?

Q4. What is ERC-20 and why is it important for the Ethereum ecosystem?

Q5. Explain the concept of "statically typed" as it applies to Solidity.

Q6. What is a re-entrancy attack? How does it exploit a smart contract?

Q7. What is the difference between an "address" and an "address payable" in Solidity?

Q8. Explain what "The Merge" was and what it changed about Ethereum.

Q9. What is formal verification in smart contract auditing? Why is it the highest assurance
level?

Q10. What are the four requirements that an application must meet to be considered a dApp?

Introduction to Blockchain — Chapter 7 Study Guide | Page 15

Q11. Why is it difficult to fix bugs in deployed dApps?

Q12. Explain front-running in the context of smart contracts.

Q13. What is the purpose of "event logging" as a best practice in smart contract
development?

Q14. What does it mean for Ethereum to be a "transaction-based state machine"?

Q15. Explain why governments cannot easily block dApps even if they wanted to.

Introduction to Blockchain — Chapter 7 Study Guide | Page 16

SECTION D — Explain in Detail (10 Questions)
Write comprehensive answers. These questions are worth the most marks.

Q1. Discuss the historical development of smart contracts from Nick Szabo's initial concept to
their modern implementation on Ethereum. Include key milestones, definitions, and how
blockchain technology enabled their realization.

Q2. Compare and contrast Solidity and Vyper as smart contract programming languages for
Ethereum. Discuss their design philosophies, key features, and when you might choose one
over the other.

Q3. Describe all five common vulnerabilities in smart contracts covered in the slides. For each
vulnerability, explain: (a) what it is, (b) how it occurs, and (c) what the potential impact is.

Q4. Explain the complete lifecycle of a Solidity smart contract — from writing the code to
execution on the blockchain. Include the roles of solc, EVM bytecode, and Opcode in your
answer.

Q5. Discuss the advantages and disadvantages of decentralized applications (dApps) in

detail. For each point, explain the underlying reason why that advantage or disadvantage
exists.

Q6. Explain all three types of smart contract audits (Manual, Automated, Formal Verification).
Compare their methods, tools used, and the level of assurance each provides. Why is auditing
especially critical for smart contracts?

Introduction to Blockchain — Chapter 7 Study Guide | Page 17

Q7. Describe all seven best practices for writing secure smart contracts. For each practice,
explain what it is and why it is important for contract security and reliability.

Q8. Explain what ERC-20 is, its significance, and how it relates to fungible tokens, dApps, and
the broader Ethereum ecosystem. Discuss how it ensures interoperability.

Q9. Ethereum is described as a "transaction-based state machine." Explain what this means,
including the concepts of genesis state, final state, and how transactions cause state
transitions. Reference the Ethereum Yellow Paper in your answer.

Q10. Explain the four requirements for a decentralized application (dApp) as described in
Johnston et al.'s whitepaper "The General Theory of Decentralized Applications." Provide
examples where applicable and explain why each requirement is essential to the decentralized
nature of a dApp.

Introduction to Blockchain — Chapter 7 Study Guide | Page 18

 PART 3: ANSWER KEY

Section A — Multiple Choice Answers

Q1: B — B. Nick Szabo Q2: C — C. Formalizing and Securing Relationships on
Public Networks

Q3: C — C. Blockchain Q4: D — D. Solidity

Q5: A — A. Solidity Compiler — converts Solidity to EVM Q6: C — C. 2013

bytecode

Q7: C — C. Dr. Gavin Wood Q8: B — B. Ethereum transitioned from PoW to PoS

Q9: D — D. 99.95% Q10: B — B. Compile time

Q11: C — C. Storing a 20-byte Ethereum address that Q12: C — C. mapping

allows sending Ether

Q13: B — B. Fungible tokens on Ethereum Q14: B — B. Must have a centralized authority to resolve
disputes

Q15: B — B. An external contract repeatedly calls back Q16: C — C. Front-running

into the original contract before initial execution
completes

Q17: C — C. Mathematically proving the correctness of a Q18: C — C. MythX

contract against its specification

Q19: B — B. It is a well-audited library providing common Q20: C — C. Fixing bugs requires every peer to update
smart contract functionalities their node software

Q21: D — D. Vyper Q22: B — B. The initial state before any transactions are
executed

Q23: C — C. Classes Q24: B — B. An unsigned non-negative integer up to 256

bits

Q25: C — C. A language developed with limited

expressiveness for a specific application area

Section B — Scenario Answers

Scenario 1: Smart Contract Fundamentals

[1] decentralized [2] blockchain [3] blockchain [4] business logic [5] criteria [6] deterministic [7] intermediaries
[8] Nick Szabo [9] immutable [10] enforceable

Scenario 2: Ethereum and EVM

[1] Vitalik Buterin [2] Turing-complete [3] Gavin Wood [4] genesis [5] solc [6] bytecode [7] Opcode [8] The Merge
[9] Proof-of-Stake [10] 99.95%

Scenario 3: dApp Requirements

Introduction to Blockchain — Chapter 7 Study Guide | Page 19

[1] open source [2] autonomous [3] majority [4] consensus [5] decentralized [6] central points of failure [7]
cryptographic token [8] cryptographic algorithm [9] proof of value [10] KYC

Scenario 4: Smart Contract Vulnerabilities

[1] immutable [2] irreversible [3] re-entrancy [4] integer overflow [5] unchecked external calls [6] front-running
[7] gas fees [8] [Link] [9] miners [10] timestamp dependence

Scenario 5: Smart Contract Auditing & Best Practices

[1] Manual Audits [2] Automated Audits [3] Slither [4] MythX [5] Formal Verification [6] OpenZeppelin [7] Gas
Optimization [8] Input Validation [9] Event Logging [10] proxy patterns

Introduction to Blockchain — Chapter 7 Study Guide | Page 20

Section C — Briefly Explain — Model Answers
Q1: Smart Contract Definition & Unstoppable
A smart contract is a decentralized, secure, and unstoppable computer program representing an agreement that is
automatically executable and enforceable. It is called "unstoppable" because it runs on a decentralized blockchain —
no single party can halt or alter it. Once deployed, it executes automatically when its predefined conditions are met,
without requiring any intermediary action.

Q2: DSL vs. GPL

A Domain-Specific Language (DSL) is developed with limited expressiveness for a specific application or area of
interest (e.g., Solidity for smart contracts). A General-Purpose Language (GPL) is designed for broad use across any
type of programming task (e.g., Python, Java). DSLs are better suited to smart contracts because their constraints and
features align with the requirements of contract programming.

Q3: Ethereum Virtual Machine (EVM)

The EVM is the runtime environment that executes smart contract bytecode on the Ethereum blockchain. Smart
contract code written in high-level languages (Solidity, Vyper, etc.) is compiled into EVM bytecode by compilers like
solc. The EVM then executes this bytecode on every participating node of the network, ensuring deterministic and
decentralized execution of contracts.

Q4: ERC-20
ERC-20 is a widely adopted technical standard for creating and managing fungible tokens on the Ethereum
blockchain. It defines a set of rules and functions that all conforming tokens must implement, ensuring that tokens can
interact seamlessly with dApps, wallets, and exchanges. ERC-20 enables interoperability across the entire Ethereum
ecosystem.

Q5: Statically Typed in Solidity

In Solidity, "statically typed" means that every variable — whether a state variable or a local variable — must have its
type declared at compile time. Type checking is performed when the code is compiled, not at runtime. This catches
type-related bugs early, before the contract is deployed, improving reliability and reducing vulnerabilities.

Q6: Re-entrancy Attack

A re-entrancy attack occurs when a malicious external contract repeatedly calls back into the original (victim) contract
before the initial execution completes. The attacker exploits the fact that the victim contract's state (e.g., balance) has
not yet been updated when the external call is made, allowing the attacker to drain funds or manipulate state
repeatedly within a single transaction.

Q7: address vs address payable

"address" in Solidity stores a 20-byte Ethereum address but does not support sending Ether. "address payable" also
stores a 20-byte Ethereum address but additionally has the transfer() and send() functions, allowing it to receive and
send Ether. When a contract needs to send funds to an address, it must use "address payable."

Q8: The Merge

"The Merge" was Ethereum's major protocol upgrade on September 15, 2022. It transitioned Ethereum's consensus
mechanism from Proof-of-Work (PoW) to Proof-of-Stake (PoS). This reduced Ethereum's energy consumption by
99.95%, making it a low-carbon blockchain while also boosting security and scalability.

Q9: Formal Verification

Introduction to Blockchain — Chapter 7 Study Guide | Page 21

Formal Verification is a type of smart contract audit that mathematically proves the correctness of a contract against its
specification. Unlike manual or automated audits that look for known patterns, formal verification uses mathematical
logic to guarantee that the contract behaves exactly as specified under all possible conditions. It provides the highest
level of assurance but is also the most resource-intensive approach.

Q10: Four dApp Requirements

(1) Fully open source and autonomous — no single entity controls a majority of tokens; changes are
consensus-driven. (2) Data cryptographically secured on a public decentralized blockchain to avoid central points of
failure. (3) Must use a cryptographic token to provide access and rewards to contributors. (4) Tokens must be
generated according to a standard cryptographic algorithm as proof of value to contributors.

Q11: Difficulty of Fixing dApp Bugs

In a dApp, the software runs across a decentralized peer-to-peer network of nodes. When a bug is found, fixing it
requires every peer in the network to update their node software simultaneously. There is no central server to patch.
This coordination challenge across potentially thousands of independent nodes makes updates and bug fixes
extremely difficult and slow.

Q12: Front-Running
Front-running is a smart contract vulnerability where attackers observe pending (unconfirmed) transactions in the
mempool and then submit their own transaction for the same action but with a higher gas fee. Since miners/validators
typically process transactions with higher fees first, the attacker's transaction is confirmed before the original, allowing
them to profit or disrupt the original transaction.

Q13: Event Logging

Event logging is a best practice where smart contracts emit structured events whenever critical actions occur (e.g., a
transfer, an approval, or a state change). These events are recorded on the blockchain and can be monitored by
external applications and users. Event logging provides transparency, traceability, and an audit trail, making it easier
to debug, monitor, and verify contract behavior.

Q14: Transaction-Based State Machine

Ethereum is described as a transaction-based state machine because it maintains a global state that changes through
transactions. It begins in a genesis state (the initial state). Each transaction causes a state transition, incrementally
transforming the state. The final state after all transactions is accepted as the absolute, undisputed version of the
blockchain's state. This model is documented in the Ethereum Yellow Paper by Dr. Gavin Wood.

Q15: Why Governments Cannot Easily Block dApps

Unlike traditional applications that are hosted on specific servers with identifiable IP addresses and domain names,
dApps run on a distributed network of nodes without a central server. There is no single IP address or domain that can
be blocked. Governments can track and shut down individual nodes, but if the network is large and nodes are
distributed across multiple countries, it becomes practically impossible to fully shut down the dApp.

Introduction to Blockchain — Chapter 7 Study Guide | Page 22

Section D — Explain in Detail — Model Answers
Q1: Historical Development of Smart Contracts
Nick Szabo first theorized smart contracts in the late 1990s in his article "Formalizing and Securing Relationships on
Public Networks." He defined a smart contract as an electronic transaction protocol executing contractual terms,
aiming to minimize exceptions, reduce need for trusted intermediaries, and lower fraud and transaction costs.
However, the technology to implement them at scale did not exist — nearly 20 years passed before Bitcoin
demonstrated the value of blockchain technology. Ethereum, conceptualized by Vitalik Buterin in November 2013, was
the breakthrough: it introduced a Turing-complete language enabling arbitrary smart contract programs on a
blockchain. Unlike Bitcoin's limited scripting language, Ethereum allowed developers to write complex programs. The
Ethereum Virtual Machine (EVM) became the decentralized execution environment for these contracts. Since then,
smart contracts have become the standard for decentralized finance, governance, NFTs, and more.

Q2: Solidity vs. Vyper

Solidity is a statically typed, object-oriented, domain-specific language with JavaScript-like syntax. It supports
inheritance, libraries, and complex user-defined types. It is the most widely used Ethereum smart contract language
and is compiled by solc into EVM bytecode. Solidity is contract-oriented — contracts are its central construct
(analogous to classes in OOP). Vyper, by contrast, was built from scratch with a focus on security, simplicity, and
auditability. It deliberately omits some features of Solidity (like inheritance) to reduce attack surface and make code
easier to audit. Choose Solidity when building complex systems with rich features; choose Vyper when security and
simplicity are the highest priorities, especially in high-stakes financial contracts.

Q3: Five Smart Contract Vulnerabilities

(1) Re-entrancy Attacks: A malicious external contract repeatedly calls back into the original before the first execution
completes, potentially draining funds. Classic example: The DAO hack. (2) Integer Overflow/Underflow: Arithmetic
operations that exceed the max (2^256-1 for uint256) or go below zero (for uint) wrap around to unexpected values,
causing logic errors and potential exploits. (3) Unchecked External Calls: Calling external contracts without validating
return values or outcomes can lead to silent failures or unexpected behavior that attackers exploit. (4) Front-Running:
Attackers monitor the mempool for pending transactions, then submit competing transactions with higher gas fees to
be processed first, profiting from the information advantage. (5) Timestamp Dependence: Using [Link] for
critical decisions (like randomness or time locks) is risky because miners have limited ability to manipulate
timestamps, which can affect contract outcomes.

Q4: Solidity Smart Contract Lifecycle

Step 1 — Writing: The developer writes the smart contract in Solidity, a high-level DSL with JavaScript-like syntax.
They define state variables, functions, events, and access controls. Step 2 — Compilation: The Solidity code is
compiled using solc (Solidity Compiler), which converts the high-level Solidity source into EVM bytecode (a
hexadecimal encoding of instructions). For human readability, this bytecode can also be converted to Opcode (a
human-readable assembly-like representation). Step 3 — Deployment: The compiled bytecode is broadcast as a
transaction to the Ethereum network. Once mined, the contract is assigned an address on the blockchain. Step 4 —
Execution: When users or other contracts interact with the deployed contract, the EVM executes the bytecode on
every participating node, ensuring deterministic and decentralized execution. Each execution may change the
contract's state, and these changes are recorded on the blockchain permanently.

Q5: dApp Advantages and Disadvantages

Introduction to Blockchain — Chapter 7 Study Guide | Page 23

Advantages — Fault-tolerant: Because dApps are distributed with no central server, there is no single point of failure;
the network continues even if many nodes go down. Censorship resistant: No central authority can be pressured to
remove content. Net censorship resistance is inherent. No IP/domain blocking: Governments cannot block a dApp by
targeting an IP or domain. Even shutting individual nodes is impractical in large, globally distributed networks.
Trustworthy: Users can trust the application because no single authority controls it to cheat them. Disadvantages —
Hard to update: Updating requires every peer to update their node software — no central patch mechanism. KYC
challenges: No central authority to verify user identity for applications that legally require it. Complexity: Consensus
protocols are complex, and dApps must be built to scale from inception — no iterative scaling. API independence:
dApps should not rely on centralized APIs, but this limits functionality. Ecosystem immaturity: The small ecosystem
makes building and coupling with other dApps difficult in practice.

Q6: Three Types of Smart Contract Audits

Manual Audits: Conducted by experienced human security experts who read and analyze the contract code
line-by-line. They look for logic errors, edge cases, reentrancy vulnerabilities, access control issues, and economic
exploits. Most effective for finding complex, context-dependent issues that tools miss. Automated Audits: Use
specialized tools — Slither (static analysis), MythX (symbolic execution + fuzzing), and Oyente (symbolic execution) —
to automatically scan the codebase for known vulnerability patterns. Faster and cheaper than manual review but may
miss novel or complex exploits. Formal Verification: Mathematically proves that a contract satisfies its specification
under all possible inputs and states. Uses mathematical logic and theorem provers. The most rigorous and
highest-assurance method, but also the most resource-intensive. Auditing is especially critical for smart contracts
because once deployed they are immutable — bugs cannot be easily patched, and financial losses from exploits are
typically irreversible.

Q7: Seven Best Practices for Secure Smart Contracts

(1) Code Simplicity: Keep contracts simple and modular. Complexity increases the probability of bugs and makes
auditing harder. (2) Minimize External Calls: Limit interactions with external contracts to trusted ones only. External
calls are a major attack vector (e.g., re-entrancy). (3) Use Established Libraries: Use well-audited libraries like
OpenZeppelin for common functions (token standards, access control). These have been reviewed by thousands of
developers. (4) Gas Optimization: Write efficient code to minimize gas costs without compromising security. Inefficient
code can make contracts uneconomical to use. (5) Immutable Design with Proxy Patterns: Plan for the contract's
immutability by using upgradeable proxy patterns, which allow logic to be updated without changing the contract
address. (6) Input Validation: Validate all inputs to functions to prevent invalid, malicious, or out-of-range data from
causing unexpected behavior. (7) Event Logging: Emit events for critical actions (transfers, approvals, state changes)
to provide an immutable audit trail, improve transparency, and support off-chain monitoring.

Q8: ERC-20 and the Ethereum Ecosystem

ERC-20 (Ethereum Request for Comment 20) is a widely adopted technical standard that defines the rules and
interface functions that all fungible tokens on Ethereum must implement. "Fungible" means each token unit is identical
and interchangeable with any other unit of the same token. ERC-20 defines standard functions such as transfer(),
approve(), allowance(), and balanceOf(), and standard events like Transfer and Approval. This standardization means
any ERC-20 token can interact seamlessly with any dApp, wallet, or exchange that supports ERC-20 — without
custom integration work. It ensures interoperability across the entire Ethereum ecosystem. ERC-20 tokens are used
for governance, utility, stablecoins (like USDC, DAI), and fundraising (ICOs). Its standardization was crucial in the
explosion of the DeFi (Decentralized Finance) ecosystem.

Q9: Ethereum as a Transaction-Based State Machine

Introduction to Blockchain — Chapter 7 Study Guide | Page 24

Ethereum is described in the Yellow Paper (authored by Dr. Gavin Wood) as a transaction-based state machine. This
means Ethereum maintains a global state — a snapshot of all account balances, contract storage, and other data —
that changes exclusively through transactions. The machine begins in a genesis state (the very first state when the
blockchain is initialized). Each submitted transaction is validated and applied, causing a state transition: the current
state S is transformed into a new state S' by applying the transaction's effects (updating balances, running contract
code, etc.). This happens incrementally with every transaction. The final state after processing all transactions in a
block is accepted by consensus as the absolute, undisputed version of reality on the Ethereum blockchain. This model
ensures that all nodes, independently executing the same transactions, arrive at the same final state — the foundation
of Ethereum's trustless correctness.

Q10: Four dApp Requirements (Johnston et al.)

(1) Open Source and Autonomous: The application code must be publicly accessible and operate without central
control. No single entity should hold a majority of its tokens. All changes must be driven by community consensus.
This ensures no party can unilaterally alter the application. Example: Bitcoin's protocol changes require majority miner
and node agreement. (2) Cryptographically Secured Data on a Decentralized Blockchain: Data must be stored on a
public blockchain and protected by cryptography. This prevents tampering and eliminates central points of failure.
Example: Ethereum stores transaction history permanently and immutably. (3) Cryptographic Token: The dApp must
issue cryptographic tokens to grant access and reward contributors. Tokens align economic incentives between
participants. Example: Bitcoin rewards miners with BTC. (4) Standard Cryptographic Algorithm for Token Generation:
Tokens must be generated through a transparent, standardized algorithm (like PoW or PoS mining). This serves as
proof that contributors have added value. Example: Bitcoin's PoW mining algorithm generates BTC according to a
predictable, auditable algorithm.

Introduction to Blockchain — Chapter 7 Study Guide | Page 25

 PART 4: RAPID REVIEW SHEET — Last-Minute Study
Read this the morning of your exam. Everything on this page is HIGH-PROBABILITY exam content.

Key People & Their Contributions

Person When Contribution

Nick Szabo Late 1990s Theorized smart contracts; article: "Formalizing and Securing
Relationships on Public Networks"

Vitalik Buterin Nov 2013 Conceptualized Ethereum; proposed Turing-complete blockchain

language

Dr. Gavin Wood 2014 Wrote the Ethereum Yellow Paper; described Ethereum as a
transaction-based state machine

Johnston et al. ~2014 Authored "The General Theory of Decentralized Applications"; defined 4
dApp requirements

Critical Numbers to Memorize

Number/Value What It Represents

99.95% Energy reduction from The Merge (PoW → PoS)

Sep 15, 2022 Date of The Merge

Nov 2013 Ethereum conceptualized by Vitalik Buterin

Late 1990s Smart contracts theorized by Nick Szabo

~20 years Gap between Szabo's theory and blockchain enabling smart contracts

20 bytes Size of an Ethereum address in Solidity

256 bits Maximum size of uint/int in Solidity

4 Number of dApp requirements (Johnston et al.)

5 Number of common smart contract vulnerabilities

7 Number of best practices for secure smart contracts

3 Types of smart contract audits

Acronyms — MEMORIZE THESE (Instructor said acronyms will be

tested)
■ WARNING: Your instructor specifically stated that acronyms will appear in the exam and abbreviations
will NOT be given — you must know what they stand for!

Acronym Full Form + Meaning

EVM Ethereum Virtual Machine — runtime that executes smart contract bytecode

DSL Domain-Specific Language — language for a specific application area

Introduction to Blockchain — Chapter 7 Study Guide | Page 26

GPL General-Purpose Language — language for any programming task

solc Solidity Compiler — compiles Solidity to EVM bytecode

dApp Decentralized Application — app running on a decentralized P2P network

ERC-20 Ethereum Request for Comment 20 — standard for fungible tokens on Ethereum

PoW Proof-of-Work — original Ethereum consensus (before The Merge)

PoS Proof-of-Stake — current Ethereum consensus (after The Merge)

LLL Low-level Lisp-like Language — smart contract language for Ethereum

KYC Know Your Customer — identity verification process (a challenge for dApps)

MythX Automated smart contract security analysis service (audit tool)

OOP Object-Oriented Programming — Solidity contracts ≈ OOP classes

DeFi Decentralized Finance — financial services using blockchain/smart contracts

DAO Decentralized Autonomous Organization — org governed by smart contracts

NFT Non-Fungible Token — unique digital asset (contrast with ERC-20 fungible tokens)

Likely Exam Traps — Watch Out!

TRAP 1 Smart contracts were invented by Nick Szabo (NOT Vitalik Buterin, NOT Satoshi Nakamoto).

TRAP 2 The Ethereum Yellow Paper was written by Dr. Gavin Wood (NOT Vitalik Buterin).

TRAP 3 The Merge date: September 15, 2022 (NOT 2021 or 2023).

TRAP 4 Energy reduction from The Merge: 99.95% (NOT 90% or 95%).

TRAP 5 Solidity is statically typed (type checking at COMPILE time, NOT runtime).

TRAP 6 dApps CAN depend on other dApps (theoretically), but NOT on centralized APIs.

TRAP 7 "address" and "address payable" are different — only payable can send Ether.

TRAP 8 Solidity is DSL (domain-specific), not a general-purpose language.

TRAP 9 Smart contracts are deterministic (not "smart" in the AI/ML sense).

TRAP 10 Formal Verification MATHEMATICALLY PROVES correctness — it is NOT just automated scanning.

TRAP 11 ERC-20 is for FUNGIBLE tokens (identical/interchangeable units), not NFTs.

TRAP 12 solc = Solidity Compiler. MythX, Slither, Oyente are AUDIT tools (not compilers).

5-Minute Pre-Exam Checklist

■ I know Nick Szabo theorized smart contracts in the late 1990s.
■ I know Ethereum was conceptualized in November 2013 by Vitalik Buterin.
■ I know the Yellow Paper author is Dr. Gavin Wood.
■ I know The Merge was September 15, 2022 and reduced energy by 99.95%.
■ I know Solidity is statically typed, object-oriented, compiled by solc into EVM bytecode.
■ I know all 13 Solidity data types.
■ I can list all 4 dApp requirements (Johnston et al.).

Introduction to Blockchain — Chapter 7 Study Guide | Page 27

■ I can name all 5 smart contract vulnerabilities.
■ I know the 3 audit types: Manual, Automated (Slither/MythX/Oyente), Formal Verification.
■ I know all 7 best practices for secure smart contracts.
■ I know what DSL, GPL, EVM, solc, ERC-20, PoW, PoS, dApp, KYC, LLL stand for.
■ I know ERC-20 = fungible token standard for Ethereum.
■ I know front-running exploits gas fee ordering, not overflow or re-entrancy.

Good luck on your exam! You've got this. Remember: read each question carefully, watch for acronyms,
and trust your preparation. — Your Claude Study Assistant

Introduction to Blockchain — Chapter 7 Study Guide | Page 28