Blockchain Evolution

Now that you understand how consensus mechanisms and cryptographic primitives work, let's explore how these concepts evolved from Bitcoin's simple value transfer to today's programmable blockchain platforms.

Each major blockchain represents different engineering decisions and tradeoffs, shaped by the fundamental constraints we've learned about.

Bitcoin

Bitcoin wasn't designed to be a general-purpose computer; it was built to solve one specific problem: creating digital money that works without banks or governments. Every design decision in Bitcoin reflects this singular focus.

Consensus

Bitcoin uses the original Proof of Work implementation that Satoshi designed. Miners compete to find a nonce (random number) that, when hashed with the block data, produces a hash starting with a specific number of zeros.

The network automatically adjusts the difficulty every 2,016 blocks (approximately two weeks) to maintain an average block time of 10 minutes.

This timing isn't arbitrary. Faster blocks would cause network splits where miners work on different blockchain versions. Slower blocks would make transactions painfully slow.

The UTXO Model

Bitcoin doesn't track account balances like banks do. Instead, it tracks individual "coins" using UTXOs (Unspent Transaction Outputs), which function similarly to physical cash.

Imagine you have three $20 bills in your wallet and want to buy something that costs $35. You can't split a $20 bill, so you give the cashier two bills ($40) and receive $5 in change. Bitcoin works exactly the same:

Let's say Alice has received bitcoin in three separate transactions:

• UTXO #1: 0.5 BTC (from Bob)
• UTXO #2: 0.3 BTC (from Carol)
• UTXO #3: 0.8 BTC (from Dave)

Alice's "balance" is 1.6 BTC, but there's no single account storing this number. Instead, the blockchain records three separate UTXOs that Alice can spend.

When Alice wants to send 1.0 BTC to Eve, she must:

• Select UTXOs that total at least 1.0 BTC (she chooses UTXO #1 and #3, totaling 1.3 BTC)
• Create a transaction where she sends 1.0 BTC to Eve and 0.3 BTC back to herself as change
• Sign the transaction with her private key to prove she owns the input UTXOs

The transaction consumes UTXOs #1 and #3 (they're now "spent") and creates two new UTXOs: one for Eve and one change UTXO for Alice.

This model enables powerful features:

• Parallelizable Processing: Since each UTXO can only be spent once, transactions using different UTXOs don't conflict. Miners can validate thousands of transactions simultaneously without worrying about double-spending, as long as each transaction references different UTXOs.
• Privacy: There's no global account that reveals your total balance. Your bitcoins are spread across multiple UTXOs, making it harder for observers to determine your total wealth. Each UTXO might be linked to a different address, further obscuring ownership patterns.
• Simple Verification: Each transaction can be verified independently by checking that the input UTXOs exist and haven't been spent, and that the digital signatures are valid. You don't need to maintain complex account state or worry about the order of transactions affecting balances.
• Atomic Operations: Either a transaction succeeds completely (consuming all inputs and creating all outputs) or fails completely. There's no risk of partial state where some money is deducted but not transferred.

Ethereum

While Bitcoin solved digital payments, Vitalik Buterin recognized a bigger opportunity: what if the blockchain could run any program, not just transfer money? This vision led to Ethereum: the first general-purpose blockchain computer.

Bitcoin's UTXO model works perfectly for payments but becomes clunky for complex applications that need persistent state, complex logic, and composability between different programs.

Consensus

Ethereum originally used Proof of Work but switched to Proof of Stake in 2022 during "The Merge." This transition maintained security while gaining crucial benefits:

• Mathematical Finality: After about 13 minutes, transactions become mathematically irreversible
• Energy Efficiency: No more massive electricity consumption
• Future Upgrades: Proof of Stake enables sharding: splitting the network into parallel chains for higher throughput

The Account Model

Ethereum replaced Bitcoin's UTXO system with familiar account-based balances, enabling:

• Smart Contracts: Programs that live on the blockchain and maintain their own state
• External Accounts: User-controlled accounts like Bitcoin addresses
• Inter-Contract Calls: Smart contracts can interact with each other seamlessly

In Ethereum, there are two types of accounts:

• Externally Owned Accounts (EOAs): Controlled by users with private keys, similar to Bitcoin addresses. They have a balance and can send transactions.
• Contract Accounts: Controlled by code, not private keys. They have a balance AND store executable code plus persistent data.

For this reason, on Ethereum, smart contracts are autonomous programs that live on the blockchain, maintain their own state, and can be called by other accounts.

This account model enables persistent state—data that survives across transactions. A smart contract can remember information from previous interactions, maintain complex data structures, and evolve over time.

This makes applications like lending protocols, governance systems, and complex financial instruments possible.

All of this is possible thanks to the Ethereum Virtual Machine (EVM), which runs on every node and makes the blockchain programmable. It defines what programs can run, how they execute, and what resources they consume.

Solana

Ethereum demonstrated that blockchains could support general-purpose computation, but this success revealed scalability constraints. As decentralized applications gained adoption, network congestion led to high transaction fees and slower confirmation times.

These limitations stemmed from fundamental architectural decisions in Ethereum's design, which Solana attempts to address through architectural innovations by redesigning core blockchain components from first principles.

Consensus

Solana uses Proof of Stake but adds a crucial innovation: Proof of History. Instead of waiting for consensus on when events happened, Solana creates a cryptographic clock that timestamps all transactions before consensus, allowing validators to process transactions in parallel since they already know the correct order.

This temporal ordering enables much faster consensus: Solana produces blocks every 400 milliseconds compared to Ethereum's 12 seconds.

Solana Virtual Machine

The EVM processes transactions sequentially because smart contracts share global state: when one contract modifies shared data, all other transactions must wait. This creates bottlenecks as network usage grows.

Solana fundamentally rethinks this architecture:

• Stateless Programs: Unlike Ethereum where smart contracts store data internally, Solana programs are stateless. All data lives in separate accounts that programs read from and write to. This separation enables parallel processing since programs don't compete for shared state.
• Transaction Parallelization: Solana transactions must declare upfront which accounts they'll read and modify. The runtime can then execute non-conflicting transactions simultaneously across multiple CPU cores. If Transaction A modifies Account X and Transaction B modifies Account Y, they can run in parallel.
• Optimized Execution: The SVM uses a register-based architecture instead of the EVM's stack-based approach, reducing the overhead of moving data around during computation. Programs compile to native machine code rather than bytecode, eliminating interpretation overhead.
• Predictable Costs: Instead of Ethereum's fixed gas prices determined years ago, Solana uses dynamic fee markets where transaction costs reflect actual network demand and computational resources consumed.

The result is that Solana can process over 5,000 transactions per second (TPS) compared to Ethereum's 15 TPS, while maintaining sub-second finality and decentralization. This performance comes from architectural decisions that prioritize parallel execution over the sequential processing model inherited from single-threaded computing.