Module 1: Blockchain Fundamentals¶
This module builds your understanding of blockchain technology from first principles. We'll explore the problems blockchains solve, how they work, and why Solana's approach is unique.
Learning Objectives¶
By the end of this module, you will understand:
- What problems blockchains solve
- How distributed consensus works
- The structure of transactions and blocks
- Public key cryptography basics
- Different consensus mechanisms
- Why Solana is designed the way it is
1. The Problem: Trust in Digital Systems¶
The Double-Spend Problem¶
Consider digital money without a blockchain:
Alice has $100 in her digital wallet
Alice sends $100 to Bob
Alice sends $100 to Carol (at the same time!)
Without a central authority, who gets the money? This is the double-spend problem - digital information can be copied infinitely.
Traditional Solution: Centralized Trust¶
Banks solve this by being the single source of truth:
graph LR
A[Alice] --> B[Bank]
B --> C[Bob]
B --> D[Carol]
B --> E[Audit Log]Problems with centralization:
| Issue | Description |
|---|---|
| Single point of failure | If the bank goes down, no transactions |
| Censorship | Bank can freeze accounts |
| Trust requirement | Must trust the bank won't cheat |
| Limited hours | May not operate 24/7 |
| Geographic limits | Cross-border is expensive/slow |
Blockchain Solution: Distributed Trust¶
Blockchains distribute trust across many participants:
graph TB
subgraph Network
N1[Node 1]
N2[Node 2]
N3[Node 3]
N4[Node 4]
end
A[Alice] --> N1
N1 <--> N2
N2 <--> N3
N3 <--> N4
N4 <--> N1Every node maintains a copy of the transaction history. Consensus rules ensure all copies stay synchronized.
2. Cryptographic Foundations¶
Hash Functions¶
A hash function converts any input into a fixed-size output:
import hashlib
def sha256(data: str) -> str:
return hashlib.sha256(data.encode()).hexdigest()
# Same input = same output (deterministic)
print(sha256("hello")) # 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
print(sha256("hello")) # 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
# Tiny change = completely different output (avalanche effect)
print(sha256("Hello")) # 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969
Properties of cryptographic hashes:
| Property | Meaning |
|---|---|
| Deterministic | Same input always produces same output |
| Fast | Computing hash is quick |
| One-way | Cannot reverse hash to find input |
| Collision-resistant | Extremely hard to find two inputs with same hash |
| Avalanche effect | Small input change = completely different output |
Public Key Cryptography¶
Blockchains use asymmetric cryptography (public/private key pairs):
Private Key (Secret) Public Key (Shareable) Address
━━━━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━
Random 256-bit number Derived from private Hash of public key
Keep secret! Share with everyone Your "account number"
Signs transactions Verifies signatures
Solana uses Ed25519 - an elliptic curve signature scheme:
from solders.keypair import Keypair
from solders.pubkey import Pubkey
# Generate a new keypair
keypair = Keypair()
# Private key (keep secret!)
private_key = bytes(keypair)
# Public key (your address)
public_key: Pubkey = keypair.pubkey()
print(f"Public Key: {public_key}") # e.g., 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU
Digital Signatures¶
Signatures prove you control a private key without revealing it:
Transaction: "Send 10 SOL from Alice to Bob"
│
▼
┌─────────────────┐
│ Sign with │
│ Alice's private │──────► Signature (unique to this message + key)
│ key │
└─────────────────┘
│
▼
Anyone can verify using Alice's public key
3. Blockchain Structure¶
Blocks¶
A block contains:
┌────────────────────────────────────────────┐
│ Block Header │
├────────────────────────────────────────────┤
│ Previous Block Hash: 0x7a8f... │
│ Timestamp: 2024-01-15 10:30:00 │
│ Merkle Root: 0x3b2c... │
│ Nonce/Slot: 12345 │
└────────────────────────────────────────────┘
│ Transactions │
├────────────────────────────────────────────┤
│ TX1: Alice → Bob, 10 SOL │
│ TX2: Carol → Dave, 5 SOL │
│ TX3: Eve → Frank, 2 SOL │
│ ... │
└────────────────────────────────────────────┘
The Chain¶
Blocks are linked by hashes, forming an immutable chain:
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Block 1 │◄────│ Block 2 │◄────│ Block 3 │
│ Hash: A │ │ Hash: B │ │ Hash: C │
│ Prev: 0 │ │ Prev: A │ │ Prev: B │
└─────────┘ └─────────┘ └─────────┘
Immutability: Changing Block 1 changes its hash (A), which invalidates Block 2's "Previous Hash" field, which changes Block 2's hash (B), and so on. Attackers must redo work for every subsequent block.
Merkle Trees¶
Transactions are organized in a Merkle tree for efficient verification:
To verify TX3 is in the block, you only need: Hash C, Hash AB, and Root Hash. This is O(log n) instead of O(n).
4. Consensus Mechanisms¶
The Problem: Which Block is Valid?¶
Multiple nodes might propose different blocks simultaneously. Consensus mechanisms determine which block becomes canonical.
Proof of Work (PoW)¶
Used by Bitcoin. Miners compete to solve a computational puzzle:
def mine_block(transactions, previous_hash, difficulty):
nonce = 0
while True:
block_data = f"{transactions}{previous_hash}{nonce}"
block_hash = sha256(block_data)
# Hash must start with 'difficulty' zeros
if block_hash.startswith("0" * difficulty):
return nonce, block_hash
nonce += 1
| Pros | Cons |
|---|---|
| Battle-tested security | Extremely energy intensive |
| Decentralized | Slow (Bitcoin: ~7 TPS) |
| Simple to understand | Mining hardware centralization |
Proof of Stake (PoS)¶
Used by Ethereum. Validators stake tokens as collateral:
Validator stakes 32 ETH
│
▼
Randomly selected to propose block
│
▼
Other validators attest to validity
│
▼
If honest: earn rewards
If dishonest: lose stake (slashing)
| Pros | Cons |
|---|---|
| Energy efficient | "Rich get richer" concerns |
| Faster than PoW | Complex to implement correctly |
| Economic security | Nothing-at-stake problem |
Proof of History (PoH) - Solana's Innovation¶
Solana adds a cryptographic clock to prove time passage:
Each hash proves it came after the previous one. This creates a verifiable ordering of events without communication.
// Simplified PoH concept
fn proof_of_history(mut hash: [u8; 32], iterations: u64) -> [u8; 32] {
for _ in 0..iterations {
hash = sha256(&hash);
}
hash
}
Key insight: PoH is not consensus - it's a clock. Solana combines PoH with Tower BFT (a PoS variant) for consensus.
5. Transactions¶
Transaction Anatomy¶
A blockchain transaction typically contains:
┌─────────────────────────────────────────────┐
│ Transaction │
├─────────────────────────────────────────────┤
│ Signatures: [sig1, sig2, ...] │ ◄─ Who authorized this
│ Message: │
│ ├─ Header │
│ │ ├─ num_required_signatures │
│ │ └─ num_readonly_accounts │
│ ├─ Account Keys: [pubkey1, pubkey2, ...] │ ◄─ Accounts involved
│ ├─ Recent Blockhash │ ◄─ Prevents replay
│ └─ Instructions: [ │
│ { │
│ program_id: "Token Program", │ ◄─ Which program
│ accounts: [0, 1, 2], │ ◄─ Which accounts
│ data: [amount, ...] │ ◄─ What to do
│ } │
│ ] │
└─────────────────────────────────────────────┘
Transaction Lifecycle¶
sequenceDiagram
participant User
participant Wallet
participant RPC
participant Validators
User->>Wallet: Create transaction
Wallet->>Wallet: Sign with private key
Wallet->>RPC: Submit transaction
RPC->>Validators: Broadcast
Validators->>Validators: Validate & include in block
Validators->>RPC: Confirm
RPC->>Wallet: Transaction confirmedFinality¶
Finality = when a transaction cannot be reversed.
| Blockchain | Finality Type | Time |
|---|---|---|
| Bitcoin | Probabilistic | ~60 min (6 blocks) |
| Ethereum | Probabilistic/Economic | ~15 min |
| Solana | Optimistic | ~400ms |
| Solana | Finalized | ~12 sec |
6. Why Solana?¶
Performance Comparison¶
| Metric | Bitcoin | Ethereum | Solana |
|---|---|---|---|
| TPS (theoretical) | ~7 | ~30 | ~65,000 |
| Block Time | 10 min | 12 sec | 400 ms |
| Transaction Cost | $1-50 | $1-100 | $0.00025 |
| Finality | ~60 min | ~15 min | ~12 sec |
Solana's Key Innovations¶
- Proof of History (PoH): Cryptographic clock for ordering
- Tower BFT: PoH-optimized consensus
- Turbine: Block propagation protocol
- Gulf Stream: Mempool-less transaction forwarding
- Sealevel: Parallel smart contract runtime
- Pipelining: Transaction processing pipeline
- Cloudbreak: Horizontally-scaled accounts database
- Archivers: Distributed ledger storage
Trade-offs¶
| Advantage | Trade-off |
|---|---|
| High throughput | Higher hardware requirements |
| Low fees | Centralization concerns |
| Fast finality | Occasional network congestion |
| Rich ecosystem | Younger than Ethereum |
7. Wallets and Key Management¶
Wallet Types¶
| Type | Security | Convenience | Best For |
|---|---|---|---|
| Hardware (Ledger) | Highest | Low | Large holdings |
| Browser Extension (Phantom) | Medium | High | Daily use |
| Mobile (Solflare) | Medium | High | On-the-go |
| Paper | High (if stored well) | Very Low | Cold storage |
| CLI (solana-keygen) | Medium | Low | Development |
Creating Your First Wallet¶
- Install Phantom browser extension
- Click "Create New Wallet"
- Write down your seed phrase (12-24 words)
- Store seed phrase securely offline
- Set a strong password
Interactive: Create Your First Wallet¶
Exercise: Set Up a Development Wallet
-
Open terminal and run:
-
View your public key:
-
Set to devnet and get test SOL:
You should see: 2 SOL
8. Summary¶
| Concept | Key Takeaway |
|---|---|
| Double-spend | Blockchains solve this via distributed consensus |
| Hash functions | One-way functions that link blocks |
| Public/private keys | Prove ownership without revealing secrets |
| Blocks | Containers of transactions, linked by hashes |
| Consensus | Agreement on valid chain state |
| PoH | Solana's cryptographic clock |
| Transactions | Signed messages that change state |
| Finality | When transactions become irreversible |
Self-Assessment¶
What problem does blockchain solve?
The double-spend problem - preventing digital assets from being spent twice without a central authority.
Why can't you reverse a hash to find the input?
Hash functions are mathematically designed to be one-way. Finding an input that produces a specific hash requires brute-force search of an astronomically large space (2^256 possibilities for SHA-256).
How does Proof of History differ from Proof of Stake?
PoH is not a consensus mechanism - it's a clock. It creates a verifiable ordering of events. PoS is actual consensus (who decides which blocks are valid). Solana uses PoH for ordering and Tower BFT (a PoS variant) for consensus.
Why is Solana faster than Ethereum?
Multiple reasons: parallel transaction execution (Sealevel), cryptographic clock (PoH) reduces communication overhead, optimistic confirmation, pipelining, and higher hardware requirements for validators.
Next Steps¶
Now that you understand blockchain fundamentals, let's dive deep into Solana's specific architecture: