Loading…

Worked solutions

IB Computer Science HL · Paper 3

Computer Science, Higher Level

Session: May 2021
Marks: 30
Duration: 1 hour
Calculator: Not allowed
Questions: 4

Keep your copy of the paper open alongside. We don't reproduce the questions: each part below is labelled to match the May 2021 Global paper, which your school or the IB can provide.

Practice mode

Hide our working until you've had a go.

Questions

Questions 1–4 · 30 marks

Question 1

4 marks

Digital signatures and proof-of-work mining in distributed cryptocurrency ledgers

Networks

(a)

2 marks

Identify two core technical characteristics of a digital signature used in peer-to-peer cryptocurrency networks:
1) Non-repudiation and cryptographic authenticity: A transaction signed by the sender's private key cannot be forged or disowned, proving conclusively that the legitimate owner initiated the transfer.
2) Mathematical uniqueness and message integrity: The signature is generated from the specific transaction payload and changes completely if even a single bit of the transaction data is altered, ensuring collision resistance and tamper detection.

Mentor tip

Focus on asymmetric cryptographic properties such as private-key signing for non-repudiation and transaction hash binding.

(b)

2 marks

Identify two essential stages involved in the proof-of-work consensus sequence:
1) Block aggregation and proposed block header creation: The mining node collects pending unconfirmed transactions from the memory pool, verifies their signatures, constructs a Merkle tree, and combines the resulting Merkle root with the previous block's hash into a proposed block header.
2) Iterative cryptographic hashing against target difficulty: The miner increments a numerical counter (nonce) repeatedly, running SHA-256 over the block header until generating a digest with a value strictly below the network target threshold.

SHA-256 (SHA-256 (Header ∥ Nonce)) < Target

Mentor tip

Distinguish between assembling unconfirmed transactions into a block and calculating a nonce that meets the target difficulty constraint.

Question 2

8 marks

Merkle tree hierarchy and governance concerns in decentralized municipal economies

Abstract data structures
System fundamentals

(a)

4 marks

Describe the hierarchical construction and hash storage mechanism of a Merkle tree in blockchain architectures:
1) Leaf node instantiation: Individual financial transactions within a unmined block are hashed using a cryptographic hash function, with each hash assigned as a leaf node at the base level of the binary tree.
2) Pairwise concatenation and hashing: Adjacent pairs of leaf hashes are concatenated in order and hashed together to generate intermediate parent nodes at the next level up: $H_{12} = Hash (H_{1} ∥ H_{2})$ .
3) Handling odd counts: Whenever a level contains an odd number of hash nodes, the rightmost unpaired node is duplicated and hashed with itself to preserve strict binary tree symmetry.
4) Recursive aggregation to the Merkle root: This pairwise hashing proceeds iteratively upward through logarithmic levels until a single cryptographic digest remains at the apex, known as the Merkle root, which acts as a tamper-evident cryptographic fingerprint for all transactions in the block.

Root = Hash (Hash (H_{1} ∥ H_{2}) ∥ Hash (H_{3} ∥ H_{4}))

Mentor tip

Trace the bottom-up generation from individual transaction leaf hashes through recursive pairwise parent concatenation to the final apex root hash.

(b)

4 marks

Explain two major reasons why community residents might express concern regarding the absence of a central administrative authority for MONS transactions:
1) Irreversibility of mistaken or fraudulent transfers: Without a central banking authority or ombudsman to adjudicate disputes, transactions committed to the distributed ledger are immutable; sending funds to an incorrect alphanumeric address or suffering account theft leaves users with no institutional mechanism for chargebacks or dispute resolution.
2) Vulnerability to majority hash-power attacks and private network instability: In a localized, small-scale municipal blockchain, total network computing power remains modest, raising the risk that a rogue actor or coordinated mining pool could command over 51% of hashing power, enabling double-spending attacks and undermining community trust.

Mentor tip

Highlight the permanent nature of immutable ledger transfers alongside the lack of central consumer protections and vulnerability to 51% attacks.

Question 3

6 marks

Role of determinism and non-invertibility in cryptographic ledger integrity

Networks

6 marks

Explain how determinism and non-invertibility support secure and immutable operation within blockchain systems:
1) Role of determinism in network consensus and validation: Determinism guarantees that passing an identical input sequence into the hash algorithm always outputs the exact same fixed-length bit string. This property is vital across a decentralized network because hundreds of independent validator nodes must verify transactions and blocks concurrently; without absolute determinism, different validating nodes would compute differing state digests from identical blocks, preventing agreement on ledger history.
2) Role of determinism in block linkage and Merkle proofs: The header of each new block embeds the deterministic hash of the preceding block header. Because altering any previous transaction changes that block's digest and all downstream linkages, determinism enforces immutability across the chain while enabling light nodes to verify transaction membership via compact Merkle audit paths.
3) Role of non-invertibility in asymmetric address security: Non-invertibility (one-way pre-image resistance) ensures that given an output hash $y$ , it is computationally impossible to determine the original pre-image $x$ . This protects public wallet addresses derived from public keys; users can share their payment addresses openly without exposing the underlying private signing credentials that unlock their funds.
4) Role of non-invertibility in proof-of-work integrity: Because miners cannot run the hash function backward to deduce a compliant nonce directly from a target difficulty, they must conduct brute-force exploration across the nonce search space, ensuring that block generation requires authentic physical computation and cannot be bypassed.

x deterministic y = H (x), H^{- 1} (y) intractable \emptyset

Mentor tip

Structure your response into two distinct sections: how determinism guarantees uniform multi-node verification and chained block hashes, and how non-invertibility protects private keys and enforces proof-of-work difficulty.

Question 4

12 marks

Strategic evaluation of security versus scalability in municipal blockchain deployments

Networks

12 marks

Evaluate Pablo's claim that adopting blockchain architecture guarantees both robust security and high scalability for Santa Monica's local MONS cryptocurrency:
Architectural security strengths:
- Distributed resilience and elimination of single points of failure: Operating as a peer-to-peer network across municipal computers removes centralized database targets, protecting the local economy against single server outages and direct administrative database tampering.
- Cryptographic chain immutability: Every block encapsulates the cryptographic hash of its predecessor. Modifying historical transaction records would require regenerating all subsequent proof-of-work headers faster than the honest network, creating high structural tamper resistance.
- Asymmetric authorization: Wallets require cryptographic signatures from private keys, preventing unauthorized spending as long as user credentials remain secure.
Inherent security vulnerabilities and local constraints:
- Elevated 51% attack susceptibility on small networks: While global cryptocurrencies possess vast computational hashing distribution, a municipal token like MONS features low total network hash power. A modest computing cluster could temporarily control the majority of hashing capacity, enabling double-spending of local currency.
- Endpoint and credential vulnerability: Distributed ledgers secure transaction logs, but do not prevent phishing, malware key-logging, or lost seed phrases at the user device level; without central account recovery, stolen credentials result in permanent loss.
Scalability bottlenecks in proof-of-work networks:
- Low transaction throughput (TPS limits): Enforcing strict block size constraints and predetermined block generation intervals (e.g., 10 minutes) severely caps peak transaction volume. If the Santa Monica municipal economy expands and thousands of shoppers make simultaneous purchases, transaction backlogs and unconfirmed queues will proliferate.
- Network latency and propagation delays: Distributing every transaction and block to all municipal nodes requires substantial network bandwidth; during retail rush hours, synchronization delays could lead to temporary chain forks and payment friction.
- Computational and storage bloat: Every full node must maintain a complete historical copy of the distributed ledger. As transaction history accumulates over years, storage requirements and memory consumption grow steadily, discouraging small local merchants from hosting independent validating nodes.
Strategic conclusion and recommendation:
Pablo's assertion is partially flawed: while blockchain delivers strong cryptographic security and decentralization, proof-of-work architectures inherently trade off scalability to maintain distributed consensus (the classic blockchain trilemma). To make MONS practical for everyday retail use, Santa Monica should avoid heavy proof-of-work mining and instead implement an energy-efficient permissioned Byzantine fault-tolerant or Proof-of-Authority (PoA) consensus model managed across trusted local institutions, or deploy a layer-2 state channel payment framework to achieve instant, high-throughput retail settlements.

Mentor tip

Address both security (51% attack vulnerability on small municipal networks vs ledger immutability) and scalability (throughput caps, block propagation, storage overhead), concluding with alternative consensus models like PoA or layer-2 scaling.

Our analysis

Where the marks are

Each part sorted by the topic it mostly tests. Networks carries the most marks on this paper.

Networks22 marks · 73%
Q1, Q3, Q4
System fundamentals4 marks · 13%
Q2
Abstract data structures4 marks · 13%
Q2

Mentor insights

Traps to watch for

01
Confusing unmined block assembly with nonce verification · Q1
Creating a unmined block involves aggregating unconfirmed transactions into a Merkle tree; finding the proof-of-work nonce is an independent iterative hashing step against target difficulty.
02
Assuming small private blockchains share the 51% resistance of public networks · Q2
A localized municipal currency operates with relatively low total network hashing power, making it far more vulnerable to a 51% attack than large global networks.
03
Overlooking the fundamental blockchain trilemma between security and throughput · Q4
Proof-of-work cryptocurrencies cannot scale to high transaction volumes without compromising decentralization or block interval safety; claiming both without qualification ignores fundamental architectural limits.

Solutions and tips are GeorgeTheTutor's own; the questions are not reproduced here. Not affiliated with or endorsed by the International Baccalaureate Organization.

Want someone to go through your paper with you?

Our maths mentors took these exams recently. One-to-one, they'll find where your marks are going and fix it before May.

Find your maths mentor More past papers

Worked solutions

IB Computer Science HL · Paper 3

Computer Science, Higher Level

Session: May 2021
Marks: 30
Duration: 1 hour
Calculator: Not allowed
Questions: 4

Q1 Q2 Q3 Q4

Keep your copy of the paper open alongside. We don't reproduce the questions: each part below is labelled to match the May 2021 Global paper, which your school or the IB can provide.

Practice mode

Hide our working until you've had a go.

Questions

Questions 1–4 · 30 marks

Question 1

4 marks

Digital signatures and proof-of-work mining in distributed cryptocurrency ledgers

Networks

(a)

2 marks

Identify two core technical characteristics of a digital signature used in peer-to-peer cryptocurrency networks:
1) Non-repudiation and cryptographic authenticity: A transaction signed by the sender's private key cannot be forged or disowned, proving conclusively that the legitimate owner initiated the transfer.
2) Mathematical uniqueness and message integrity: The signature is generated from the specific transaction payload and changes completely if even a single bit of the transaction data is altered, ensuring collision resistance and tamper detection.

Mentor tip

Focus on asymmetric cryptographic properties such as private-key signing for non-repudiation and transaction hash binding.

(b)

2 marks

Identify two essential stages involved in the proof-of-work consensus sequence:
1) Block aggregation and proposed block header creation: The mining node collects pending unconfirmed transactions from the memory pool, verifies their signatures, constructs a Merkle tree, and combines the resulting Merkle root with the previous block's hash into a proposed block header.
2) Iterative cryptographic hashing against target difficulty: The miner increments a numerical counter (nonce) repeatedly, running SHA-256 over the block header until generating a digest with a value strictly below the network target threshold.

SHA-256 (SHA-256 (Header ∥ Nonce)) < Target

Mentor tip

Distinguish between assembling unconfirmed transactions into a block and calculating a nonce that meets the target difficulty constraint.

Question 2

8 marks

Merkle tree hierarchy and governance concerns in decentralized municipal economies

Abstract data structures
System fundamentals

(a)

4 marks

Describe the hierarchical construction and hash storage mechanism of a Merkle tree in blockchain architectures:
1) Leaf node instantiation: Individual financial transactions within a unmined block are hashed using a cryptographic hash function, with each hash assigned as a leaf node at the base level of the binary tree.
2) Pairwise concatenation and hashing: Adjacent pairs of leaf hashes are concatenated in order and hashed together to generate intermediate parent nodes at the next level up: $H_{12} = Hash (H_{1} ∥ H_{2})$ .
3) Handling odd counts: Whenever a level contains an odd number of hash nodes, the rightmost unpaired node is duplicated and hashed with itself to preserve strict binary tree symmetry.
4) Recursive aggregation to the Merkle root: This pairwise hashing proceeds iteratively upward through logarithmic levels until a single cryptographic digest remains at the apex, known as the Merkle root, which acts as a tamper-evident cryptographic fingerprint for all transactions in the block.

Root = Hash (Hash (H_{1} ∥ H_{2}) ∥ Hash (H_{3} ∥ H_{4}))

Mentor tip

Trace the bottom-up generation from individual transaction leaf hashes through recursive pairwise parent concatenation to the final apex root hash.

(b)

4 marks

Explain two major reasons why community residents might express concern regarding the absence of a central administrative authority for MONS transactions:
1) Irreversibility of mistaken or fraudulent transfers: Without a central banking authority or ombudsman to adjudicate disputes, transactions committed to the distributed ledger are immutable; sending funds to an incorrect alphanumeric address or suffering account theft leaves users with no institutional mechanism for chargebacks or dispute resolution.
2) Vulnerability to majority hash-power attacks and private network instability: In a localized, small-scale municipal blockchain, total network computing power remains modest, raising the risk that a rogue actor or coordinated mining pool could command over 51% of hashing power, enabling double-spending attacks and undermining community trust.

Mentor tip

Highlight the permanent nature of immutable ledger transfers alongside the lack of central consumer protections and vulnerability to 51% attacks.

Question 3

6 marks

Role of determinism and non-invertibility in cryptographic ledger integrity

Networks

6 marks

Explain how determinism and non-invertibility support secure and immutable operation within blockchain systems:
1) Role of determinism in network consensus and validation: Determinism guarantees that passing an identical input sequence into the hash algorithm always outputs the exact same fixed-length bit string. This property is vital across a decentralized network because hundreds of independent validator nodes must verify transactions and blocks concurrently; without absolute determinism, different validating nodes would compute differing state digests from identical blocks, preventing agreement on ledger history.
2) Role of determinism in block linkage and Merkle proofs: The header of each new block embeds the deterministic hash of the preceding block header. Because altering any previous transaction changes that block's digest and all downstream linkages, determinism enforces immutability across the chain while enabling light nodes to verify transaction membership via compact Merkle audit paths.
3) Role of non-invertibility in asymmetric address security: Non-invertibility (one-way pre-image resistance) ensures that given an output hash $y$ , it is computationally impossible to determine the original pre-image $x$ . This protects public wallet addresses derived from public keys; users can share their payment addresses openly without exposing the underlying private signing credentials that unlock their funds.
4) Role of non-invertibility in proof-of-work integrity: Because miners cannot run the hash function backward to deduce a compliant nonce directly from a target difficulty, they must conduct brute-force exploration across the nonce search space, ensuring that block generation requires authentic physical computation and cannot be bypassed.

x deterministic y = H (x), H^{- 1} (y) intractable \emptyset

Mentor tip

Question 4

12 marks

Strategic evaluation of security versus scalability in municipal blockchain deployments

Networks

12 marks

Evaluate Pablo's claim that adopting blockchain architecture guarantees both robust security and high scalability for Santa Monica's local MONS cryptocurrency:
Architectural security strengths:
- Distributed resilience and elimination of single points of failure: Operating as a peer-to-peer network across municipal computers removes centralized database targets, protecting the local economy against single server outages and direct administrative database tampering.
- Cryptographic chain immutability: Every block encapsulates the cryptographic hash of its predecessor. Modifying historical transaction records would require regenerating all subsequent proof-of-work headers faster than the honest network, creating high structural tamper resistance.
- Asymmetric authorization: Wallets require cryptographic signatures from private keys, preventing unauthorized spending as long as user credentials remain secure.
Inherent security vulnerabilities and local constraints:
- Elevated 51% attack susceptibility on small networks: While global cryptocurrencies possess vast computational hashing distribution, a municipal token like MONS features low total network hash power. A modest computing cluster could temporarily control the majority of hashing capacity, enabling double-spending of local currency.
- Endpoint and credential vulnerability: Distributed ledgers secure transaction logs, but do not prevent phishing, malware key-logging, or lost seed phrases at the user device level; without central account recovery, stolen credentials result in permanent loss.
Scalability bottlenecks in proof-of-work networks:
- Low transaction throughput (TPS limits): Enforcing strict block size constraints and predetermined block generation intervals (e.g., 10 minutes) severely caps peak transaction volume. If the Santa Monica municipal economy expands and thousands of shoppers make simultaneous purchases, transaction backlogs and unconfirmed queues will proliferate.
- Network latency and propagation delays: Distributing every transaction and block to all municipal nodes requires substantial network bandwidth; during retail rush hours, synchronization delays could lead to temporary chain forks and payment friction.
- Computational and storage bloat: Every full node must maintain a complete historical copy of the distributed ledger. As transaction history accumulates over years, storage requirements and memory consumption grow steadily, discouraging small local merchants from hosting independent validating nodes.
Strategic conclusion and recommendation:
Pablo's assertion is partially flawed: while blockchain delivers strong cryptographic security and decentralization, proof-of-work architectures inherently trade off scalability to maintain distributed consensus (the classic blockchain trilemma). To make MONS practical for everyday retail use, Santa Monica should avoid heavy proof-of-work mining and instead implement an energy-efficient permissioned Byzantine fault-tolerant or Proof-of-Authority (PoA) consensus model managed across trusted local institutions, or deploy a layer-2 state channel payment framework to achieve instant, high-throughput retail settlements.

Mentor tip

Our analysis

Where the marks are

Each part sorted by the topic it mostly tests. Networks carries the most marks on this paper.

Networks22 marks · 73%
Q1, Q3, Q4
System fundamentals4 marks · 13%
Q2
Abstract data structures4 marks · 13%
Q2

Mentor insights

Traps to watch for

01
Confusing unmined block assembly with nonce verification · Q1
Creating a unmined block involves aggregating unconfirmed transactions into a Merkle tree; finding the proof-of-work nonce is an independent iterative hashing step against target difficulty.
02
Assuming small private blockchains share the 51% resistance of public networks · Q2
A localized municipal currency operates with relatively low total network hashing power, making it far more vulnerable to a 51% attack than large global networks.
03
Overlooking the fundamental blockchain trilemma between security and throughput · Q4
Proof-of-work cryptocurrencies cannot scale to high transaction volumes without compromising decentralization or block interval safety; claiming both without qualification ignores fundamental architectural limits.

Solutions and tips are GeorgeTheTutor's own; the questions are not reproduced here. Not affiliated with or endorsed by the International Baccalaureate Organization.

Want someone to go through your paper with you?

Our maths mentors took these exams recently. One-to-one, they'll find where your marks are going and fix it before May.

Find your maths mentor More past papers