Book summary “Blockchain Basics”: summary

Introduction

You want to understand blockchain technology, but technical descriptions often overwhelm you with advanced cryptography, complex economic theory, and dense computer science jargon. You face the challenge of grasping how decentralized systems work without needing a degree in software engineering.

Daniel Drescher provides a plain-English framework that builds your knowledge step-by-step from fundamental terminology to decentralized finance. The central idea is that blockchain achieves and maintains integrity in a purely distributed peer-to-peer system through cryptography, decentralized data structures, and algorithmic consensus.

The book guides you through seven logical areas to replace human intermediaries with automated protocol trust. You will find answers to several core questions:

• How do cryptographic hash functions and digital signatures secure digital transactions?
• What mechanisms prevent tampering within a decentralized ledger?
• How do independent network nodes reach consensus without a central authority?
• What role do native cryptocurrencies play in maintaining system security?
• How do programmable smart contracts enable decentralized finance applications?

1. Technical Foundations and Hashing Data

Hashing Data

Cryptographic hash functions transform any input data into a fixed-length hexadecimal number that acts as a unique digital fingerprint.

Hash functions are small computer programs featuring properties such as quick execution, deterministic outputs, pseudo-randomness, non-invertible one-way functionality, and collision resistance. You rely on these functions to process digital information securely.

Applying the SHA256 hash function to the greeting "Hello World!" yields the hexadecimal number 7F83B1657FF1FC53B92DC18148A1D65DFC2D4B1FA3D677284ADDD200126D9069.

When dealing with multiple independent pieces of data, specialized hashing patterns like Merkle trees allow the creation of a single hierarchical hash value. Ralph Merkle proposed the hierarchical hash tree in 1980.

Different hashing patterns serve distinct structural needs:

• independent hashing;
• repeated hashing;
• combined hashing;
• sequential hashing;
• hierarchical hashing.

Hashing in the Real World

Cryptographic hash values are used in real-world scenarios to compare large files efficiently, detect data alterations, create change-sensitive references, and enforce computational work. Hash references function like digital cloakroom tickets that break if the referenced data changes.

Combining the text "Hello World!" with the nonce 614 yields a shortened hash value starting with three leading zeros (00068A3C).

Hash outputs vary by algorithm:

• SHA1 produces 40-character hexadecimal strings;
• SHA256 produces 64-character hexadecimal strings;
• SHA512 produces 128-character hexadecimal strings.

Hash puzzles require computational trial and error using a nonce to find a hash value meeting difficulty restrictions.

2. Identifying Accounts and Authorizing Transactions

Asymmetric cryptography and digital signatures identify user accounts and securely authorize property transfers without central intermediaries.

Identifying User Accounts

Asymmetric cryptography utilizes a pair of complementary public and private keys where data encrypted with one key can only be decrypted by the other. This method separates the capability to encrypt data from the capability to decrypt it. The public key is shared openly to identify accounts or encrypt messages, while the private key is kept secret to decrypt messages or prove authorship. Elliptic curve cryptography and RSA are prominent encryption methods, where RSA keys can theoretically be swapped, though doing so introduces security risks.

You can apply these principles directly:

• Use cryptographic software to create a private key and its corresponding public key.
• Keep the private key for yourself.
• Give your public key to everyone else.

Blockchain applies asymmetric cryptography to identify user accounts through public keys and authorize property transfers through private keys. User account numbers in a blockchain are public cryptographic keys operating like mail addresses. They allow anyone to send property to an account, while access remains restricted to the holder of the private key. Satoshi Nakamoto's 2008 Bitcoin paper established foundational concepts utilizing public-private-key cryptography in peer-to-peer systems.

Authorizing Transactions

Digital signatures act as the cryptographic equivalent of handwritten signatures to authorize blockchain transactions. A digital signature is created by hashing transaction data and encrypting that hash value with the private key of the account handing off ownership. Anyone can verify the signature by decrypting it with the sender's public key.

If a hacker alters a signed greeting from an exclamation mark to a question mark, verifying the digital signature against the newly calculated hash reveals a mismatch, exposing the fraud.

You construct and sign messages by following specific steps:

• Describe the transaction with all necessary information, such as involved account numbers and amount being transferred, except the signature itself.
• Create the cryptographic hash value of the transaction data.
• Encrypt the hash value of the transaction with the private key of the account that hands off ownership.
• Add the ciphertext created in point 3 to the transaction as its digital signature.

3. Storing and Protecting Transaction Data

The blockchain data structure uses linked block headers and Merkle Patricia Tries to enforce an all-or-nothing approach to data changes.

Storing Transaction Data

The blockchain data structure separates transaction content from chronological ordering by mimicking a library card catalog linked via cryptographic hash values. You can transform a traditional book through five steps to understand this architecture. These steps include making page dependency explicit, outsourcing content, replacing page numbers with reference numbers, using cryptographic hash functions, and removing the book spine. In blockchain, the ordering catalog equates to a chain of block headers, while content pages correspond to Merkle Patricia Tries containing transaction data.

Protecting the Data Store

The blockchain data structure adopts a radical all-or-nothing approach to data changes, where any modification breaks cryptographic hash references and invalidates the entire chain. Because every block header references the hash of its predecessor and contains the root of a Merkle Patricia Trie, altering any transaction detail breaks its specific hash reference. This invalidates the trie root, which alters the block header's hash, consequently breaking the hash reference in the next block header and cascading all the way to the head of the chain.

Blockchain achieves immutability by imposing prohibitive computational costs on writing or rewriting data through unique hash puzzles required for every block header. While change-sensitivity ensures that any manipulation stands out, the requirement to solve a hash puzzle for every block header means that embedding a change requires resolving puzzles for all subsequent blocks. This makes tampering computationally expensive and economically irrational. Every block header in the blockchain data structure must include specific mandatory fields to enforce validation and prevent manipulation. Block headers contain cryptographic references and parameters that tie the block to its history and prove that the computational costs of the hash puzzle were paid.

Adding new transaction data to an existing blockchain data structure follows a strict three-step sequence involving a new Merkle Patricia Trie and a new block header:

• Create a new Merkle Patricia Trie that contains all new transaction data to be added.
• Create a new block header that contains both the hash reference to the header of the current block and the root of the Merkle Patricia Trie that contains the new transaction data.
• Create a new hash reference pointing to the new block header and declare it as the hash reference to the new head of the updated blockchain data structure.

4. Distributing the Data Store and Reaching Consensus

Peer-to-peer gossip networks combine validation rules, rewards, and the longest chain criterion to establish distributed consensus.

Distributing Among Peers

A purely distributed peer-to-peer system uses a gossip-style communication mechanism over the Internet to share transaction data and maintain synchronization without a central authority. Because nodes can disconnect and reconnect at any time and message delivery over the Internet is unreliable, nodes forward information to their peers in a gossip style. Cryptographic hash values filter out duplicate messages, and timestamps allow nodes to order received data.

Verifying and Adding Transactions

A company offering multiple-choice test marking turned employees into contractors governed by three rules regarding availability, $1 rewards for fast correct markings, and punishment/reward reassignments for catching mistakes. Contractors received performance-related pay: $1 for the first correct marking, and the obligation to refund mistakes to whoever caught them. This drove speed and control, but eventually, contractors formed a pact to stop checking and mark randomly to maximize speed.

The blockchain algorithm relies on five core building blocks to keep the system open while ensuring that only valid transactions are added. These blocks include validation rules for transactions and block headers, rewards for submitting valid blocks, punishment for undermining integrity, competition for rewards based on speed and quality, and peer control where all nodes supervise each other. The blockchain algorithm establishes a continuous two-step working rhythm driven entirely by the arrival of messages containing new blocks. Nodes alternate between evaluating a new block created by peers and trying hard to be the next node to create a block. Losers of the speed competition become strict referees in the subsequent quality competition.

Choosing a Transaction History

Paved park paths versus beaten tracks created directly by visitors choosing efficient shortcuts across lawns. Just as visitors leave footprints creating shortcuts across grass, blockchain nodes leave footprints in the shared data structure, collectively voting with their feet to establish agreement. When conflicting transaction histories emerge, nodes apply either the longest chain criterion or the heaviest chain criterion to select the authoritative history.

The longest chain criterion selects the path with the most blocks, representing the greatest computational effort. When difficulty levels vary, nodes use the heaviest chain criterion, which aggregates the difficulty levels of all blocks in a path. Blocks that are not part of the selected authoritative path become orphan blocks, and their transactions are put back into the inbox for reprocessing. Orphan blocks are treated as if they never happened, and rewards given for creating them are reclaimed. Transactions contained within them are not lost but are reprocessed and can become part of the authoritative chain later.

As more blocks are added to the blockchain, older blocks become increasingly anchored in the common history and immune to random changes. Uncertainty regarding block inclusion decreases over time. The deeper down the authoritative chain a block is located, the more common effort has been spent on it and the less likely it is to be abandoned, a property known as eventual consistency. A 51% attack attempts to control the majority of voting power in order to turn authoritative blocks into orphan blocks and rewrite the transaction history. By gathering a majority of computational power, an attacker can theoretically catch up and overtake the honest majority chain. However, because the hash puzzle binds voting power to costly computational resources, such an attack is heavily deterred. Randomness in solving the hash puzzle prevents predictability, protecting the consensus process from targeted manipulation and attacks. Deterministic alternatives like waiting lists create logical contradictions in distributed systems and allow attackers to plan assaults in advance. Random selection of block creators ensures that returns for dishonest peers are unpredictable and difficult to calculate.

5. Paying for Integrity and Analyzing Limitations

Maintaining system integrity requires native cryptocurrencies to compensate peers, while inherent design goals create trade-offs between transparency and privacy.

Paying for Integrity

Maintaining the integrity of a blockchain requires computational resources. This process costs money and makes it necessary to compensate participating nodes. Rewards and punishment keep peers verifying transactions orderly. Compensation directly impacts system integrity because untrustworthy or worthless payment contaminates the entire network.

To avoid interfering with blockchain values, an instrument of payment must possess specific properties resembling a wish list for a world currency. Existing fiat currencies fail to meet these criteria, making it necessary for the blockchain system to invent its own internal cryptographic money.

• Be available in digital form
• Be accepted as an instrument of payment in the real world
• Be accepted as an instrument of payment in all countries
• Not be subject to capital movement restrictions
• Have a stable value
• Be trustworthy
• Not to be controlled by a single central organization or state

New units of cryptocurrency are introduced into the system through specialized money creation transactions rather than standard transfers. These transactions have no sender account, are determined by the system itself, carry no signature, and provide block rewards to the user who successfully creates a new block.

• A constant amount
• Proportional to the difficulty of the block
• Proportional to the position of the block in the blockchain data structure
• Inversely proportional to the position of the block in the blockchain data structure

Seeing the Limitations

Blockchain exhibits major technical limitations stemming from its extreme transparency, strict security models, and the computationally expensive proof of work required for immutability. These measures lead to a lack of privacy, limited scalability, high costs, hidden centralization through specialist mining hardware, lack of flexibility, and critical size vulnerabilities like 51% attacks.

Commercial adoption of blockchain is hindered by non-technical challenges primarily related to legal status and user education. Uncertainty surrounding regulatory compliance creates friction, and a lack of user understanding prevents widespread trust and utilization, much like early e-commerce in the 1990s.

The fundamental technical limitations of blockchain originate from inherent conflicts between transparency and privacy during data reading, and security and speed during data writing. Reading the entire history of transaction data ensures auditability and prevents double-spending but destroys user privacy. Writing transaction data through time-consuming proof of work secures history but limits transaction speed.

By independently varying reading and writing access rights, four distinct versions of blockchain emerge from public and private, permissionless and permissioned combinations. Public permissionless blockchains grant universal access, whereas private permissioned versions restrict access to preselected participants, trading away pure distribution for commercial speed and privacy.

6. Applications and Alternative Consensus Mechanisms

Generic application patterns and alternative consensus models like Proof of Stake expand blockchain utility beyond basic transaction recordkeeping.

You can use blockchain across various domains through generic application patterns derived from its core properties as a decentralized data store. These patterns include:

• proof of existence for unique items like patents;
• proof of non-existence for fines or convictions;
• proof of time for event tracking;
• proof of order for resource allocation;
• proof of identity for digital documents;
• proof of authorship for electronic publishing;
• proof of ownership for managing assets.

Evaluating whether a blockchain application creates tangible value requires examining specific architectural, operational, and commercial criteria. You must answer these questions:

• Are the requirements for using blockchain fulfilled?
• What kind of blockchain is used?
• What is the added value of using a purely distributed peer-to-peer system?
• What is the application idea?
• What is the business case?
• How are peers compensated for contributing resources to the system?

Alternative Consensus Mechanisms

Proof of Stake replaces energy-intensive hash puzzles with a lottery system where participation cost is determined by staking ownership of the native cryptocurrency.

The PoS process involves five steps: staking cryptocurrency as collateral, validator selection via a lottery draw, block creation by the winner, block validation by peers, and block finalization through a majority vote. Honest validators receive transaction fees and a refund of their lottery ticket price after a lock-up period. Dishonest behavior triggers monetary penalties like withholding rewards or confiscating collateral, alongside non-monetary punishment such as exclusion from the consensus process.

The author compares the monopolization risk in PoS to the board game Monopoly, specifically recalling the thrilling penultimate rounds where everyone except one player goes bankrupt.

Different blockchain consensus mechanisms rely on distinct scarce resources to impose participation costs and secure the network. Alternative mechanisms include Proof of Work using processor power, Proof of Stake using cryptocurrency ownership, Proof of Burn by destroying coins, Proof of Activity combining PoW and PoS, Proof of Capacity using disk space, Proof of Elapsed Time using waiting time, Proof of Authority using reputation, and Proof of Importance using network engagement.

7. Programmable Blockchain and Decentralized Finance

Embedding executable code within transactions turns blockchain into a global computer that powers decentralized finance applications.

Making Blockchain Programmable

You can transform blockchain into a global computer by embedding instructions, data, or computer programs inside transaction text fields. Nodes across the distributed network evaluate and execute these instructions, creating smart contracts without altering the underlying blockchain architecture.

Using an international money transfer text field to send instructions for watering a lawn or cleaning a house.

Turing-complete programming languages give developers complete control over processors, but they introduce the risk of infinite loops that can freeze the entire blockchain. Because every node in the network executes the smart contract code, an infinite loop would consume computational resources forever. You need digital fuel, similar to a car with an empty tank, which depletes with each instruction and stops the program when exhausted.

Connecting with the Outside World

Blockchain oracles serve as third-party bridges that provide smart contracts with external information from the real world. Oracles can be classified by data source, direction of information, and architecture.

• Software oracles
• Hardware oracles
• Human oracles
• Computation oracles
• Inbound oracles
• Outbound oracles
• Centralized oracles
• Consensus oracles

Blockchain oracles reintroduce epistemological and operational problems into the blockchain by importing messy real-world empirical data. The historical Oracle of Delphi in ancient Greece illustrates the challenge of obtaining worldly decisions through an opaque process. Emperor Theodosius I closed down the Oracle of Delphi in 391 AD.

Tokenizing Valuable Things

Tokens are compact objects with a defined context of use and an assigned value that is greater than their raw material value. Cutting a banknote in two equal pieces in an attempt to create change results in both pieces losing their cash value entirely. You can classify digital tokens across multiple objective criteria:

• Fungible
• Non-fungible tokens
• Utility tokens
• Financial securities tokens
• Payment tokens
• Governance tokens

Decentralizing Finance

Decentralized Finance provides financial products and services on public permissionless blockchains without intermediaries.

DeFi comprises a hierarchical structure of products ranging from basic cryptocurrencies and lending to advanced stablecoins, staking pools, and flash loans. A flash loan transaction can borrow 100 Dream Coins, buy an artwork on one market, sell it on another, and repay the loan plus interest all within one single transaction. You can execute this specific operation:

• Take out a loan of 100 Dream Coins at 10% interest
• Buy the digital artwork Tulips at Sunset for 100 Dream Coins on the Cheap Art Market
• Sell the digital artwork Tulips at Sunset on the Expensive Art Market for 200 Dream Coins
• Pay back 100 Dream Coins of the loan
• Pay 10 Dream Coins as interest
• Pay 90 Dream Coins to your own account

10 Key Ideas

1. Cryptographic hash functions transform any input data into a fixed-length hexadecimal number that acts as a unique digital fingerprint.
2. Asymmetric cryptography and digital signatures identify user accounts and securely authorize property transfers without central intermediaries.
3. The blockchain data structure uses linked block headers and Merkle Patricia Tries to enforce an all-or-nothing approach to data changes.
4. Peer-to-peer gossip networks combine validation rules, rewards, and the longest chain criterion to establish distributed consensus.
5. Maintaining system integrity requires native cryptocurrencies to compensate peers, while inherent design goals create trade-offs between transparency and privacy.
6. When conflicting transaction histories emerge, nodes apply either the longest chain criterion or the heaviest chain criterion to select the authoritative history.
7. New units of cryptocurrency are introduced into the system through specialized money creation transactions rather than standard transfers.
8. Blockchain exhibits major technical limitations stemming from its extreme transparency, strict security models, and the computationally expensive proof of work required for immutability.
9. Proof of Stake replaces energy-intensive hash puzzles with a lottery system where participation cost is determined by staking ownership of the native cryptocurrency.
10. Decentralized Finance provides financial products and services on public permissionless blockchains without intermediaries.