Final Technical Review

Section IX: Applications and Synthesis

Army Cyber Institute

April 9, 2026

Why This Technical Review Matters

• This course moved quickly across cryptography, distributed systems, consensus, Bitcoin, Ethereum, and forensics
• The final exam asks you to explain how these ideas fit together, not just recognize isolated terms
• Today is a focused rebuild of the technical stack before the course closes

Overall Slide Concept This slide frames the lesson as an integration exercise rather than a last-minute cram session. It matters here because students need to rebuild the full technical stack before the exam and see how the course modules connect. Emphasize that the review is about causal relationships across layers, not isolated vocabulary.

Key Points - Re-center the class on mechanisms from cryptography through forensics. - Stress that the exam rewards explanation and synthesis more than term recognition. - Set expectations for a fast review that repeatedly ties one module to the next.

Walkthrough None

Sources [1]; [2]; [3]

Technical Review Objectives

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

1. Explain the core technical role of hashing, Merkle roots, and digital signatures in blockchain systems
2. Contrast centralized, distributed, permissioned, and permissionless architectures
3. Compare classical consensus, Proof of Work, and Proof of Stake at a high level
4. Reconstruct the key technical ideas behind Bitcoin and Ethereum
5. Explain how blockchain forensics relies on both transparent ledgers and off-chain identity links

Overall Slide Concept This slide gives students a roadmap for what they should be able to explain by the end of the review. It matters here because the rest of the lesson moves quickly across domains and needs a visible set of anchor goals. Emphasize that these objectives define the conceptual through-line for the course closeout.

Key Points - Highlight the four major technical layers being revisited: primitives, systems, consensus, and platform design. - Point out that Bitcoin, Ethereum, and forensics are being reviewed as applications of those layers. - Spell out that P2P means peer-to-peer and UTXO means unspent transaction output.

Walkthrough None

Sources None

The Blockchain Stack at a Glance

• Cryptography gives integrity, commitments, and authorization
• Peer-to-peer networking moves transactions and blocks without a central server
• Consensus lets many nodes converge on one ledger history
• Ledger/data structures record history in a tamper-evident form
• Applications build wallets, tokens, smart contracts, and services on top

Overall Slide Concept This slide re-establishes blockchain as a layered system rather than a single invention. It matters here because the lesson will revisit each layer separately and then reconnect them. Emphasize that failures or tradeoffs at one layer propagate into the layers above it.

Key Points - Cryptography secures data, authorization, and integrity. - Distributed networking moves data among nodes without one central operator. - Consensus coordinates state updates so many replicas can accept one shared history.

Walkthrough None

Sources None

One Transaction, End to End

1. A user creates a transaction and signs it with a private key
2. The transaction is broadcast across a peer-to-peer network
3. Nodes validate structure, signatures, and policy rules
4. A miner or validator proposes a block containing the transaction
5. Consensus determines whether that block becomes part of the accepted history
6. The transaction later becomes evidence for accounting, auditing, or forensics

Overall Slide Concept This slide reconstructs the full lifecycle of a blockchain transaction from creation through settlement. It matters here because it links together nearly every technical concept students learned in the course. Emphasize that no single mechanism solves the problem alone; the system works because the layers cooperate.

Key Points - A transaction is signed, propagated, validated, and committed through several distinct stages. - Each stage depends on different mechanisms such as signatures, gossip, mempools, and consensus. - Finality is the result of the full process, not just submission by the user.

Walkthrough 1. A user creates and signs a transaction with a private key. 2. Peers relay the transaction and nodes validate its format and authorization. 3. A proposer or miner includes it in a block that the consensus process accepts.

Sources [1]; [4]; [5]

Why Cryptography Matters in Blockchain

• Blockchain does not eliminate trust problems by magic
• It replaces some trust in institutions with trust in math, protocol rules, and distributed verification
• Cryptography helps answer three core questions:
  • Has data changed?
  • Who authorized this action?
  • Can many parties verify the same claim efficiently?

Overall Slide Concept This slide explains why blockchain security begins with cryptographic primitives rather than trust in an administrator. It matters here because the review starts from the lowest technical layer before moving upward. Emphasize that cryptography provides integrity and authorization, but not by itself full system security.

Key Points - Hashing, signatures, and randomness support the core security assumptions of the ledger. - Cryptography constrains what honest and dishonest actors can do to data and ownership claims. - Security still depends on correct implementation and system design, not mathematics alone.

Walkthrough None

Sources [1]; [3]

Hashing: What Problem Does It Solve?

• A cryptographic hash maps arbitrary input to a fixed-length digest
• Hashes are used as compact fingerprints of data
• In blockchains, hashes support:
  • Tamper evidence
  • Block linking
  • Commitments to large data sets
  • Efficient verification

Overall Slide Concept This slide clarifies that hashing is used to compress and commit to data in a tamper-evident way. It matters here because later slides rely on students understanding why hashes appear throughout blocks, trees, and identifiers. Emphasize the idea of compact commitments rather than encryption.

Key Points - A cryptographic hash function maps arbitrary input to a fixed-size digest. - The digest lets nodes check integrity without storing or comparing full inputs each time. - Hashing does not hide data; it gives a compact fingerprint of data.

Walkthrough None

Sources [1]; [2]

Hash Properties That Matter for Blockchain

• Deterministic: same input, same output
• Preimage resistant: hard to recover the original input from the digest
• Second-preimage resistant: hard to find a different input with the same digest as a chosen message
• Collision resistant: hard to find any two distinct inputs with the same digest
• Avalanche effect: small input changes produce very different outputs

Overall Slide Concept This slide identifies the specific hash properties blockchain systems rely on in practice. It matters here because the security story for blocks and Merkle roots depends on these properties being hard to break. Emphasize preimage resistance, second-preimage resistance, and collision resistance as distinct ideas.

Key Points - Preimage resistance makes it hard to recover an input from its digest. - Collision resistance makes it hard to find two different inputs with the same digest. - Second-preimage resistance matters when an attacker tries to swap one valid message for another.

Walkthrough None

Sources [1]; [2]

Avalanche Effect: Tiny Change, Very Different Output

• One small change in input should produce a radically different digest
• That makes hash outputs hard to predict and helps expose tampering

Hash("HELLO")
3615f80c9d293ed7402687f94b22d58e...

Hash("HELLo")
c6f4b0a7af12e91b3ca3e1e7100e2971...

Overall Slide Concept This slide shows why tiny changes in input produce dramatically different hash outputs. It matters here because blockchain depends on even small tampering being immediately visible in downstream hashes. Emphasize that this sensitivity is what makes chained records tamper-evident.

Key Points - Small input changes should produce unrelated-looking outputs. - This makes near-miss tampering easy to detect and hard to conceal. - Avalanche behavior supports block chaining, Merkle proofs, and integrity checks.

Walkthrough None

Sources [1]; [6]

Hashing in Blockchain Practice

• Blocks include hashes of previous blocks to form a chain
• Transactions and headers are hashed repeatedly during validation and consensus
• Nodes can compare short digests instead of entire files or histories
• If a hash-linked record changes, later hashes no longer match

Overall Slide Concept This slide connects abstract hash properties to the places students actually see hashing in blockchain systems. It matters here because review works best when the primitive is tied back to concrete system roles. Emphasize that hashing is reused repeatedly for different technical jobs.

Key Points - Hashes identify blocks, transactions, and committed data structures. - Merkle roots summarize many transactions in one block-header field. - Proof-of-Work also turns hashing into an economic resource test.

Walkthrough None

Sources None

Merkle Trees: Why They Exist

• A block can contain many transactions
• Instead of storing every transaction in the header, the system commits to them with a tree of hashes
• Leaf hashes represent individual items
• Parent hashes combine child hashes until a single top value remains
• Top value: the Merkle root

Overall Slide Concept This slide explains why blockchain systems need a data structure more efficient than checking every transaction one by one. It matters here because Merkle trees connect hashing to scalable verification. Emphasize that the tree lets nodes prove membership without sending the whole block.

Key Points - A Merkle tree combines many transaction hashes into one root. - This structure supports efficient inclusion proofs for lightweight verification. - The root changes if any underlying transaction data changes.

Walkthrough None

Sources None

Why the Merkle Root Matters

• It is a compact commitment to all transactions in the block
• Changing even one transaction changes the Merkle root
• It allows efficient inclusion proofs without downloading the full block body
• It lets lightweight clients verify membership with a path of sibling hashes
• The Merkle root is not just another field in the block header
• It is the block’s compact cryptographic commitment to the full transaction set
• It matters because it enables:
  • Tamper detection
  • Efficient verification
  • Lightweight client proofs
  • Header-first validation strategies

Overall Slide Concept This slide turns the Merkle tree into an operational concept by focusing on the root. It matters here because the root is the block-level commitment that lightweight clients can rely on. Emphasize that trust in the root still depends on trust in the broader chain and consensus process.

Key Points - The Merkle root commits to the full transaction set in a compact form. - Membership proofs let a client verify inclusion using only a small branch of hashes. - This supports simplified verification without downloading every transaction.

Walkthrough 1. Start from the transaction hash being proved. 2. Recompute the path of sibling hashes up to the root. 3. Compare the recomputed root with the root stored in the accepted block header.

Sources [1]; [6]; [7]

Asymmetric Crypto and Digital Signatures

• Public-key cryptography separates a public verification key from a private signing key
• In blockchain, signatures are often more important than encryption
• A valid signature shows that the holder of the private key authorized the transaction
• Other nodes can verify that authorization using only the public key or address data

Overall Slide Concept This slide reviews how public-key cryptography authorizes transactions without sharing secret material. It matters here because blockchain ownership claims are expressed through signatures rather than account managers. Emphasize that signatures prove authorization, not necessarily identity.

Key Points - A private key signs; a public key verifies. - Digital signatures let the network check that a spender is authorized. - Asymmetric means the signing key and verification key are different.

Walkthrough 1. A user signs a message or transaction with a private key. 2. Other nodes verify the signature using the corresponding public key. 3. Valid signatures allow the network to accept the authorization claim.

Sources [4]; [5]

Keys, Wallets, Addresses, and Ownership

• A private key is the critical secret
• A public key is derived from the private key and supports verification
• An address is usually a shorter identifier derived from public-key material or script conditions
• A wallet manages keys, addresses, and signing operations
• Control of funds depends on control of keys, not on knowing someone’s name

Overall Slide Concept This slide separates several concepts that students often merge together in casual conversation. It matters here because blockchain systems treat keys, addresses, and wallet software as related but distinct layers. Emphasize that control of a private key is closer to ownership than the interface a user sees.

Key Points - A wallet is software or hardware that helps manage keys and transactions. - An address is a public-facing identifier derived from key material under a protocol’s rules. - Ownership in practice means the ability to produce valid signatures or otherwise satisfy spend conditions.

Walkthrough None

Sources [8]; [4]

When Cryptography Fails in Practice

• Strong algorithms do not help if implementations are weak
• Common failures include:
  • Poor randomness
  • Weak key generation
  • Key leakage
  • Bad validation logic
  • Unsafe wallet recovery procedures
• Blockchain losses often come from operational failures, not broken math

Overall Slide Concept This slide reminds students that good primitives do not save bad implementations. It matters here because protocol-level trust can still be undermined by key leaks, poor randomness, and operational mistakes. Emphasize that the attack surface includes software engineering and human handling.

Key Points - Implementation bugs and unsafe defaults can defeat theoretically sound cryptography. - Key management and randomness are recurring practical failure points. - Security reviews must include operational and software layers, not just math.

Walkthrough None

Sources [1]; [9]

Cryptographic Challenges Moving Forward

• Quantum risk is more serious for current public-key systems like RSA and ECC than for hash functions
• Hash-based security is weakened by Grover-style speedups, but not destroyed in the same way signature systems are threatened by Shor-style attacks
• Blockchain migration challenges include:
  • Large installed key base
  • Long-lived addresses
  • Backward compatibility
  • “Harvest now, decrypt later” style concerns for public data and exposed keys

Overall Slide Concept This slide bridges classic cryptography into future-looking risk. It matters here because blockchain systems have long lifetimes and must plan for migration before assumptions fail. Emphasize that cryptographic agility is a governance and engineering challenge, not just a research topic.

Key Points - Post-quantum migration is slow because live systems cannot switch assumptions instantly. - Long-lived addresses, signatures, and archived data create transition pressure. - Protocol upgrades require coordination across software, users, and institutions.

Walkthrough None

Sources [10]; [11]

Case Reminder: Milk Sad and Bad Entropy

• Wallet safety depends on good randomness
• If seed phrases or private keys are generated from weak entropy, the wallet may be predictable
• The lesson is broader than one bug:
  • Cryptography can be correct on paper and still fail in deployment
  • Blockchain systems amplify the cost of key-management mistakes because irreversible transfers are easy

Overall Slide Concept This slide grounds the implementation-risk discussion in a concrete blockchain failure. It matters here because students need to remember that randomness is not an abstract detail when keys are involved. Emphasize that entropy means the unpredictability needed to generate secure secrets.

Key Points - Bad entropy can make supposedly secret keys guessable. - The Milk Sad case shows how wallet generation mistakes become theft opportunities. - Randomness quality is a system dependency, not an optional refinement.

Walkthrough None

Sources [1]; [12]

Centralized vs Distributed Architectures

• A centralized system has a clear control point and often a simpler operating model
• A distributed system spreads responsibility across multiple machines or organizations
• Blockchain adopts distributed designs to reduce reliance on a single trusted operator
• This improves resilience in some ways, but also adds coordination, latency, and consistency problems

Overall Slide Concept This slide contrasts the basic control patterns behind traditional systems and blockchain-style systems. It matters here because later consensus and governance choices make more sense once the architectural tradeoff is clear. Emphasize that distributed does not automatically mean decentralized.

Key Points - Centralized systems are simpler to coordinate but create single points of control and failure. - Distributed systems improve resilience but increase coordination complexity. - Decentralized means power is dispersed, not merely that many machines exist.

Walkthrough None

Sources [13]; [1]

Why Blockchain Pushes Toward P2P

• Permissionless blockchains try to minimize trust in any single operator or organization
  • A central server would have to be trusted not to fail, censor, or behavoe maliciously
• Blockchain networks want many participants to receive transactions, validate blocks, relay information, and maintain ledger history
• P2P design supports openness, redundancy, and censorship resistance, while permissioned systems often reintroduce more trusted service layers

Overall Slide Concept This slide explains why public blockchains lean on peer-to-peer networking instead of a central relay. It matters here because open participation depends on information moving without a privileged hub. Emphasize that P2P means peer-to-peer communication among nodes of the same network.

Key Points - Peer-to-peer designs reduce reliance on a single distribution point. - Gossip-style propagation helps spread transactions and blocks quickly across the network. - This openness creates resilience but also introduces new attack surfaces.

Walkthrough None

Sources [7]; [13]

Gossip vs DHTs

• Gossip/unstructured relay is good for spreading new information widely
• Distributed Hash Table/structured overlay routing is good for efficient lookup in large networks
• Tradeoff:
  • Gossip favors resilience and simple dissemination
  • DHTs favor efficient routing and discovery

Overall Slide Concept This slide compares two overlay-network ideas students encountered earlier in the course. It matters here because blockchain uses broadcast-heavy communication differently from structured lookup systems. Emphasize that DHT means distributed hash table.

Key Points - Gossip is good for broad dissemination of new data such as blocks and transactions. - DHTs are designed for structured lookup and routing rather than wide broadcast. - Blockchain networks may combine ideas, but the core relay problem usually looks gossip-heavy.

Walkthrough None

Sources [13]; [14]

Peer Discovery and Churn

• New nodes need a way to find their first peers
• Real networks must handle nodes joining, leaving, failing, or moving
• A healthy blockchain network needs:
  • Bootstrapping mechanisms
  • Ongoing peer replacement
  • Diversity in connections
  • Tolerance for churn and partial partitions

Overall Slide Concept This slide reviews how nodes find one another and remain connected in a changing network. It matters here because peer-to-peer systems only work if they can tolerate constant joins, leaves, and failures. Emphasize that churn means continual turnover in participating peers.

Key Points - Nodes need discovery mechanisms to locate useful peers without central coordination. - Healthy networks must keep operating as peers join, disconnect, or change addresses. - Connectivity quality affects propagation speed, resilience, and eclipse risk.

Walkthrough None

Sources [15]; [14]

P2P Threats: Sybil and Eclipse

• A Sybil attack tries to gain influence by creating many fake identities
• An eclipse attack tries to isolate a node from honest peers and control what it sees
• These attacks matter because even strong cryptography is not enough if a node’s network view is manipulated
• Open systems need technical and economic defenses, not just identity checks

Overall Slide Concept This slide highlights two of the most important peer-to-peer threats in open blockchain networks. It matters here because networking attacks can distort a node’s view even if cryptography remains intact. Emphasize that a Sybil attack means creating many fake identities and an eclipse attack means surrounding a target with attacker-controlled peers.

Key Points - Sybil attacks try to gain influence by multiplying apparent identities. - Eclipse attacks isolate a victim’s network view and can support higher-level fraud or manipulation. - Peer diversity, admission controls, and robust discovery reduce these risks.

Walkthrough None

Sources [16]; [17]

Permissioned vs Permissionless Systems

• Permissionless systems allow open participation and must resist unknown adversaries
• Permissioned systems restrict membership and usually know who participants are
• This changes:
  • Admission control
  • Identity management
  • Governance
  • Privacy expectations
  • Consensus design

Overall Slide Concept This slide contrasts open blockchain participation with curated membership models. It matters here because consensus, governance, and threat assumptions shift dramatically depending on who may join. Emphasize that permissioned systems restrict participation while permissionless systems allow open entry.

Key Points - Permissionless systems optimize for openness and adversarial resilience. - Permissioned systems trade openness for control, performance, and identifiable participants. - Admission policy changes both the governance model and the threat model.

Walkthrough None

Sources [16]; [17]

Where Hyperledger Fabric Fits

• Fabric is a permissioned distributed ledger platform
• It assumes known organizations, managed identities, and policy-driven participation
• Trust is managed through:
  • MSPs and certificate authorities
  • Endorsement policies
  • Ordering services
  • Governance agreements

Overall Slide Concept This slide gives students a concrete example of a permissioned ledger architecture. It matters here because Fabric shows how enterprise blockchain design diverges from public-chain design. Emphasize that Fabric uses known organizations, modular components, and policy-driven control.

Key Points - Hyperledger Fabric separates transaction endorsement, ordering, and validation roles. - Known participants reduce some open-network threats but introduce governance and administration assumptions. - It is best understood as a business network platform rather than a permissionless cryptocurrency system.

Walkthrough None

Sources [3]; [2]

What Consensus Is Actually Trying to Guarantee

• Consensus is about getting many nodes to agree on ledger state or history
• Earlier in the course, we framed the core properties as SLVA:
  • Safety: honest nodes do not finalize conflicting outcomes
  • Liveness: the system continues making progress
  • Validity: decided values must satisfy the protocol’s rules
  • Agreement: honest nodes converge on the same result

Overall Slide Concept This slide clarifies the real job of consensus beyond the vague idea of agreement. It matters here because both classical and blockchain-style protocols are best compared by the guarantees they aim to deliver. Emphasize safety and liveness as the main conceptual anchors.

Key Points - Safety asks whether honest nodes avoid accepting conflicting histories. - Liveness asks whether honest activity eventually makes progress. - Consensus manages replicated state under failure and, sometimes, active attack.

Walkthrough None

Sources [3]; [2]; [16]

Classical vs Economic Consensus

• Classical consensus usually assumes known participants and focuses on message exchange, quorum rules, and fault models
• Economic consensus adds incentives, resource costs, or stake penalties to shape behavior in open systems
• Permissioned ledgers: usable because membership is curated and identity is managed
• Permissionless blockchains: needed because anyone may try to participate, relay, or attack

Overall Slide Concept This slide compares two families of consensus students saw in the course. It matters here because blockchain protocols borrow the goal of replicated agreement but rely on very different enforcement tools. Emphasize that classical protocols lean on bounded membership while economic protocols lean on costly participation and incentives.

Key Points - Classical consensus assumes known participants and explicit fault thresholds. - Economic consensus uses scarce resources or stake to discourage bad behavior. - The membership model strongly shapes performance, security, and governance.

Walkthrough None

Sources None

Proof of Work

• PoW uses a computational puzzle to make block production costly
• Producing a block is expensive, but checking a proposed block is cheap
• This creates an objective eligibility rule for blocks in open networks
• Security comes from the real-world cost of rewriting history at scale

Overall Slide Concept This slide reintroduces Proof of Work as an economic consensus mechanism built around costly computation. It matters here because Bitcoin’s security model depends on turning block production into a resource competition. Emphasize that work is probabilistic and externalized through energy and hardware costs.

Key Points - Miners compete to find a valid block hash below the current target. - The protocol uses difficulty to regulate how often valid blocks appear. - Security comes from the cost of rewriting history at scale.

Walkthrough 1. Miners assemble candidate blocks and vary a nonce or related fields. 2. They hash repeatedly until a candidate satisfies the network target. 3. The network accepts the valid block and extends the chain with the most accumulated work.

Sources [7]; [3]

Difficulty, Work, and Probabilistic Finality

• The target determines how hard it is to find a valid block
• Difficulty adjustment may be used to help keep average block intervals near an intended schedule
• Finality in PoW is usually probabilistic:
  • A payment becomes safer as more work accumulates after it
  • The chain is never impossible to fork or replace, but doing so becomes costlier as more work accumulates

Overall Slide Concept This slide explains why Proof of Work gives confidence gradually rather than instantly. It matters here because students often treat block inclusion as final when it is really probabilistic under PoW. Emphasize that finality is confidence that increases as more work is built on top of a block.

Key Points - Difficulty tunes the expected effort required to mine a block. - Accumulated work makes older blocks progressively harder to replace. - Probabilistic finality means certainty is approximated rather than absolute.

Walkthrough None

Sources [7]; [3]

Common PoW Attack Themes

• Majority hash-power attacks: dominant mining power can outcompete honest miners and replace recent chain history.
• Double-spend attempts: an attacker spends funds, then tries to build an alternate branch that excludes the original payment.
• Selfish mining and strategic withholding: miners keep blocks private to gain an advantage over honest miners.
• Censorship through block construction choices: miners or pools can refuse to include selected transactions.
• Network-level attacks: routing, eclipse, or partition attacks distort what miners and nodes see.

Overall Slide Concept This slide summarizes the recurring attack patterns against Proof of Work systems. It matters here because the protocol is secure only relative to its resource-distribution assumptions. Emphasize that many attacks aim to distort incentives, visibility, or majority control rather than break hashing itself.

Key Points - Majority-hash attacks threaten reorderability and double-spend resistance. - Selfish mining and related strategies exploit coordination and information asymmetries. - Security depends on economic decentralization as much as protocol rules.

Walkthrough None

Sources [7]; [3]; [15]

Proof of Stake

• PoS replaces energy-intensive work with stake-weighted participation
• Core flow:
  • A proposer is selected for a slot or round
  • A committee attests to the proposed block
  • Votes accumulate toward checkpoints and finality

Overall Slide Concept This slide reintroduces Proof of Stake as a different way to make consensus expensive to attack. It matters here because students need to contrast stake-based security with work-based security without assuming they are identical. Emphasize that the scarce resource is bonded stake rather than computation.

Key Points - Validators are selected or scheduled based on stake-backed participation. - Misbehavior can be punished economically through slashing or related penalties. - The protocol trades hardware costs for governance and incentive complexity.

Walkthrough 1. Validators lock stake to become eligible for protocol duties. 2. The protocol assigns proposing and attesting roles across time slots or rounds. 3. Finality emerges when enough honest stake votes consistently for the same history.

Sources [18]; [19]

Validators, Committees, and Finality

• A validator is a participant authorized by stake to help secure the chain
• Committees are randomly selected subsets of validators that check proposals in a slot
• This structure avoids every validator talking to every other validator on every block
• Every epoch, a stake-weighted supermajority vote finalizes the blocks

Overall Slide Concept This slide breaks Proof of Stake into the operational roles students need to remember. It matters here because modern PoS systems are easier to understand when separated into proposers, attesters, committees, and finality rules. Emphasize that committee means a subset of validators assigned to evaluate a block or slot.

Key Points - Validators do not all perform the same task at the same time. - Committees distribute validation duties and help scale coordination. - Finality rules make reverting older decisions increasingly costly or impossible under assumptions.

Walkthrough 1. A proposer assembles a candidate block for the current slot or round. 2. Assigned validators or committees attest to what they observe as valid. 3. Finality logic aggregates those votes into stronger commitment to one chain state.

Sources [18]; [19]

Common PoS Attack Themes

• Nothing-at-stake incentives: validators may be tempted to support multiple forks if equivocation is not punished.
• Long-range attacks: old validator keys or historical stake can be abused to fabricate an alternate past.
• Weak subjectivity: new or offline nodes need trustworthy recent checkpoints to avoid bad histories.
• Censorship and cartel behavior: large validator groups can coordinate to delay or exclude targeted transactions.
• Bribery and concentration risks: stake concentration can make collusion or economic coercion more effective.

Overall Slide Concept This slide reviews the main ways stake-based consensus can be attacked or distorted. It matters here because PoS changes the cost model but not the need for careful adversarial reasoning. Emphasize that these threats target incentives, coordination, and governance, not just validator software.

Key Points - Nothing-at-stake and long-range-style concerns arise from the ability to sign cheaply. - Validator concentration can create governance and censorship pressure. - Defenses rely on slashing, checkpointing, social coordination, and client discipline.

Walkthrough None

Sources None

Consensus Families

• Permissioned/classical consensus gives strong deterministic finality under curated membership
• PoW gives open participation with computationally costly block production and probabilistic finality
• PoS gives open participation with stake-based security enforced through slashing and structured finality
• The right question is not “which one is best?” but “which assumptions and tradeoffs fit the system?”

Overall Slide Concept This slide gives students one last high-level comparison across the main consensus approaches. It matters here because the review is moving from abstract protocol families into specific chains and platforms. Emphasize which assumptions change and which goals stay constant across the families.

Key Points - All consensus families aim to coordinate replicated state under failure. - Membership, cost model, and finality behavior are the main differentiators. - Choosing a family means choosing a threat model and governance style.

Walkthrough None

Sources None

Why Bitcoin Emerged

• Bitcoin grew out of long-running digital cash efforts and cypherpunk thinking
• The 2008 financial crisis sharpened distrust in centralized financial intermediaries
• Thecombination of existing concepts drawn from cryptography, peer-to-peer networking, trust and conesensus, and lessons from failed digital cash efforts provided the foundation for Bitcoin and subsequent blockchain techniolgies
  • Nakamoto (Proof-of-Work) consensus was the final key to making the decentralized digital cash work

Overall Slide Concept This slide reconnects Bitcoin to the earlier digital-cash and cypherpunk history. It matters here because Bitcoin is best understood as a synthesis of older ideas under a new trust model. Emphasize the double-spend problem and the search for non-state digital cash.

Key Points - Bitcoin combined earlier cryptographic ideas with peer-to-peer consensus and issuance rules. - It emerged in response to both technical and political dissatisfaction with central intermediaries. - Its novelty was the package: incentives, hashing, and open participation working together.

Walkthrough None

Sources None

Bitcoin’s Core Design Synthesis

• Digital signatures define who can authorize spending
• Peer-to-peer networking spreads transactions and blocks
• Proof of Work helps open participants converge on one history
• Hash-linked blocks and Merkle commitments make history tamper-evident
• Together, these mechanisms address double-spending without a central operator

Overall Slide Concept This slide condenses Bitcoin into a small set of cooperating mechanisms. It matters here because students should leave the course able to explain Bitcoin as a layered design, not just a token. Emphasize how signatures, chained blocks, and economic consensus jointly address double spending.

Key Points - Digital signatures authorize spending of valid outputs. - Hash-linked blocks create a tamper-evident transaction history. - Proof of Work and longest-chain selection coordinate agreement on one history.

Walkthrough None

Sources None

Bitcoin Block Structure

• A Bitcoin block contains a header plus a body of transactions
• Key header fields include:
  • Version
  • Previous block hash
  • Merkle root
  • Timestamp
  • Difficulty target representation
  • Nonce

Overall Slide Concept This slide revisits what is actually inside a Bitcoin block. It matters here because many later ideas, from Merkle roots to mining, depend on the header-body distinction. Emphasize how compact header fields summarize larger bodies of transaction data.

Key Points - The block header contains fields that miners hash and peers validate. - The transaction list contains the payload whose integrity is summarized by the Merkle root. - Different fields serve different jobs: identification, ordering, difficulty, and commitment.

Walkthrough 1. The header records metadata such as previous block hash, Merkle root, timestamp, target, and nonce. 2. The body holds the transactions included in the block. 3. Together they let nodes verify both chain position and transaction-set integrity.

Sources None

Bitcoin Transactions and the UTXO Model

• Bitcoin tracks spendable outputs, not account balances
• A transaction consumes old outputs and creates new outputs
• Change usually returns to a new output controlled by the sender
• This model matters for:
  • Transaction structure
  • Fee calculation
  • Wallet behavior
  • Forensic clustering heuristics

Overall Slide Concept This slide revisits Bitcoin’s transaction model as a flow of spendable outputs. It matters here because students often carry account-model intuitions into Bitcoin and miss how ownership and validation really work. Emphasize that UTXO means unspent transaction output.

Key Points - Bitcoin transactions consume prior outputs and create new outputs. - Validation checks that referenced outputs are valid, unspent, and properly authorized. - The model makes state explicit as a set of spendable pieces rather than account balances.

Walkthrough 1. A transaction points to existing outputs it wants to spend. 2. It provides unlocking data, usually signatures, to satisfy the spending conditions. 3. It creates new outputs that become future UTXOs for later transactions.

Sources None

Bitcoin Monetary Policy and Difficulty

• New coins enter circulation through block subsidies
• The subsidy schedule declines over time through halvings
• The total supply cap is designed around a 21 million BTC limit
• Difficulty adjusts every 2016 blocks to target about a 10-minute average block interval despite changes in hash rate

Overall Slide Concept This slide ties Bitcoin’s issuance schedule to its mining adjustment logic. It matters here because students should understand that monetary policy and consensus tuning are linked in Bitcoin. Emphasize that issuance is rule-based while difficulty stabilizes block timing.

Key Points - New bitcoin enters circulation through block rewards that decline over time. - Difficulty adjustment keeps expected block production near the protocol target despite hash-rate changes. - Scarcity and security are related but not identical design goals.

Walkthrough None

Sources None

Bitcoin Nodes, Relay, and Peer Discovery

• Full nodes validate rules and maintain the ledger independently
• Transactions and blocks spread through peer-to-peer relay
• New nodes need a bootstrapping path to peers
• Once connected, nodes keep learning about the network through peer communication and gossip propagation

Overall Slide Concept This slide revisits the network layer that supports Bitcoin’s consensus layer. It matters here because blocks do not matter if they cannot propagate through the network promptly and honestly. Emphasize that node behavior includes validation, relay, and neighbor management.

Key Points - Nodes discover peers, exchange inventory, and relay transactions and blocks. - Propagation quality affects mempool visibility and fork resolution. - Networking assumptions influence both performance and attack exposure.

Walkthrough 1. A node learns about peers through discovery mechanisms and prior connections. 2. It exchanges announcements and requests for transactions or blocks. 3. It validates received data locally before relaying accepted information onward.

Sources None

Mining Pools and Their Role

• Solo mining has high reward variance
• Pools reduce variance by letting miners combine effort and share payouts
• Pools change incentives and centralization pressures even if the protocol remains permissionless
• Pools are economically important, but they are not identical to the protocol itself
• Concentration in pools can create real security concerns

Overall Slide Concept This slide explains why many miners aggregate effort instead of mining entirely alone. It matters here because mining decentralization looks different once variance and payout smoothing are introduced. Emphasize that pools coordinate rewards and can influence governance pressure points.

Key Points - Pools reduce payout variance for individual miners by sharing rewards. - Pooling can improve economic stability while increasing concentration risk. - Operational centralization can emerge even when hardware ownership is widespread.

Walkthrough None

Sources None

Ethereum’s Goals

• Ethereum extends blockchain beyond payments into general-purpose programmable state
• The core vision is a platform for smart contracts and decentralized applications
• Ethereum shifts the central design question from “How do we transfer digital money?” to “How do we execute shared logic on a decentralized system?”

Overall Slide Concept This slide contrasts Ethereum’s ambitions with Bitcoin’s narrower original focus. It matters here because students need to understand why Ethereum introduced new execution and state-management complexity. Emphasize programmability as the core expansion.

Key Points - Ethereum aims to support general-purpose on-chain computation, not only payments. - Its design centers smart contracts and shared state transitions. - That broader scope expands use cases while increasing complexity and risk.

Walkthrough None

Sources None

EVM, Gas, and Global State

• Ethereum maintains a shared global state rather than Bitcoin’s UTXO set
• The EVM executes contract logic deterministically
• Gas meters computation and storage use; the base fee is burned while tips can go to the proposer
• If a transaction runs out of gas, state changes revert but the spent gas is still lost

Overall Slide Concept This slide reviews the execution model that makes Ethereum programmable. It matters here because later smart-contract and scaling slides rely on students understanding execution cost and shared state. Emphasize that EVM means Ethereum Virtual Machine.

Key Points - The EVM executes contract code against a shared global state. - Gas meters computation and storage usage to price execution and limit abuse. - All nodes do not invent their own answers; they reproduce the same state transition rules.

Walkthrough None

Sources None

Accounts vs UTXOs

• Bitcoin’s UTXO model represents value as discrete spendable outputs
• Ethereum’s account model represents balances and contract state directly
• The difference affects:
  • Transaction structure
  • Smart contract design
  • Wallet semantics
  • Forensics and tracing

Overall Slide Concept This slide helps students compare Ethereum’s account model with Bitcoin’s UTXO model. It matters here because design choices about state shape downstream wallet behavior, privacy, and contract logic. Emphasize that an account model stores balances in named state entries rather than spendable output sets.

Key Points - Bitcoin tracks spendable outputs, while Ethereum tracks account state directly. - Account models can simplify some application logic but change validation and privacy properties. - The transaction model influences how smart contracts, wallets, and analytics behave.

Walkthrough None

Sources None

The Merge and Two-Layer Ethereum

• Ethereum moved from PoW to PoS in The Merge
• The modern system separates:
  • Execution layer: transactions, EVM execution, state transitions
  • Consensus layer: validator coordination, fork choice, finality
• The application state stayed continuous, but the block-production and finality engine changed underneath it
• That separation matters because scaling, client software, and upgrades often affect one layer more than the other

Overall Slide Concept This slide reviews Ethereum’s move from Proof of Work to Proof of Stake and the resulting execution-consensus split. It matters here because modern Ethereum is easier to understand as two cooperating layers. Emphasize that the execution layer processes transactions while the consensus layer finalizes blocks.

Key Points - The Merge replaced mining with validator-based consensus. - Ethereum now separates execution responsibilities from consensus responsibilities. - This architecture clarifies upgrade paths and role boundaries.

Walkthrough None

Sources None

EOAs vs Contract Accounts

• Externally Owned Accounts (EOAs) are controlled by private keys and initiate transactions
• Contract accounts hold code and storage, but only execute when called
• This distinction matters for:
  • Wallet behavior and nonce handling
  • Access control and smart contract design
  • Forensics, because some addresses are users and some are programs

Overall Slide Concept This slide distinguishes user-controlled accounts from code-controlled accounts. It matters here because many smart-contract interactions are really relationships between these two account types. Emphasize that EOA means externally owned account.

Key Points - EOAs are controlled by private keys and can initiate transactions directly. - Contract accounts hold code and react according to deployed logic. - Understanding the difference is crucial for security and execution flow.

Walkthrough None

Sources None

Block Building

• Block construction is often specialized rather than handled only by the proposer
• Maximal Extractable Value (MEV) is the value gained from transaction ordering, inclusion, or exclusion
• Key actors:
  • Searchers identify profitable orderings
  • Builders assemble candidate blocks
  • Relays forward bids and blocks to proposers
• That makes Ethereum block production an ecosystem with real censorship and centralization pressure

Overall Slide Concept This slide explains who actually assembles candidate Ethereum blocks in the modern stack. It matters here because students need to connect incentives, MEV, and proposer-builder separation to protocol operation. Emphasize that MEV means maximal extractable value.

Key Points - Modern block production can involve proposers, builders, and relays rather than one simple actor. - Transaction ordering creates both revenue opportunities and fairness concerns. - The block-building stack affects centralization and censorship pressure.

Walkthrough 1. Transactions enter shared pools or builder pipelines. 2. Builders assemble candidate blocks that optimize for validity and revenue. 3. Proposers select or publish a block that the consensus layer then advances.

Sources None

Smart Contracts: What They Are

• A smart contract is code stored on-chain and executed by the network
• It can hold state, enforce rules, and expose callable functions
• Smart contracts support:
  • Tokens
  • Exchanges
  • Lending
  • Governance
  • NFT logic

sequenceDiagram
  participant U as User (EOA)
  participant A as Contract A
  participant B as Contract B
  U->>A: tx: call A.f(x), value = v
  A->>B: external call B.g(y)
  B-->>A: return / revert
  A-->>U: return / revert

contract Counter {
  uint256 public count;
  function inc() external { count += 1; }
}

Overall Slide Concept This slide re-centers smart contracts as persistent programs with on-chain consequences. It matters here because many Ethereum applications are easier to understand as rule systems over shared state. Emphasize that smart contracts execute deterministically under protocol rules rather than human discretion.

Key Points - A smart contract is code stored on-chain and executed by the network. - Contracts can hold assets, enforce rules, and coordinate interactions. - They extend blockchain from record-keeping into programmable state transitions.

Walkthrough None

Sources None

Smart Contract Risks and Security

• Bugs become security problems when code directly controls assets or permissions
• Important risks include reentrancy, bad access control, unsafe upgrades, oracle dependence, and randomness misuse
• Reentrancy: an external call lets untrusted code call back before state is updated
• Reused code and copied patterns can spread both best practices and vulnerabilities at scale
• Code quality, governance, and operational controls still matter

Overall Slide Concept This slide reminds students that programmability increases attack surface. It matters here because Ethereum’s flexibility only matters if students also understand the cost of bugs and unsafe assumptions. Emphasize reentrancy, access control, and audit discipline as recurring themes.

Key Points - Contract bugs can move or lock assets irreversibly once deployed. - Security depends on code quality, testing, review, and conservative design patterns. - Smart-contract trust often means trusting implementation choices under immutable conditions.

Walkthrough None

Sources None

Oracles and Off-Chain Dependencies

• Smart contracts cannot directly observe the outside world
• Oracles bridge in prices, events, or other off-chain facts
• That makes them useful, but also reintroduces trust and manipulation risk
• If the oracle is wrong, delayed, or censored, what does the contract do?

Where and why did trust re-enter the system?

Overall Slide Concept This slide shows where Ethereum’s on-chain logic still depends on outside information. It matters here because students should not mistake on-chain execution for self-sufficiency. Emphasize that an oracle is a mechanism for bringing external data into contract logic.

Key Points - Smart contracts cannot natively observe the outside world with certainty. - Oracles bridge data in, but they create trust and manipulation questions. - External dependencies often become the weak point in otherwise elegant systems.

Walkthrough None

Sources None

Layer 2s, Rollups, and Blobs

• Layer 2 systems move execution or aggregation away from Layer 1 while still relying on Ethereum for settlement or data availability
• Optimistic rollups rely on fraud proofs and challenge periods
• ZK rollups rely on validity proofs that show the state transition was correct
• Blob data from EIP-4844 gives rollups cheaper temporary data space without expanding permanent state

Overall Slide Concept This slide revisits Ethereum scaling through layered execution rather than one chain doing everything. It matters here because modern Ethereum strategy depends on moving activity off the base layer while preserving settlement assurances. Emphasize that rollups batch activity and post compressed commitments back to Ethereum.

Key Points - Layer 2 systems execute many transactions outside the base layer. - Rollups rely on Ethereum for settlement, data availability, or dispute resolution depending on design. - Blob data lowers the cost of publishing large batches needed by scaling systems.

Walkthrough 1. Transactions are processed in a secondary execution environment. 2. The rollup posts compressed data or commitments back to Ethereum. 3. Ethereum supplies settlement guarantees while the higher layer supplies throughput.

Sources None

Ethereum Upgrades, EIPs, and Client Diversity

• EIPs are the formal mechanism for proposing and standardizing protocol changes
• Ethereum evolves through coordinated upgrades rather than staying frozen
• Client diversity matters because a monoculture bug can threaten liveness or safety across the network

Examples to keep in view

• The Merge
• Rollup-centered scaling
• Blob data and the broader danksharding roadmap

Overall Slide Concept This slide reviews how Ethereum changes over time without one owner flipping a switch. It matters here because protocol evolution is a governance problem as much as a coding problem. Emphasize that EIP means Ethereum Improvement Proposal.

Key Points - Upgrades are proposed, debated, implemented, and adopted through a social-technical process. - Client diversity reduces systemic risk from one software stack dominating the network. - Governance is distributed, but it still concentrates influence in people and institutions.

Walkthrough None

Sources None

Tokens and Standards

• Tokens are smart-contract-defined assets or rights
• Common standards:
  • ERC-20 defines fungible-token balances, transfers, and allowances
  • ERC-721 defines unique NFT ownership and transfer
  • ERC-1155 supports mixed fungible and non-fungible token IDs in one contract
  • ERC-165 lets contracts advertise which interfaces they implement

Native ETH is a protocol asset; most tokens and NFTs are smart-contract assets that follow shared standards.

Overall Slide Concept This slide revisits why token standards matter in Ethereum’s application layer. It matters here because standards make wallets, exchanges, and contracts interoperable. Emphasize that a standard is a shared interface convention rather than a guarantee of quality or legitimacy.

Key Points - Token standards define predictable behaviors for assets and contracts. - Interoperability lets many tools support the same asset types with less custom code. - Standards accelerate ecosystems while leaving policy and governance questions unresolved.

Walkthrough None

Sources None

NFTs and Tokenization

• Fungible tokens are interchangeable units; NFTs track distinct records or items
• Tokenization links blockchain records to claims about assets, access, identity, or provenance
• The token is the on-chain record, but its legal, social, or physical meaning depends on surrounding rules and institutions

Overall Slide Concept This slide widens the application-layer discussion beyond fungible assets. It matters here because students should see tokenization as a claim-design problem, not merely a culture trend. Emphasize that NFT means non-fungible token.

Key Points - NFTs represent distinguishable items or claims rather than interchangeable units. - Tokenization links on-chain records to off-chain assets, identities, or rights under varying assumptions. - The hard problem is often enforcement and provenance, not token issuance itself.

Walkthrough None

Sources None

Graph Thinking and Heuristics

• Blockchain forensics often begins with transaction graph structure
• Common heuristics and patterns:
  • Fan-in/fan-out
  • Common-input ownership (CIOH)
  • Peeling chains and change detection
  • Address clustering

Heuristics generate investigative leads and clustering hypotheses, but they are clues, not proof.

Overall Slide Concept This slide reintroduces the forensic mindset needed to analyze transparent ledgers. It matters here because forensics works by combining transaction structure with pattern recognition rather than waiting for one explicit identity label. Emphasize that a heuristic is an evidence-guided inference rule, not proof by itself.

Key Points - Analysts often model flows as graphs of addresses, clusters, and interactions. - Heuristics help prioritize likely relationships or behaviors for deeper review. - Good forensic work balances useful inference with humility about uncertainty.

Walkthrough None

Sources None

Obfuscation and Countermeasures

• Adversaries use mixers, CoinJoin, bridges, chain hopping, and privacy-preserving assets to make tracing harder
• Investigators respond with flow analysis, cross-chain tracing, timing correlation, and service-level intelligence

Overall Slide Concept This slide reviews the cat-and-mouse dynamic between privacy tactics and analytic response. It matters here because transparent ledgers do not automatically mean easy attribution. Emphasize that obfuscation raises investigative cost even when it does not guarantee privacy.

Key Points - Mixing, peeling chains, and cross-chain movement complicate traceability. - Analysts respond with timing, graph, clustering, and off-chain evidence techniques. - The contest is dynamic because both privacy tools and investigative methods evolve.

Walkthrough None

Sources None

Privacy Coins

• Privacy coins change the problem because the transaction graph is intentionally hidden or degraded
• Monero uses ring signatures, stealth addresses, and RingCT to hide sender, receiver, and amount
• Zcash uses optional shielded transactions backed by zk-SNARKs
• Investigators often pivot from on-chain tracing toward:
  • Entry and exit points
  • Timing and amount correlation
  • Device or server-side evidence

Overall Slide Concept This slide reminds students that not all blockchain systems prioritize transparency equally. It matters here because privacy-preserving designs change the forensic assumptions that work well on Bitcoin or Ethereum. Emphasize that privacy coins intentionally hide parts of transaction structure by default.

Key Points - Privacy coins are designed to reduce observable links among senders, receivers, or amounts. - Their stronger privacy properties limit the usefulness of standard public-ledger heuristics. - Analytic work shifts toward endpoints, exchanges, metadata, and operational context.

Walkthrough None

Sources None

Attribution

• On-chain transparency alone rarely gives a real-world name immediately
• Attribution often depends on off-chain links such as:
  • Exchange records
  • KYC/AML processes
  • Seized devices or cloud accounts
  • OSINT and behavioral traces
• The key lesson is that blockchain forensics combines technical tracing with institutional and investigative leverage

Overall Slide Concept This slide closes the forensic review by focusing on the hardest step: linking on-chain behavior to real-world entities. It matters here because tracing value flows is not the same as identifying the actor behind them. Emphasize that attribution often requires off-chain evidence and institutional cooperation.

Key Points - Clusters and transaction patterns suggest hypotheses about control. - Attribution usually depends on off-chain records, service-provider data, or investigative context. - The strongest conclusions come from combining multiple independent evidence sources.

Walkthrough None

Sources None

Course Purpose

• It is the combination of:
  • Cryptographic commitments
  • Distributed communication
  • Consensus under adversarial conditions
  • Incentive design
  • Application-layer logic
• If one layer is weak, the overall system can still fail

Overall Slide Concept This slide recenters the entire course at the very end of the technical review. It matters here because students should leave with a coherent reason for why the course combined systems, economics, cryptography, and governance. Emphasize that blockchain literacy means being able to evaluate claims, not just describe technology.

Key Points - The course aimed to build layered understanding rather than tool-specific familiarity. - Technical design, incentives, and institutions all shape blockchain outcomes. - Students should now be able to reason across the stack instead of memorizing isolated modules.

Walkthrough None

Sources None

Final Exam Review Prompts

• What does the Merkle root do, and why is it in the block header?
• Why are digital signatures central to blockchain ownership?
• Why does a permissionless blockchain need a different consensus model than a permissioned ledger?
• How does Bitcoin’s UTXO model differ from Ethereum’s account model?
• Why are blockchain forensics possible even when users begin with pseudonymous addresses?

Overall Slide Concept This slide turns the technical review into a preparation tool for assessment. It matters here because students now need prompts that force them to synthesize across the course without scripted answers. Emphasize the structure of a strong response: mechanism, tradeoff, and implication.

Key Points - The prompts are meant to trigger integrated explanations, not one-line definitions. - Strong answers should connect primitives, system design, and real-world consequences. - Encourage students to cite examples from Bitcoin, Ethereum, permissioned ledgers, and forensics as needed.

Walkthrough None

Sources None

References

[1]

D. Yaga, P. Mell, N. Roby, and K. Scarfone, “Blockchain technology overview,” National Institute of Standards and Technology, Gaithersburg, MD, NIST IR 8202, Oct. 2018. doi: 10.6028/NIST.IR.8202.

[2]

A. Narayanan, J. Bonneau, E. Felten, A. Miller, and S. Goldfeder, Bitcoin and Cryptocurrency Technologies. Princeton University Press, 2016.

[3]

J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll, and E. W. Felten, “SoK: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies,” in 2015 IEEE Symposium on Security and Privacy, 2015, pp. 104–121. doi: 10.1109/SP.2015.14.

[4]

A. M. Antonopoulos, Mastering Bitcoin: Programming the open blockchain, Second edition. Sebastopol, CA: O’Reilly, 2017.

[5]

A. M. Antonopoulos and G. Wood, “Mastering Ethereum.” 2018. Available: https://github.com/ethereumbook/ethereumbook

[6]

R. C. Merkle, “A Digital Signature Based on a Conventional Encryption Function,” in Advances in Cryptology — CRYPTO ’87, vol. 293, C. Pomerance, Ed., Berlin, Heidelberg: Springer Berlin Heidelberg, 1988, pp. 369–378. doi: 10.1007/3-540-48184-2_32.

[7]

S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System.” Satoshi Nakamoto Institute, Oct. 31, 2008. Accessed: Sep. 12, 2025. [Online]. Available: https://cdn.nakamotoinstitute.org/docs/bitcoin.pdf

[8]

Bitcoin.org Developers, “Wallets (Developer Guide).” 2024. Available: https://developer.bitcoin.org/devguide/wallets.html

[9]

U.S. Securities and Exchange Commission, “U.s. Securities and exchange commission.” Accessed: Mar. 18, 2026. [Online]. Available: https://www.sec.gov

[10]

D. Boneh and V. Shoup, “Quantum Cryptography — Implications.” 2020. Available: https://intensecrypto.org/public/lec_19_quantum.html

[11]

National Institute of Standards and Technology, “Post-quantum cryptography project.” Accessed: Mar. 23, 2026. [Online]. Available: https://csrc.nist.gov/projects/post-quantum-cryptography

[12]

C. Reitter, “Milk sad: Update #2 - trust wallet ranges, uncompressed pubkeys.” Accessed: Mar. 28, 2026. [Online]. Available: https://milksad.info/posts/research-update-2/

[13]

UK Government Chief Scientific Adviser, “Distributed Ledger Technology: Beyond Block Chain.” 2016. Available: https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/492972/gs-16-1-distributed-ledger-technology.pdf

[14]

A. Singh, T.-W. Ngan, P. Druschel, and D. S. Wallach, “Eclipse Attacks on Overlay Networks: Threats and Defenses,” in Proceedings IEEE INFOCOM 2006. 25TH IEEE International Conference on Computer Communications, Barcelona, Spain: IEEE, 2006, pp. 1–12. doi: 10.1109/INFOCOM.2006.231.

[15]

E. Heilman, A. Kendler, A. Zohar, and S. Goldberg, “Eclipse Attacks on Bitcoin’s Peer-to-Peer Network.” Accessed: Oct. 21, 2025. [Online]. Available: https://eprint.iacr.org/2015/263

[16]

E. Androulaki et al., “Hyperledger fabric: A distributed operating system for permissioned blockchains,” in Proceedings of the Thirteenth EuroSys Conference, Porto Portugal: ACM, Apr. 2018, pp. 1–15. doi: 10.1145/3190508.3190538.

[17]

Hyperledger, “A Blockchain Platform for the Enterprise — Hyperledger Fabric Docs main documentation.” Accessed: Oct. 27, 2025. [Online]. Available: https://hyperledger-fabric.readthedocs.io/en/release-2.5/

[18]

V. Buterin, “Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform.” Ethereum.org, 2014. Available: https://ethereum.org/content/whitepaper/whitepaper-pdf/Ethereum_Whitepaper_-_Buterin_2014.pdf

[19]

ethereum.org, “The merge.” Accessed: Mar. 23, 2026. [Online]. Available: https://ethereum.org/roadmap/merge/