These are my notes from JumpCrypto's reading list. why crypto? Jump frames crypto as infrastructure that is a trust-minimized ledger for value transfer, a shared state machine for computation, open platform of composable APIs, and a token-based incentive layer that scales the network.

Utilization of Tokens

The following excerpt is from "Crypto Tokens: A Breakthrough in Open Network Design" by Chris Dixon (2017). Chris Dixon argues that crypto tokens are a major breakthrough because they give the internet a practical way to build open networks that can compete with proprietary platforms. He contrasts the early web, which enabled small teams to build products through open protocols, with today’s iOS app stores and big tech ecosystems that impose fees and restrictions, limiting independent developers’ ability to scale. Tokenization changed the game by "unbundling" Bitcoin's deeper innovation. Beyond being a store of value, Bitcoin pioneered a method of coordinating and securing a decentralized network and tokens generalize that idea as a reusable pattern for different kind of networks. This idea of a reusable pattern spawned in many different derivatives. Dixon explains how a token can fund and operate an open service while keeping control decentralized. He emphasizes incentives where token ownership can align users, developers, investors, and service providers with a share goal. Growing the network helping overcome the bootstrap problem by sharing the collective gain via token ownership. He points that tokenizing network across different domains is the next chapter in open computing such as Linux or Wikipedia, making online infrastructure more accessible and fair.

Importance of Decentralization

Chris Dixon defines two eras:

Era 1 (1980s to early 2000s): Internet services were built on open, decentralized protocols like HTTP and SMTP. Anyone could build on them without permission allowing openness, helping companies grow and innovate.
Era 2 (mid-2000s to present): Large centralized platforms came to dominate this space. These companies (i.e. MAG7) controlled platforms and set rules for developers, eliminating third party innovation. During Era 2, I have a slight objection to what Dixon writes. Era 2 isn’t only centralized dominance; the open-source substrate stayed alive and materially enabled innovation. While distribution and user access became more centralized, the open-source "substrate" still enabled meaningful third-party innovation, especially in developer tooling and infrastructure.

In AI/ML, frameworks like PyTorch and TensorFlow were made open source. Majority of cloud infrastructure relies on Linux and Kubernetes allowed developers to build and deploy applications at scale without paying for licensing fees. Open sourcing by powerful "monopolistic" still allows us (the third party) to experiment. Though in the current landscape, many projects are bounded by training infrastructure like GPUs.

Dixon argues we're entering Era 3 of the internet, built on decentralized cryptonetworks (e.g. Bitcoin, Ethereum) that combine the best features of both earlier eras. Systems that use blockchain consensus and tokens to align incentives individuals without a centralized authority. The benefit of decentralization is not only about censorship resistance, but he also list benefits that were mentioned earlier. I find the concept of forking particularly intriguing, as it offers a way for individuals to move forward when they disagree on a project's direction

"True Power" of DeFi

The "true power" of DeFi comes from composability, the ability for open, permissionless protocols to interact and build on top of one another like "Legos". Because DeFi applications are open-source and expose their functionality on shared blockchains, developers can combine existing protocols without needing approval, avoiding the silos common in Web2 finance. This article mentions Yearn Finance optimizing yields across platforms, Alchemix using those yields to create self-repaying loans, and Ribbon Finance layering option strategies on top of lending returns to demonstrate how composability allows capital to be reused efficiently across multiple different platforms.

While DeFi composability enables rapid innovation, it also introduces significant systemic risk tightly coupled protocol together in ways that amplify failure. Because many applications depend on shared liquidity, smart contracts, etc. A bug or exploit in a single foundational protocol can trigger widespread losses. TerraUSD/LUNA collapse in May 2022 is an example of systemic failure where breaking the fundamental protocol rippled through many interconnected protocols and markets. UST was integrated across different DeFi as a safe yield-bearing capital. Anchor was one of these platforms which offering unusually high yields. When UST lost its peg, large withdrawals and liquidity stress made it harder to defend the peg causing LUNA's price to collapse.

Bitcoin Protocol

The protocol has a set of rules:

identities: User control keypairs (private key $\rightarrow$ public key). Identity is basically just someone who can produce a valid signature.
ownership: The protocol tracks UTXOs. You "own" coins if you can satisfy the spending condition on some UTXO
auth: Spending is done by producing data that satisfies the the UTXO's locking condition
linking: Hash Functions bind transaction into Merkle trees and blocks into a chain so that altering old data forces redoing alot of work. A Bitcoin transaction has inputs and outputs, where each input spends a previous output (an existing UTXO). An output contains two main things:
value: how many satoshis (BTC) are in this output
locking script (scriptPubKey): the spending condition, which is a program that say what must be provided later to spend it. This is mainly just showing that you own the private key for this address. A common address style is P2PKH. The output is basically saying "these coins can be spent by whoever can provide a signature matching this public-key-hash". A block is a container for:
a block header (fixed-format summary)
a list of transaction (starting with a special coinbase transaction) Block headers is serialized in a specific 80-byte format and then hashed for proof-of-work. This include many different fields like version, previous block hash, merkle root, time, bits, and nonce. The important field to know is the merkle root which is all transaction commited to this block. The block hash is computed from the header (Bitcoin uses double-SHA256). If you change nay transaction, the Merkle root changes, header changes, PoW hash change, and the header hash is referenced by the next block where you must redo PoW for that block and every descendant.

Merkle Trees#

Within a block:

Each transaction is hashed
Hashes are paired and hashed again repeatedly up a binary tree
The final root hash is the Merkle root stored in block header Changing any tx change its leaf hash will change every ancestor thus the Merkle root. Efficient inclusion proof: To prove "tx T is in block B," you only need:

the tx hash
the sibling hashes along the path to the root ("merkle branch")
the blcok header that contains the merkle root This proof is logarithmic in numbers of transactions, not linear. Proof: Let a block contain transactions $T_0,T_1,...,T_{N-1}$ . Let $H:\{0,1\}^* \rightarrow \{0,1\}^n$ be a cryptographic hash. Define the leaf hash (transaction identifier) as: $L_{i}=H(ser(T_i))$ where $ser(T_i)$ is the byte serialization of the transaction. Define the parent hash operation as $Parent(a,b)=H(a\mid\mid b)$ Build the Merkle tree by repeatedly hashing pairs upward until one value remains. The final value is the Merkle root $MR\in\{0,1\}^n$ stored in the block header. The proof for leaf $L_i$ consists of:
transaction or its leaf hash
list of sibling hashes along the path from that leaf to root
left/right position at each step (order matters in $H(a\mid\mid b)$ $H (a ∣∣ b)$ . $\pi = ((s_0,b_0),(s_1,b_1),...,(s_{d-1},b_{d-1})$ $π = ((s_{0}, b_{0}), (s_{1}, b_{1}), ..., (s_{d - 1}, b_{d - 1})$
- $s_{k}\in \{0,1\}^n$ is the sibling hash at level $k$
- $b_k \in \{0,1\}$ is a direction bit:
- $d$ or the depth is approximately $\log_2 N$ Verification Algorithm:

Start from the leaf: $x_0=L_i$
For each level $k$ where $k\in \{0,1,...,d-1\}$ , combine the sibling $s_k$ in the correct order
Accept if the final computed value equal the Merkle root in the header If it matches, the transaction is included. A full derivation is available in this Bitcoin StackExchange thread on Merkle inclusion proofs. Additionally, see the visual Merkle tree proof walkthrough.

Mining and PoW#

Nielsen motivated PoW as a way to stop someone from creating a billion fake votes on a transaction validity. Instead, influence is proportional to computational work. Miners collect valid transaction from the mempool, build a candidate block (including coinbase tx paying themselves), compute the merkle root, and fill the header fields and try to find a header hash below the target. Targets adjust every 2016 block. The coinbase transaction creates the block subsidy (new BTC) plus collects transaction fees. Nodes verify coinbase amount does not exceed subsidy+fees.

Forking#

Forks happen when two miners find valid block at similar times. Bitcoin resolves this disagreement by selecting the chain with the most accumulated proof-of-work. Then, the nodes may reorg (roll back a few blocks and apply the winning branch by that node). The transaction from the losing branch return to the mempool. A full node verifies

every block header PoW
every transaction scripts/signatures
that inputs spend existing UTXOs
that money creation is within rules SPV clients doesn't validate all transaction. It downloads only block headers. Bitcoin developer documentation describes SPV as downloading headers and requesting transactions as needed. The bandwidth scales with chain height at 80 bytes/header.

See the Bitcoin transaction lifecycle walkthrough.

Ethereum Whitepaper

Instead of only tracking UTXOs like Bitcoin, Ethereum tracks a global state of accounts and code. It lets transactions trigger state transitions built in the VM (the EVM). The whitepaper's key claim is that "Bitcoin's big invention isn't money, it's a distributed consensus machine." Ethereum generalizes that where it provides a blockchain with a Turing-complete programming language so you can encode arbitrary state transition function ("smart contracts") directly on-chain. That means the "ledger" isn't just balances/UTXOs, it is a shared word state containing:

accounts with balances and storage
accounts that hold code (contracts)
rules for executing code deterministically on every node This whitepaper formalizes a cryptocurrency ledger as

APPLY(S, TX) -> S' OR ERROR

where:

S is current state
TX is a transaction
S' is the next state if valid else returns error It describes S as the set of unspent transaction outputs (UTXOs) and a transaction as consuming old UTXOs and producing new ones. The validation logic is described as the following:

Each input reference an existing UTXO and has a valid signature for it
sum(inputs) >= sum(outputs
Update the UTXO set Ethereum uses this framing because it want to define its APPLY function with a richer "state" than UTXOs. The whitepaper survey alternative blockchain apps and argues that building each one special purpose protocol could be redundant. Therefore, ETH aims for a single general platform where the blockchain is the computer and contracts are programs on it.

Decentralized Ordering#

If a trusted central server existed, you just need to run APPLY on that server. But in a decentralized network:

different nodes see transaction in different orders
attackers can try to double spend by racing transaction There must be a consensus mechanism that makes nodes converge on one canonical order of state transitions. This sets up the need for mining. Originally, ETH started as a PoW but transitions to PoS instead.

ETH's Design#

Ethereum replaces UTXOs with accounts. Externally Owned Account (EOAs) are controlled by private keys and Smart Contracts are controlled by code (EVM bytecode). Each account has a balance (ETH) and depending on type (nonce, code, and persistent storage). Ethereum state is organized around account objects. This makes it natural to store contract storage (key-value persistent memory) and program code (contract's logic).

Transactions vs Messages#

Transactions: Signed, originate from EOAs, pay fees and can create contracts or call contracts
Messages: Internal calls created by contract execution which is not signed but still part of the deterministic execution of a transaction. A singly externally-signed transaction can trigger a cascade of internal message calls (contract A calls contract B calls contract C and so on) and every node must reproduce that exact call tree and final state.

Transition Function `APPLY(S, TX)`

Validate the transaction (signature, nonce , balance $\ge$ gas, etc.)
Deduct fee ("gas")
Execute
- If it's a contract creation, initialize new account + run init code
- If it's a call, run callee code in EVM
Apply state change (balance, storage writes, logs)
Refund unused gas and pay validator/proposer fee

Merkle Patricia Tries#

BTC block commit to transactions via Merkle root. ETH commits using Merkle Patricia Tries (a trie that support key-value mapping with cryptographic commitment). See the visual depiction of Merkle Patricia Tries.

DeFi, Lending Protocols

To those who don't trust centralized figure, they are likely a believer in DeFi. Smart contracts are the backbone of DeFi as most project are built on top of Ethereum. Solidity, the Ethereum's programming language, allows for writing advanced smart contract that contain all logic that DeFi applications need. One of the early pioneers in DeFi application was MakerDAO (2015), allowing users to lock collateral to generate the DAI stable coin. Lending and borrowing is one of the pillars of this ecosystem. It also includes but not exclusive to:

Decentralized Exchanges: DEXes allow for exchanging crypto assets in a decentralized and permissionless way without giving up custody of the coin. There are 2 main types of dexes: the liquidity pool based and order book based ones. This includes Uniswap, Kyber, Bancor, etc.
Derivatives
Stable Coins: Tokens pegged to the US dollar, but the backing differs by design. Fiat-backed coins (USDT, USDC) hold dollar-equivalent reserves off-chain. Crypto/RWA-collateralized coins (DAI) are backed by on-chain collateral, and increasingly by real-world assets, depending on the era and collateral mix. Algorithmic coins try to hold the peg purely through smart-contract incentives with no equivalent reserve, UST is the cleanest (and cautionary) example.
Margin Trading
Insurance

AMM#

An AMM is a type of decentralized exchange protocol that uses a formula to price assets instead of orderbook with buyers and sellers. The idea is to trade against a liquidity pool, a smart contract holding reserves of two (or more) tokens. The price you get is determined by a formula based on the ratio of tokens in the pool. A Stableswap AMM is designed for assets that should trade near the same price like: USDC/USDT or stETH/ETH. With a constant product curve, even swapping two stable coins that are both around a dollar produces slippage. The amplification parameter (A) controls the Stableswap formula:

$A$ is high: the curve behaves like constant sum ( $x+y=k$ ) where slippage is low
$A$ is low: it behaves like constant product ( $x\cdot y=k$ )

Uniswap#

Uniswap uses an AMM (Automated Market Maker). The foundation of Uniswap is simple: $x\cdot y=k$

$x$ is the reserve of Token $A$
$y$ is the reserve of Token $B$
$k$ is the constant Every trade must preserve this invariant and the product of the two reserves never changing. For example, a pool holds $100$ ETH and $300,000$ USDC, so $k=30,000,000$ . If you want to buy ETH by depositing $\Delta y$ USDC, the new reserves musts satisfy $(x-\Delta x)\cdot(y+\Delta y)=k$ Solving for $\Delta x$ is the amount of ETH you will receive. This means that the more you buy, the worse your price gets. This is price impact and it emerges naturally from the curve's shape. The marginal price at any point is just the ratio of reserves: $P=\frac{y}{x}$ . Uniswap V2 charges $0.3\%$ on each trade. The input amount is reduce before constant product check, so fees effectively increase $k$ overtime, benefiting liquidity providers.
Price Impact graph: larger USDC deposits raise the effective ETH price due to price impact
Larger trade size (USDC deposited) raises the effective price due to price impact.

As you add liquidity to Uniswap, you deposit both tokens in proportion to the current reserves. You receive LP tokens representing your share of the pool. Your return comes from:

Accumulated Trading Fees
Change in the Underlying token price Impermanent loss is the main risk. If the price of one token moves significantly relative to when you deposited, the pool's rebalancing means you end up with fewer appreciating tokens and more of the depreciating one. For a price change of ratio $r$ , the impermanent loss compared to just holding is $IL=\frac{2\sqrt{r}}{1+r}-1$

Uniswap V3#

V3 introduced concentrated liquidity, letting LPs specify a range $[p_a,p_b]$ for their capital. Instead of spreading liquidity across the entire curve, your capital acts as if it were amplified within that range. The effective liquidity is $L=\Delta x \cdot \frac{\sqrt{p_a \cdot p_b}}{\sqrt{p_b} -\sqrt{p_a}}$ A narrow range gives you the same fee income with less capital, but you earn nothing when the price moves outside of the range. Thus, the IL is magnified.

Orderbook DEXes#

Orderbook DEXes work differently where they match explicit limit orders. There are bids and asks at specific prices just like a traditional exchange. The key differences from AMMs:

Price Discovery: In an orderbook, the price is set by where the best bid meets the best ask. There's no formula and determined by the market makers positing orders. In an AMM, price is an output of the reserve ratio.
Capital Efficiency: Professional market makers on order books can quote tight spreads with concentrated capital at specific price levels. Uniswap V2's liquidity is spread across all prices (very inefficient), though V3 closes this gap significantly.
Depth: On an order book, slippage depends on the depth of the book (how many orders are stacked at each price level). On an AMM, slippage is a function of trade size relative to total pool reserves (the $Δx$ formula above). Small pools have terrible slippage; deep order books can absorb large trades with minimal impact.
Latency and MEV: Order books need fast matching engines (dYdX runs on its own L1 chain for this). AMMs on Ethereum are vulnerable to MEV (front-running, sandwich attacks) because pending trades sit in a public mempool before execution.

L1

A Layer 1 (L1) is a base blockchain that provides its own security: it has a native validator set, its own consensus, and is where final settlement happens. The defining property is that it does not borrow security from another chain. Bitcoin and Ethereum are L1s; an L2 (next section) executes elsewhere but settles back to an L1.

The Scalability Trilemma#

Vitalik's framing: with "naive" techniques a blockchain can have at most two of:

Decentralization: anyone can run a fully validating node on cheap hardware; no reliance on a small privileged set.
Security: the cost to attack the chain (rewrite history, censor, double-spend) is high relative to the value secured.
Scalability: throughput (transactions/sec) and low fees, measured per unit of node resource.

The trilemma is really a statement about naive scaling: the obvious way to get more throughput is to demand more from each node (bigger blocks, faster hardware), which prices out hobbyist nodes and erodes decentralization. The entire modern research program, sharding + data-availability sampling + ZK proofs, is an attempt to break the trilemma using cryptography so that a node can verify the chain without re-executing all of it.

Anatomy of an L1#

It helps to separate the functions a blockchain performs:

Networking: peer discovery and gossip (devp2p, libp2p), propagating transactions (the mempool) and blocks.
Consensus: agreeing on a single ordering of blocks. Two sub-jobs: Sybil resistance (who gets to propose, PoW/PoS) and fork choice / finality (which chain is canonical). Covered deeply in the BFT/PoS section.
Execution: applying the state-transition function (running the VM, e.g. the EVM) to produce the next state.
Data availability (DA): guaranteeing that the data behind a block was actually published, so anyone can reconstruct state and check it.
Settlement: the layer that provides finality and adjudicates disputes (where rollups anchor).

Monolithic vs Modular#

Monolithic: one chain does all five (Solana, Avalanche C-Chain, BNB, and pre-rollup Ethereum). Every full node executes every transaction. Pros: tight integration, atomic composability (the DeFi-Legos property the earlier notes praised, all contracts in one synchronous state), low latency. Cons: throughput is capped by what a single node can do, so you either limit decentralization (raise hardware requirements) or limit throughput.
Modular: split the functions across specialized layers. This is Ethereum's rollup-centric roadmap: Ethereum = consensus + DA + settlement; rollups = execution. Other examples: Celestia / Avail / EigenDA provide DA only. Pros: each layer specializes; execution scales horizontally across many rollups. Cons: fragmentation (liquidity and state split across rollups), cross-layer latency, and composability that no longer works synchronously across domains.

The earlier objection in the Decentralization section, that Era 2 still ran on an open-source substrate, has a nice analogue here: the monolithic vs modular debate is partly about where the open, permissionless substrate should live (one shared state machine vs many specialized layers).

Fee markets#

Fees exist to (a) resist spam/DoS, (b) ration scarce blockspace, and (c) pay for security.

Gas (Ethereum): every EVM opcode is metered; a block has a gas limit. You pay gas_used × gas_price.
First-price auction (Bitcoin, pre-2021 Ethereum): users bid a fee rate; highest bidders get in. Leads to overpaying and bad UX.
EIP-1559: splits the fee into a base fee (algorithmically set, burned) plus a priority fee / tip (paid to the proposer). The base fee adjusts up to ±12.5% per block to target ~50% block fullness. This makes fees more predictable and makes ETH issuance partly deflationary (burned base fee can exceed issuance).

State growth and statelessness#

The state (all account balances and contract storage) only grows, and every full node must store it. This is a long-run decentralization threat. Mitigations being researched/deployed:

State expiry: old, untouched state becomes dormant and must be revived with a proof.
Statelessness: block producers attach witnesses (proofs) so validators verify without holding the full state.
Verkle trees (and successors), replace the Merkle Patricia Trie with a commitment scheme (vector commitments) giving much smaller witnesses, a prerequisite for statelessness.

A survey of major L1 designs#

Ethereum: account model, EVM, PoS (Gasper). Deliberately keeps L1 execution modest and pushes scale to rollups; supplies cheap DA via blobs (EIP-4844) and, after Fusaka (Dec 2025), PeerDAS. The settlement/DA hub of the modular stack.
Solana: aggressively monolithic and high-throughput. Proof of History (PoH) is a verifiable hash chain that gives a cryptographic clock so nodes agree on ordering before consensus; Tower BFT is a PBFT variant layered on PoH; Sealevel executes non-overlapping transactions in parallel (txs declare the state they touch); Gulf Stream pushes transactions to leaders without a global mempool; Turbine shreds blocks for fast propagation. The cost is high hardware requirements → fewer, beefier nodes (a decentralization trade-off).
Avalanche: metastable "Snow" consensus (repeated random subsampling, below in BFT section), the Primary Network plus subnets / custom L1s; the EVM-compatible C-Chain uses Snowman (linear ordering).
Cosmos: the app-chain thesis: every app is its own sovereign chain. CometBFT/Tendermint gives instant finality; the Cosmos SDK is a chain framework; IBC is a light-client-based interoperability protocol for trust-minimized cross-chain messaging.
Aptos / Sui: descendants of Diem, both use the Move language (resource-oriented, assets are first-class types that can't be copied/dropped). Aptos uses Block-STM (optimistic parallel execution). Sui adds an object model with a consensus-less fast path for simple owned-object transfers, falling back to a DAG mempool (Narwhal) + consensus (Bullshark) for shared objects.
Cardano: Ouroboros PoS (peer-reviewed, provably secure) and an extended UTXO (eUTXO) model (Bitcoin-style UTXOs augmented to carry contract logic).
Bitcoin: the original L1: PoW, UTXO, intentionally minimal scripting; optimizes security/decentralization over expressiveness.

Cross-L1 interoperability#

Moving value/state between L1s uses bridges: lock-and-mint (lock on chain A, mint a wrapped asset on B) or burn-and-mint. Trust models range from multisig/custodial (most hacked, Ronin ~ $625M, Wormhole ~$ 320M) to light-client / validity-proof bridges (IBC, zk-bridges) that verify the other chain's consensus on-chain. Bridges are historically the single largest source of crypto losses, precisely because they concentrate value with weaker security than the chains they connect.

The "modular endgame" debate (2026)#

The live argument is rollup-centric Ethereum (many execution layers over a shared DA/settlement base) vs monolithic high-performance L1s (Solana). Notably, with L1 DA scaling via PeerDAS in 2026, Vitalik has argued that cheaper, higher-capacity L1 data reduces the need for a proliferation of generic rollups, the surviving rollups will differentiate on ecosystem and governance, not just on being "another EVM chain."

L2

A Layer 2 (L2) is a protocol that executes transactions off the L1 but inherits the L1's security: it publishes its data and/or proofs to the L1 so that (1) anyone can reconstruct its state and (2) state correctness is enforceable on the L1. This is the crucial line between an L2 and a sidechain: a sidechain has its own validator set and security and merely bridges; if its validators collude, your funds are gone regardless of what Ethereum says.

Why L2s (the rollup-centric roadmap)#

Ethereum chose not to scale base-layer execution (that would raise node requirements and hurt decentralization). Instead: keep L1 cheap to validate, use it for consensus + DA + settlement, and move execution to rollups. The slogan is "scale data availability, not execution."

What "inherits L1 security" actually requires#

Two conditions:

Data availability: the rollup's transaction data (or state diffs) must be published on L1, so anyone can reconstruct the L2 state and, if needed, exit without the operator's cooperation.
State validity enforcement: there must be an on-chain mechanism to reject invalid state transitions: either fraud proofs (optimistic) or validity proofs (ZK).

The community grades how trustless a rollup really is with L2BEAT's Stage 0 / 1 / 2 framework:

Stage 0: "training wheels": operators/security council can override; users trust the team.
Stage 1: a functional proof system exists with limited council override.
Stage 2: fully trustless; the proof system governs and a council can act only for verified bugs.

As of 2026, Arbitrum One, OP Mainnet, and Base run live permissionless fraud-proof systems (Stage 1); many smaller rollups remain Stage 0; most ZK rollups still rely on a centralized prover, which is the current frontier for decentralization.

Taxonomy of scaling approaches#

State / payment channels (Lightning on Bitcoin, Raiden): lock funds in a 2-of-2 contract and exchange signed off-chain state updates, settling the net result on-chain. Excellent for high-frequency bilateral payments; poor for general programmability or open participation. Needs "watchtowers" to police fraud while you're offline.
Sidechains (Polygon PoS originally, Gnosis Chain): independent chains, not true L2s, you trust their consensus.
Plasma: child chains commit only state roots to L1 with fraud proofs, but keep data off-chain → the "mass exit / data withholding" problem (if the operator hides data you can't prove your balance). Largely superseded by rollups, though there's modest revival for payment-only use where validity proofs reduce the DA dependence.
Rollups: execute off-chain but post transaction data on-chain (DA) plus a validity mechanism. The dominant paradigm.
Validiums / Volitions: rollup-style proofs but DA is off-chain (validium) or a per-transaction user choice (volition, à la StarkEx). Cheaper, but adds a DA-committee trust assumption.

Rollups in depth#

Core idea: batch thousands of L2 transactions and post to L1 (a) the compressed data or state diffs (so the state is reconstructable, DA), (b) a commitment to the new L2 state root, and (c) a proof mechanism. Heavy compression (dropping signatures, indexing addresses, stripping zero bytes) plus a dedicated cheap data lane (blobs) is what makes the economics work.

Optimistic Rollups#

Post state roots optimistically (assumed valid). Anyone can submit a fraud proof during a challenge window (typically 7 days) to revert an invalid state.

Fraud-proof styles: interactive / multi-round (Arbitrum's bisection game: the disputers repeatedly halve the disputed range until a single execution step remains, which the L1 then runs, minimizing on-chain compute) vs single-round (Optimism's Cannon fault-proof VM executes a disputed step over a MIPS interpreter on L1).
Arbitrum (Offchain Labs): Nitro stack, Stylus (Rust/C++ contracts via WASM alongside the EVM), BoLD dispute protocol. Largest L2 (~40-44% of L2 TVL, ≈$16-17B in 2026).
Optimism: the OP Stack powers the Superchain: Base (Coinbase, no token, ~33% TVL), Mode, Zora, and dozens more share the stack and a roadmap toward a shared bridge and interop.
Trade-offs: easy EVM-equivalence and cheap "happy path" (no proof unless challenged), but 7-day withdrawal latency (third-party "fast bridges" front liquidity for a fee) and a liveness assumption (at least one honest verifier must be watching).

ZK (Validity) Rollups#

Post a validity proof (a SNARK or STARK) with each batch proving the state transition is correct; an L1 verifier contract checks it. No challenge window → fast finality and fast withdrawals once the proof is verified.

SNARK vs STARK: SNARKs are tiny and cheap to verify but historically need a trusted setup (Groth16; PLONK reduces this); STARKs need no trusted setup and are post-quantum but produce larger proofs (StarkNet).
zkEVM "types" (Vitalik's taxonomy, equivalence vs proving speed):
- Type 1: fully Ethereum-equivalent (proves real Ethereum blocks); slowest to prove; the target of the "real-time L1 proving" effort.
- Type 2: EVM-equivalent (identical to developers; minor internal differences). Scroll, Polygon zkEVM aim here.
- Type 3: almost EVM-equivalent (a few precompiles unsupported).
- Type 4: high-level-language equivalent (compile Solidity to a ZK-friendly VM): zkSync Era, StarkNet (Cairo). Fastest to prove, but not bytecode-compatible.
Trade-offs: trustless validity, fast finality, and no liveness assumption for safety; but proving is computationally expensive and prover decentralization is unsolved (most networks run a single prover today).

Data availability: the binding constraint#

A rollup is only as safe as its data is available: if data is withheld, you cannot prove your state or exit. This is the security crux.

On-chain DA (a true rollup) posts to Ethereum. Originally this used expensive calldata. EIP-4844 (Dencun, Mar 2024) introduced blobs: a separate, cheaper, ephemeral data lane (blobs are pruned after ~18 days) with its own blob-gas fee market. This cut L2 fees by ~90%.
PeerDAS (Fusaka, Dec 2025) adds data-availability sampling: nodes verify that erasure-coded blob data is available by randomly sampling fragments rather than downloading every blob, so blob throughput can scale without each node's bandwidth scaling. Blob-Parameter-Only (BPO) forks then ratchet blob targets upward through 2026. This is the first step toward full Danksharding.
Off-chain DA (validiums; or external DA layers like Celestia, Avail, EigenDA) is cheaper but adds a DA-committee/external trust assumption, strictly weaker than a true rollup.

Sequencers#

The sequencer orders L2 transactions and produces L2 blocks. Today almost all are centralized (run by the team). Risks: censorship, downtime, and the sequencer extracting L2-level MEV. Mitigations / roadmap:

Forced inclusion / escape hatch: submit a transaction directly via L1 if the sequencer censors you.
Decentralized sequencing and shared sequencers (e.g. Espresso), enabling cross-rollup atomicity.
Based (L1-sequenced) rollups: let L1 proposers sequence the rollup, inheriting L1 liveness/censorship-resistance.

L3s and app-chains#

Rollups that settle to another rollup (Arbitrum Orbit, OP Stack chains, StarkNet appchains). They can specialize (custom gas token, governance, throughput) at the cost of more fragmentation.

Bridges, interop, and intents#

Moving between L2s uses the canonical bridge (trust-minimized but slow on optimistic rollups due to the challenge window) or third-party liquidity bridges (fast, extra trust). The modern UX answer is intents: the user signs a desired outcome ("I want X on chain B for at most Y") and solvers compete to fulfill it cross-chain (UniswapX, CoW, across-chain solvers), abstracting away the bridge.

Current landscape (2026)#

~70+ rollups secure roughly ** $34-48B** TVL, but ~90% of activity sits on the top three. **Arbitrum** leads (~40-44%, ≈$ 16-17B), Base is second (~33%, Coinbase/OP Stack, no token, the biggest consumer chain), then OP Mainnet, followed by the ZK cohort (zkSync Era: pivoting toward institutional/permissioned "Prividium"; StarkNet; Scroll; Linea). The dominant narrative is consolidation plus the open question of whether cheaper L1 DA (PeerDAS) reduces the need for so many generic rollups.

Trading Mechanism

This builds on the AMM / orderbook material already in the DeFi section, zooming out to market microstructure and the full spectrum of on-chain trading designs.

Microstructure primitives#

Bid / ask / spread: best buy price, best sell price, and the gap between them (the market maker's gross margin).
Mid-price: average of best bid and ask; a reference "fair" price.
Depth: how much size sits near the top of the book; deep books absorb large orders with little movement.
Price impact: how your own trade moves the price (intrinsic to the venue's curve/book).
Slippage: the difference between expected and realized execution price (price impact + adverse price moves while pending).
Adverse selection / inventory risk: market makers lose to better-informed traders and accumulate unwanted inventory; they widen spreads to compensate.

Order types (CLOB)#

Market (take immediately at best available), limit (rest at a chosen price), stop / stop-limit (trigger when price crosses a level), IOC/FOK (immediate-or-cancel / fill-or-kill), post-only (only add liquidity, never take), iceberg (hide size). A central limit order book matches by price-time priority.

The on-chain trading design spectrum#

CLOB DEXes: on-chain or hybrid order books with explicit limit orders and a matching engine. On Ethereum L1 this is too expensive, so they run on app-chains/L2s: dYdX v4 (own Cosmos chain), Hyperliquid (own L1), historically Serum (Solana). Capital-efficient, tight spreads, familiar to pro market makers, but need fast, cheap blockspace.
AMMs: price from a formula against a pool. The family (extending the earlier notes):
- Constant product $x\cdot y=k$ (Uniswap V2).
- Constant sum $x+y=k$ , zero slippage but can be fully drained at the peg.
- Stableswap / Curve: a hybrid tuned by the amplification parameter $A$ (already covered): near-constant-sum (low slippage) close to the peg, reverting to constant-product in the tails to avoid depletion.
- Concentrated liquidity (Uniswap V3), LPs choose a price range (already covered); capital is "amplified" within the range at the cost of magnified IL outside it.
- Weighted pools (Balancer), $\prod_i x_i^{w_i}=k$ , $n$ assets with custom weights → behaves like a self-rebalancing index fund.
- Oracle / proactive market makers (DODO, GMX's GLP), price from an external oracle so swaps incur ~zero price impact, shifting risk onto LPs and introducing oracle dependence.
Aggregators / RFQ: 1inch, 0x, Paraswap, CoW: split an order across venues and pull professional Request-for-Quote prices to find best execution.
Batch auctions / uniform clearing price: CoW Protocol collects orders over a short batch and lets solvers compete to settle them all at a single clearing price. Two benefits: Coincidence of Wants (matching opposite traders directly, bypassing the AMM and its fee) and MEV resistance (a uniform price within the batch removes intra-batch ordering advantage). Generalizes to frequent batch auctions, a microstructure idea for defeating latency races.
Intents: the user signs a desired outcome and solvers compete to realize it (UniswapX, CoW, 1inch Fusion). This pushes execution complexity and MEV capture to a competitive solver market.

Perpetual futures ("perps")#

The dominant crypto derivative: futures with no expiry, kept near spot by a periodic funding rate (when the perp trades above spot, longs pay shorts, and vice versa). Designs:

Order-book perps: dYdX, Hyperliquid (on-chain CLOB matching).
Pool / oracle perps: GMX (the GLP pool is the counterparty; Chainlink sets price → zero price impact, but LPs absorb trader PnL), Synthetix (a shared debt pool mints synthetic assets), Perpetual Protocol (a virtual AMM).
Mechanics throughout: maintenance margin, liquidations, insurance funds, and auto-deleveraging when the insurance fund is exhausted.

Oracles (the price-truth layer)#

On-chain contracts can't see off-chain prices, so they rely on oracles:

Chainlink: a decentralized oracle network aggregating off-chain sources, pushed on-chain.
Pyth: low-latency, pull-based, first-party publisher prices.
On-chain TWAP (Uniswap V3 time-weighted average price), manipulation-resistant but laggy. Getting this wrong is catastrophic: oracle manipulation (use a flash loan to move a thin pool's spot price, then exploit a protocol that naively reads that spot) is behind many DeFi hacks, which is exactly the systemic-risk-from-composability point made in the earlier "True Power of DeFi" section.

Execution quality and protection#

Users defend execution with a slippage tolerance, a deadline, and MEV-protected RPCs (e.g. Flashbots Protect) or private order flow that keeps a transaction out of the public mempool, which is the natural bridge into the next section.

MEV/Arbitrage#

Maximal Extractable Value (MEV) is the value a block producer can extract beyond block rewards and ordinary fees by choosing which transactions to include, exclude, and (above all) order. Originally "Miner EV"; renamed "Maximal" after the Merge, since extraction now spans validators, builders, and searchers.

Why it exists#

Three ingredients: a public mempool (pending transactions are visible), a single party orders each block, and deterministic, front-runnable on-chain state. Ordering is therefore economically valuable, and value flows to whoever controls it.

The MEV supply chain (post-Merge Ethereum)#

Users broadcast transactions to the public mempool: Dan Robinson's "dark forest," full of predatory bots.
Searchers scan the mempool and state for opportunities and build bundles (ordered transaction sequences), bidding for inclusion.
Builders assemble full blocks from competing bundles + public transactions to maximize total extractable value, competing in an auction.
Relays are trusted intermediaries that hold a builder's block, reveal only the header to the proposer, and guarantee atomic payment so neither side can cheat (the builder's bundle isn't stolen; the proposer is paid).
Proposer (validator) runs MEV-Boost, picks the highest-bidding header, and signs it. ~90% of Ethereum blocks are built this way.

Types of MEV#

DEX arbitrage: equalize prices across pools/venues in a single atomic transaction. Largely benign: it keeps AMM prices in line with the market.
Liquidations: repay an undercollateralized loan (Aave/Compound) for a bonus; searchers race for it. Necessary for protocol solvency.
Sandwich attacks: front-run a victim's large AMM swap (buy first, pushing price up), let them execute at the worse price, then back-run (sell after). Pure extraction from users, toxic MEV.
Back-running: place a transaction immediately after a target event (oracle update, big swap); less harmful than sandwiching.
JIT (just-in-time) liquidity: add tight V3 liquidity right before a big swap to capture the fee, then remove it, extracting from passive LPs.
Time-bandit attacks / reorgs: if the MEV in a past block exceeds the cost of re-mining it, a validator is tempted to reorg the chain to steal it. This is why MEV is a consensus-security problem, not just a UX nuisance.
Cross-domain MEV: opportunities spanning L1↔L2↔CEX boundaries.

Why MEV is dangerous (beyond annoying)#

Centralization pressure: sophisticated builders/searchers plus exclusive order flow create a builder oligopoly; validators capturing more MEV compound their stake.
Consensus instability: reorg/time-bandit incentives threaten finality.
Censorship: relays and builders can exclude transactions (e.g. sanctions-driven filtering).
User harm and congestion: sandwiching taxes ordinary users; historically, priority gas auctions spammed the chain with failed transactions.

Flashbots and MEV-Boost#

Flashbots introduced a private bundle relay (MEV-Geth), replacing on-chain priority gas auctions with off-chain sealed-bid auctions, cutting congestion and failed-transaction spam and democratizing MEV access. Post-Merge, MEV-Boost is the out-of-protocol implementation of Proposer-Builder Separation: validators outsource block construction to a competitive builder market via relays. This let small validators capture builder revenue, but it added relay trust and entrenched builder centralization.

Proposer-Builder Separation and the roadmap#

Out-of-protocol PBS (today): MEV-Boost + trusted relays.
Enshrined PBS (ePBS, EIP-7732): bring the proposer/builder split into the protocol: trustless on-chain builder auctions with no relay trust, plus more time for ZK-proof propagation. Scheduled for the Glamsterdam upgrade (H1 2026).
FOCIL (Fork-Choice Enforced Inclusion Lists, EIP-7805): a committee of ~16 randomly chosen validators each builds an inclusion list that forces the proposer/builder to include eligible transactions, preserving the MEV "last-look" auction while preventing censorship (lists capped at 8 KB). Targeted for the Hegota upgrade (H2 2026).
Encrypted / private mempools (e.g. Shutter), threshold-encrypt transactions until ordering is fixed, so builders can't see contents to front-run.
MEV redistribution / burn: order-flow auctions (MEV-Share, MEV-Blocker) rebate extracted value to users; proposed MEV burn would remove the proposer's incentive entirely by burning the surplus, turning ordering into a public good.

A worked arbitrage: optimal size between two constant-product pools#

Suppose two pools for the same pair, both $x \cdot y = k$ :

Pool A: $100$ ETH / $300{,}000$ USDC → price $3{,}000$ , $k_A = 30{,}000{,}000$ (ETH is cheap here).
Pool B: $100$ ETH / $330{,}000$ USDC → price $3{,}300$ , $k_B = 33{,}000{,}000$ (ETH is dear here).

Arb: buy $q$ ETH from A (pay USDC), sell it into B (receive USDC). Ignoring fees, profit is

\begin{aligned} \Pi(q) &= \underbrace{\left[330{,}000 - \frac{k_B}{100+q}\right]}_{\text{USDC received from B}} - \underbrace{\left[\frac{k_A}{100-q} - 300{,}000\right]}_{\text{USDC paid to A}} \\[4pt] &= 630{,}000 - \frac{k_B}{100+q} - \frac{k_A}{100-q}. \end{aligned}

Setting $\Pi'(q) = 0$ :

\Pi'(q) = \frac{k_B}{(100+q)^2} - \frac{k_A}{(100-q)^2} = 0 \;\Longrightarrow\; \frac{k_B}{(100+q)^2} = \frac{k_A}{(100-q)^2},

which rearranges to

\sqrt{k_B}\,(100-q) = \sqrt{k_A}\,(100+q).

Plugging in $k_B/k_A = 1.1$ gives $\sqrt{1.1}\,(100-q) = 100+q$ , so

q^* = 100 \cdot \frac{\sqrt{1.1}-1}{\sqrt{1.1}+1} \approx 2.38 \text{ ETH}, \qquad \Pi(q^*) \approx \$357.

The optimum is exactly where the two pools' marginal prices meet: arbitrage equalizes prices, which is why it's the "good" MEV that keeps AMMs honest. Trading more than $q^*$ overshoots and erodes profit (e.g. $q = 5$ ETH here is already a loss of about $75). With a $0.3\%$ fee on each leg, no-arb opens a band: arbitrage is only profitable once the price ratio exceeds roughly $1/(1-\gamma)^2$ , with $\gamma = 0.003$ .

Smart Contract Programming

Smart contracts are the backbone of everything above. They are immutable (by default), adversarial (anyone can call them), and they hold money, so correctness isn't a nicety, it's existential. "Code is law" cuts both ways.

The EVM#

The Ethereum Virtual Machine is a quasi-Turing-complete, stack-based VM operating on 256-bit words (sized for Keccak-256 and secp256k1 arithmetic). "Quasi" because gas bounds execution, sidestepping the halting problem, a contract can loop, but it will run out of gas and revert. Execution environment:

Stack: max depth 1024; all computation happens here.
Memory: volatile, byte-addressable, zeroed each call; expands as needed (and costs gas to grow).
Storage: persistent $256\text{-bit}\to 256\text{-bit}$ key-value map per contract; expensive (SLOAD/SSTORE), since every node stores it forever.
Calldata: read-only input to a call.
Message calls: CALL, STATICCALL (no state change), DELEGATECALL (run callee code in the caller's storage/context, the basis of libraries and upgradeable proxies, and a frequent source of bugs), CREATE / CREATE2 (deterministic, counterfactual addresses).

Determinism is mandatory, every node must reproduce execution identically, so there's no native randomness (use Chainlink VRF or commit-reveal), block.timestamp is weakly proposer-manipulable, and all external data comes through oracles.

Solidity (and the alternatives)#

Solidity is the dominant language (alternatives: Vyper, raw Yul/assembly, Stylus = Rust on Arbitrum, Move on Aptos/Sui). A contract has state variables (in storage), functions, events, modifiers, and inheritance.

Visibility: public / external / internal / private. Mutability: view (reads only) / pure (no state access) / payable (accepts ETH).
Context: msg.sender, msg.value, tx.origin, block.*.
Events / logs: cheap, written to transaction receipts with indexed topics; how front-ends and indexers (The Graph) read contract activity off-chain.
Storage layout: variables map to 32-byte slots; pack small types together to save gas; mappings and dynamic arrays live at hashed slots.

Lifecycle: a deployment transaction runs creation (init) code → the constructor executes → the runtime bytecode is returned and stored at the new address. CREATE2 enables deterministic addresses (used by smart wallets and factories).

Standards (ERCs)#

ERC-20 (fungible): transfer / approve / transferFrom / balanceOf. Note the approve race condition and that some tokens (USDT) don't return a bool → use SafeERC20.
ERC-721 (unique NFTs), ERC-1155 (multi-token, batch transfers).
ERC-4626 (tokenized vaults), standardizes yield-bearing shares; central to DeFi composability.
ERC-2612 (permit): gasless approvals via signatures.
ERC-4337 (Account Abstraction): smart-contract wallets without a protocol change (UserOperations, bundlers, an EntryPoint contract, and paymasters for gas sponsorship). Complemented by EIP-7702 (Pectra, May 2025), which lets a plain EOA temporarily execute as a smart account.

Security: the core discipline#

Each of these maps to real, expensive failures:

Reentrancy: a contract makes an external call before updating its own state, letting the callee re-enter and repeat the action (e.g. drain a balance). This was The DAO hack (2016, ~$60M), which caused the ETH/ETC fork. Fix: the Checks-Effects-Interactions ordering and a reentrancy guard (mutex). Watch for the subtler read-only reentrancy (a view function returns stale state mid-callback).
Integer overflow / underflow: pre-Solidity-0.8 required SafeMath; 0.8+ checks arithmetic by default (opt out only inside unchecked { }).
Access control: missing or wrong onlyOwner, unprotected initializers on proxies (the Parity multisig freeze locked ~$150M this way), or accidentally public functions.
Oracle manipulation / flash-loan attacks: borrow a huge sum with no collateral (repaid in the same transaction), move a manipulable spot price, and exploit a protocol that prices off that spot (bZx, Harvest, Mango). Fix: robust oracles / TWAPs; never price off a single thin pool's spot.
Unchecked external calls: low-level call returns a bool instead of reverting; you must check it.
delegatecall / storage collisions: proxy and implementation must share an identical storage layout, or state corrupts; an arbitrary delegatecall target is a full takeover.
tx.origin authentication: phishable; authenticate with msg.sender.
Signature replay & malleability: require nonces, a chainId, and EIP-712 domain separation.
Denial of service / griefing: unbounded loops over user-controlled arrays; pushing a payment to an address that reverts. Use the pull pattern.
Rounding / precision: round in the protocol's favor; beware first-depositor share-inflation attacks in vaults.

Reentrancy: vulnerable vs fixed#

// VULNERABLE: external call before state update
function withdraw() external {
    uint256 bal = balances[msg.sender];
    (bool ok, ) = msg.sender.call{value: bal}("");   // callee can re-enter here
    require(ok);
    balances[msg.sender] = 0;                         // updated too late
}

// FIXED: Checks-Effects-Interactions (+ a nonReentrant guard for defense in depth)
function withdraw() external nonReentrant {
    uint256 bal = balances[msg.sender];
    balances[msg.sender] = 0;                         // effect first
    (bool ok, ) = msg.sender.call{value: bal}("");    // interaction last
    require(ok);
}

Design patterns#

Checks-Effects-Interactions, pull-over-push payments (the withdrawal pattern), reentrancy guards, circuit breakers / Pausable, timelocks on governance, and role-based access control (OpenZeppelin Ownable / AccessControl).

Upgradeability: because contracts are immutable, upgrades go through a proxy that delegatecalls into a logic contract:

Transparent proxy: admin and user call paths are separated to avoid selector clashes.
UUPS: the upgrade logic lives in the implementation (cheaper, but the implementation must include it).
Diamond (EIP-2535): one proxy multiplexing many "facets." Upgradeability is a trade-off: it buys you bug-fixing but reintroduces a trusted admin key (centralization) and demands strict storage-layout discipline. Factory and minimal-proxy clones (EIP-1167) make cheap mass deployment possible.

Tooling and assurance#

Because bugs are total and irreversible, defense is layered: dev frameworks Foundry (fast, Solidity-native tests + fuzzing + invariant testing) and Hardhat; static analysis (Slither, Mythril); fuzzing / invariant testing (Echidna, Foundry); formal verification (Certora, K framework, SMT solvers); plus audits, bug bounties (Immunefi), timelocks + multisig (Safe), value caps, and runtime monitoring (Forta).

Byzantine Fault Tolerance & Proof-of-Stake algos

This is the consensus core that everything above rests on: how mutually distrusting nodes, with no central coordinator, agree on a single ordering of transactions despite failures and adversaries.

Fault models#

Crash (fail-stop): a node simply halts.
Byzantine: a node behaves arbitrarily: lying, sending different messages to different peers (equivocation), and colluding. Named for Lamport's Byzantine Generals Problem (1982), where generals must coordinate an attack over messengers while some generals are traitors.

Network timing models#

Synchronous: message delay is bounded by a known $\Delta$ .
Partially synchronous: a bound exists but is unknown, or holds only after some unknown GST (global stabilization time). This is the realistic model most BFT protocols target.
Asynchronous: no timing bound at all.

The impossibilities and the central trade-off#

FLP impossibility (Fischer-Lynch-Paterson, 1985): in a fully asynchronous network, no deterministic protocol can guarantee consensus if even one node may crash. Real systems escape this by assuming partial synchrony (timeouts) or by adding randomization.
CAP theorem: under a network partition you must choose Consistency or Availability. BFT chains (Tendermint) choose consistency (they halt rather than fork); Nakamoto chains choose availability (they keep producing and resolve forks later).
Safety vs Liveness:
- Safety: nothing bad happens, no two honest nodes finalize conflicting blocks.
- Liveness: something good eventually happens, the chain keeps making progress. Tendermint prioritizes safety (halts if >1/3 are Byzantine); Nakamoto prioritizes liveness (never halts) but offers only probabilistic safety.

Why $n \ge 3f+1$

A classical BFT protocol tolerating $f$ Byzantine nodes needs at least $n = 3f+1$ total, using quorums of $2f+1$ . The argument is quorum intersection: any two quorums of size $2f+1$ in a set of $3f+1$ overlap in at least $(2f+1)+(2f+1)-(3f+1) = f+1$ nodes. Since at most $f$ are Byzantine, that overlap contains ≥1 honest node, who won't vote for two conflicting values, so two conflicting decisions can't both gather a quorum. You need $2f+1$ (not just $f+1$ ) so that even if $f$ honest nodes are slow/partitioned, the remaining honest majority can still form a quorum → liveness. In stake terms: tolerate up to <1/3 of stake Byzantine.

Classical BFT: PBFT (Castro-Liskov, 1999)#

Leader-based, partially synchronous, $3f+1$ . A request goes through three phases:

Pre-prepare: the leader assigns a sequence number and broadcasts the proposal.
Prepare: replicas broadcast agreement; each waits for $2f+1$ matching prepares.
Commit: replicas broadcast commit; each waits for $2f+1$ commits, then executes.

Two all-to-all rounds → $O(n^2)$ messages. If the leader is faulty, a view change (triggered by timeout) elects a new one, the expensive, tricky part. Once committed, finality is deterministic and immediate.

Modern pipelined BFT: HotStuff (2019)#

Reduces communication to $O(n)$ by routing votes through the leader and aggregating them with threshold signatures, and pipelines its phases (each block's phases overlap with the next), rotating the leader every view. It is responsive (advances at actual network speed, not worst-case $\Delta$ ). Basis of DiemBFT → Aptos (Jolteon/AptosBFT).

Tendermint / CometBFT (Cosmos)#

BFT PoS, partially synchronous, $3f+1$ by stake. Each height runs rounds of propose → prevote → precommit, each needing >2/3 of voting power; locking rules forbid voting for a conflicting block once you've precommitted. Result: instant, deterministic finality (one block, no reorgs). It halts rather than forks if >1/3 of stake is Byzantine (safety over liveness), and equivocation is cryptographically attributable → slashable.

Nakamoto consensus (the contrast)#

No fixed validator set; open participation with Sybil resistance via PoW (or chain-based PoS). The canonical chain is the heaviest / longest (Bitcoin) or chosen by GHOST. Finality is probabilistic: the deeper a block, the harder to reverse ("wait 6 confirmations"). It tolerates unknown, dynamic membership and heavy churn and never halts (favoring liveness), at the cost of high latency, low throughput, and a higher (but only probabilistic) 51% attack threshold vs BFT's 33%.

Why PoS (vs PoW)#

Sybil resistance comes from economic stake rather than burned energy: cheaper, greener, and, crucially, it enables in-protocol penalties (slashing) that PoW can't do (you can't confiscate a miner's electricity). New problems unique to PoS:

Nothing-at-stake: voting on every competing fork is costless (no physical work per fork). Fixed by slashing equivocation.
Long-range attacks: validators who have withdrawn could re-sign an alternate history from genesis at no present cost. Fixed by weak subjectivity (a newly syncing or long-offline node must start from a recent trusted checkpoint) plus withdrawal delays.
Stake grinding, validator cartels, and liquid-staking centralization (e.g. Lido's share of stake).

Chain-based PoS (Nakamoto-style, longest chain) vs BFT-style PoS (explicit voting, fast finality) are the two families; Ethereum's design is a hybrid.

Ethereum's consensus: Gasper (the worked example)#

Gasper = Casper FFG + LMD-GHOST:

LMD-GHOST (Latest-Message-Driven Greedy Heaviest-Observed SubTree) is the fork-choice rule, follow the subtree with the most attesting stake using each validator's latest vote.
Casper FFG (Friendly Finality Gadget) is the finality overlay laid on top.

Time structure: 12-second slots; 32 slots = 1 epoch (~6.4 min). One proposer per slot (selected via RANDAO); validators are split into committees and each attests once per epoch. An attestation carries both a head vote (for LMD-GHOST) and a checkpoint vote (FFG source → target).

Justification & finalization: an epoch boundary checkpoint becomes justified when ≥2/3 of total stake votes for it; when two consecutive checkpoints are justified, the earlier one is finalized. So finality takes ~2 epochs (~12.8 min). Reverting a finalized block requires ≥1/3 of all stake to be slashed → economic finality.

Validators: 32 ETH to activate; EIP-7251 (Pectra) raised the max effective balance to 2048 ETH (allowing consolidation of many validators into one). Activation and exit are rate-limited by queues. Rewards accrue for timely, correct attestations and proposals.

Slashing conditions, both provably attributable:

Double vote / proposal (equivocation).
Surround vote: an FFG vote whose (source, target) interval surrounds or is surrounded by another of your votes. Slashed validators lose stake and are ejected; a correlation penalty scales with how many validators are slashed together (deterring coordinated attacks).

Inactivity leak: if the chain can't finalize because >1/3 of stake is offline, the offline validators slowly leak stake until the online set again exceeds 2/3, restoring finality. This is how Ethereum recovers liveness from a large outage without sacrificing safety.

Roadmap: Single-Slot Finality (SSF) (finalize in one slot rather than two epochs, research), ePBS (EIP-7732, Glamsterdam), FOCIL (EIP-7805, Hegota), all under the broader "Surge / Scourge / Verge / Purge / Splurge" program.

Other notable PoS / BFT designs#

Cardano (Ouroboros): peer-reviewed, provably secure chain-based PoS; epochs and slots, VRF-based private leader election, "follow-the-Satoshi" stake selection. Variants: Praos (adaptive adversary, semi-synchronous) and Genesis (bootstrap from genesis without trusted checkpoints, tackling long-range attacks).
Algorand (Pure PoS): cryptographic sortition: a VRF privately selects proposers and a committee, revealed only after they act, so an adversary can't target them (DoS-resistant, unpredictable). Byzantine Agreement (BA⋆) yields no forks and fast finality; no minimum stake and no slashing (it relies on an honest majority of money plus ephemeral keys).
Avalanche (metastable "Snow" family) (Slush → Snowflake → Snowball → Avalanche/Snowman): repeated random subsampling: repeatedly query a small random sample of validators and shift toward the observed majority until confidence is high. Gives probabilistic safety with very fast finality and large validator sets, leaderless.
Solana (Tower BFT over Proof of History): PoH is a sequential, verifiable hash chain providing a global clock/ordering before consensus; Tower BFT is a PBFT variant exploiting that clock, using exponentially increasing vote lockouts.
DAG mempools (Narwhal/Tusk/Bullshark, used by Sui): separate data dissemination (a DAG of transaction batches) from ordering, decoupling throughput from consensus latency.

Finality taxonomy (summary)#

Probabilistic: Nakamoto, Avalanche (reorg risk decays with depth/confidence).
Deterministic / absolute: Tendermint, HotStuff (committed = final, period).
Economic: Ethereum (reverting finalized blocks costs ≥1/3 of all stake).

The recurring trade-off: deterministic-finality BFT is fast but needs a known validator set and bounded membership; Nakamoto-style is robust to open, churny membership but only probabilistic and slow.

Recent extensions#

Restaking (EigenLayer): re-use staked ETH to additionally secure other services ("AVSs"). It boosts yield but introduces correlated / systemic slashing risk (a bug in one AVS can cascade to ETH security).
DVT (Distributed Validator Technology): split one validator's keys/duties across several operators (Obol, SSV) for fault tolerance and decentralization.
Liquid staking (Lido, Rocket Pool), tokenize staked ETH for composability, at the cost of concentration concerns around any dominant provider.

Exercises

Problems span the whole reading list. Solutions are in collapsible blocks (Obsidian renders <details>) so you can self-test.

1. Merkle proof size#

A block contains $N = 1024$ transactions. How many sibling hashes are in the inclusion proof for one transaction, and why is this efficient?

The tree has depth $d = \log_2 N = \log_2 1024 = \mathbf{10}$ , so the Merkle branch is 10 sibling hashes. The proof is logarithmic in the number of transactions, not linear, to prove inclusion you carry only the tx hash, 10 siblings, and the header. This is exactly the property that makes SPV clients viable.

2. Why a nonce in the account model#

Bitcoin (UTXO) gets replay protection "for free" because each UTXO is spent exactly once. Ethereum uses an account balance model, why does it need a per-account nonce?

In the account model the same signed transaction (same sender, same amount) would be valid again if there were no extra state distinguishing it. The nonce (a per-account counter incremented each transaction) makes every transaction unique and strictly ordered, so a transaction can be included at most once and out-of-order replays are rejected. UTXOs achieve the same by consuming a specific output.

3. EIP-1559 base-fee dynamics#

The base fee adjusts up to ±12.5% per block toward a 50%-full target. If three consecutive blocks are completely full, what happens to the base fee? Completely empty?

Full blocks are above target, so the base fee rises by the max +12.5% each block: after three full blocks it's $1.125^3 \approx \mathbf{1.42\times}$ the starting base fee. Three empty blocks push it down by −12.5% each: $0.875^3 \approx \mathbf{0.67\times}$ . The burned base fee makes congestion expensive and is the deflationary lever on ETH supply.

4. Uniswap V2 price impact#

A pool holds $100$ ETH and $300{,}000$ USDC ( $k = 3\times10^7$ ). You buy 10 ETH. Compute the USDC paid without fees and with the $0.3\%$ fee, and the effective price vs the $3{,}000$ spot.

No fee. New ETH reserve $= 90$ , so new USDC $= k/90 = 333{,}333.33$ . USDC in $= 333{,}333.33 - 300{,}000 = \mathbf{33{,}333.3}$ → effective price $3{,}333.3$ /ETH, a ~11.1% impact.

With 0.3% fee (getAmountIn, $\gamma = 0.997$ ):

\Delta y_{in} = \frac{x_{in}\cdot \Delta x \cdot 1000}{(x_{out}-\Delta x)\cdot 997} = \frac{300{,}000 \cdot 10 \cdot 1000}{90 \cdot 997} \approx \mathbf{33{,}434.7}\ \text{USDC},

effective price $\approx 3{,}343.5$ /ETH. The fee adds ~ $100 and is what accrues to LPs (effectively growing$ k$).

5. Impermanent loss#

You LP into a 50/50 pool; afterward one token's price doubles ( $r=2$ ). Compute IL vs simply holding.

$IL = \frac{2\sqrt{r}}{1+r} - 1 = \frac{2\sqrt{2}}{3} - 1 = \frac{2.8284}{3} - 1 \approx \mathbf{-5.7\%}.$ You end up with fewer of the appreciating token and more of the other, underperforming a hold by ~5.7% (before fees). IL is symmetric in log-price and grows with the size of the move; concentrated-liquidity (V3) magnifies it within a range.

6. Stableswap intuition#

In Curve's Stableswap, why does a high amplification $A$ give low slippage for USDC/USDT, and what's the danger if the peg breaks?

High $A$ pushes the invariant toward constant-sum $x+y=k$ near the balance point, so swaps near $1{:}1$ barely move the price → tiny slippage for like-priced assets. The danger: if one asset de-pegs, the near-constant-sum region lets arbitrageurs drain the good asset cheaply, so the pool ends up almost entirely holding the broken asset. (This is the composability/systemic-risk theme, cf. the UST/LUNA collapse.)

7. Optimal cross-pool arbitrage#

Pool A: $100$ ETH / $300{,}000$ USDC. Pool B: $100$ ETH / $330{,}000$ USDC. Ignoring fees, find the profit-maximizing amount of ETH to buy from A and sell into B.

With $\Pi(q) = 630{,}000 - \frac{k_B}{100+q} - \frac{k_A}{100-q}$ and $k_A = 3\times10^7$ , $k_B = 3.3\times10^7$ , set $\Pi'(q)=0$ : $\frac{k_B}{(100+q)^2} = \frac{k_A}{(100-q)^2} \Rightarrow \sqrt{1.1}\,(100-q) = 100+q \Rightarrow q^\* \approx \mathbf{2.38\ \text{ETH}},\ \Pi(q^\*) \approx \mathbf{\$350}.$ The optimum equalizes the pools' marginal prices, which is why arbitrage is the mechanism keeping AMM prices aligned with the market.

8. The 3f+1 bound#

A BFT chain has 100 equal-weight validators. How many Byzantine validators can it tolerate, and what is the quorum size? State it in stake terms.

$n = 3f+1 \Rightarrow f = \lfloor (100-1)/3 \rfloor = \mathbf{33}$ . Quorum $= 2f+1 = \mathbf{67}$ . In stake terms: tolerate strictly less than 1/3 Byzantine stake; safety follows from any two 2/3-quorums intersecting in ≥1 honest node.

9. Ethereum finality timing#

Slots are 12 s and an epoch is 32 slots. How long is an epoch, and how long until a block is finalized under Casper FFG?

Epoch $= 32 \times 12 = \mathbf{384\ \text{s} \approx 6.4\ \text{min}}$ . A checkpoint is justified when ≥2/3 stake attests; finality needs two consecutive justified checkpoints → ~2 epochs ≈ 12.8 min. (Single-Slot Finality aims to collapse this to one slot.)

10. Surround votes#

Validator casts FFG vote $V_1$ with (source, target) epochs $(4, 5)$ . Which of these later votes is slashable as a surround? (a) $(5,6)$ (b) $(3,7)$ (c) $(5,7)$ .

(b) $(3,7)$ surrounds $(4,5)$ because $3 < 4$ and $7 > 5$ , a slashable surround vote. (a) is a normal forward vote; (c) neither surrounds nor is surrounded by $(4,5)$ . Equivocation and surround votes are the two attributable slashing conditions.

11. Anatomy of a sandwich#

A victim submits a swap with a generous 5% slippage tolerance into a thin pool. Walk through how a searcher extracts value and how the victim should have protected themselves.

The searcher's bundle: front-run by buying the same asset first (pushing the price up), let the victim's swap execute at the inflated price (still within their 5% tolerance), then back-run by selling, pocketing the spread. Defenses: a tight slippage tolerance, splitting the order, routing through a batch auction / uniform-clearing-price venue (CoW), or using a private/MEV-protected RPC so the pending tx never hits the public mempool.

12. Optimistic vs ZK rollup choice#

You're launching a high-value bridge needing fast, trustless withdrawals. Optimistic or ZK rollup, and what's the core trade-off?

ZK (validity) rollup: each batch carries a proof the L1 verifies, so withdrawals are fast (no challenge window) and there's no liveness assumption for safety. The cost is expensive, specialized proving and harder EVM-compatibility (plus today's centralized provers). An optimistic rollup is simpler and EVM-equivalent but imposes the ~7-day challenge window on trustless withdrawals.

13. Spot the bug#

function claim() external {
    require(!claimed[msg.sender]);
    (bool ok,) = msg.sender.call{value: reward}("");
    require(ok);
    claimed[msg.sender] = true;
}

What's wrong, and how do you fix it?

Reentrancy. The external call happens before claimed[...] is set, so the recipient's fallback can re-enter claim() and drain reward repeatedly (the flag is still false). Fix with Checks-Effects-Interactions: set claimed[msg.sender] = true; before the call, and optionally add a nonReentrant guard.

14. Why data availability is the crux#

A rollup posts validity proofs to L1 but keeps its transaction data off-chain (a validium). The proofs are valid. Why is this strictly weaker than a true rollup?

Validity proofs guarantee the state transition is correct, but not that the data is available. If the operator withholds the data, users can't compute their own balances or construct the withdrawal proofs needed to exit: funds can be frozen. A true rollup posts data on-chain (now via blobs, scaled by PeerDAS) so anyone can reconstruct state and exit without the operator. Availability, not just validity, is what lets users leave unilaterally.

15. PoH vs consensus (conceptual)#

Solana's Proof of History is sometimes called a consensus mechanism. Is it? What does it actually provide?

PoH is not consensus, it's a verifiable clock: a sequential hash chain proving time elapsed and a definite ordering of events before validators vote. Consensus (agreement on the canonical chain under faults) is provided by Tower BFT (a PBFT variant) layered on top. PoH's value is letting validators agree on ordering cheaply, boosting throughput; it doesn't by itself tolerate Byzantine faults.

16. Putting it together (open-ended)#

The earlier notes argue DeFi composability creates systemic risk (UST/LUNA). Using the L2, oracle, and MEV sections, name three additional places where tight coupling concentrates risk, and one mitigation each.

Shared sequencer / single sequencer across many rollups → correlated censorship/downtime. Mitigation: decentralized/shared sequencing + L1 forced-inclusion escape hatch.
A single oracle read by many protocols → one manipulation cascades (flash-loan attacks). Mitigation: decentralized oracles + TWAPs; never price off a thin spot.
Builder/relay oligopoly in the MEV supply chain → censorship and centralization. Mitigation: ePBS (EIP-7732) + FOCIL inclusion lists + encrypted mempools.
(Bonus) Restaking (EigenLayer) reusing the same ETH to secure many services → correlated slashing. Mitigation: conservative AVS risk limits and isolation.

Acknowledgements

These notes were developed primarly from Jump Crypto's published reading list which provides a structure way to understand the history of crypto. It explore core ideas including, but not limit to:

blockchain protocols
DeFi, AMMs, MEV/Arbitrage
decentralized systems

Jump's curated selection of whitepaper, technical resources, and exercise help me dive deeper into this topic. Any interpretations or extensions of these idea are my own.