Trilemma Blueprints Slides Protocol Engineering Series
Trilemma
Blueprints
Analyzing the fundamental constraints of distributed ledger scalability.
CS602 // Module 01
The Global Demand
Centralized networks (Visa) handle 24,000+ TPS. Decentralized networks struggle to break 100 without architectural shifts.
The Bottleneck
Every node must validate every transaction in a globally consistent order.
Bitcoin ~7 TPS
Ethereum 1.0 ~15-30 TPS
Visa (Peak) 65,000+ TPS
The Scalability Trilemma
Decentralization
Network can run on consumer hardware.
Security
Immunity to 51% attacks and reorganization.
Scalability
High throughput and low latency.
Pick Two
Calculating Throughput
// Theoretical TPS Formula
TPS = Block Size / (Avg Tx Size × Block Time)
Variables
Block Size: Max data per block (MB)
Block Time: Interval between blocks (s)
Tx Size: Metadata + Witness (bytes)
Example: Bitcoin
Size: 1MB
Time: 600s
Avg Tx: 250 bytes
Result: ~6.67 TPS
The Bandwidth Bound
Why not just make blocks 1GB? Propagation time.
Propagation Lag
Large blocks take longer to traverse the p2p network, increasing stale block rates.
Verification Cost
High-throughput requires powerful CPUs, pricing out hobbyist nodes (Centralization risk).
State Bloat
Faster chains accumulate history rapidly, making full node synchronization impossible for many.
Throughput Limit Worksheet Throughput Blueprints
CS602 // Scalability & Network Limits
NAME: ________________________________
DATE: ________________________________
Fundamental Equation
TPS = Bsize / (Tavg × Btime)
1
The Baseline Limits
Scenario A: A legacy Proof-of-Work network has a block size of 1.5MB, an average transaction size of 320 bytes, and a target block time of 12 minutes (720 seconds). Calculate the maximum theoretical TPS.
Scenario B: To compete with payment processors, the developers decide to decrease the block time to 15 seconds. If all other variables remain constant, what is the new TPS? Discuss one potential security risk of this change.
2
Trilemma Analysis Matrix
Evaluate how the following architectural decisions impact the three pillars of the trilemma. Use (+) for improvement, (-) for reduction, and (0) for neutral.
Architectural Change Scalability Security Decentralization Increasing Block Size to 500MB Requiring specialized ASIC hardware for nodes Implementing Proof-of-Stake (Consensus Shift) Restricting node participation to 21 elected entities
3
Engineering Challenges
Explain the concept of "State Bloat." Why does high scalability inevitably lead to storage issues for full nodes over a multi-year period?
In a p2p network, how does the "Speed of Light" physical constraint limit the minimum possible block time for a globally distributed network?
Trilemma Facilitation Guide Trilemma Debrief
TEACHER RESOURCE
Instructional strategies and answer keys for Lesson 01: The Scalability Trilemma and Network Limits.
Instructional Strategy
The "Pick Two" Debate
Divide the class into three groups, each advocating for one corner of the trilemma (Decentralization, Security, Scalability). Ask them to argue why their corner is the most critical for a global financial system and what they are willing to sacrifice from the other two.
Key Misconception
Students often think "better code" or "faster hardware" solves the trilemma. Emphasize that these are architectural and physical constraints (propagation speed, data availability, and peer-to-peer latency).
Worksheet Answer Key
Section 1: Baseline Limits
Scenario A Result:
1,500,000 bytes / (320 bytes * 720 sec) ≈ 6.51 TPS
Scenario B Result:
1,500,000 bytes / (320 bytes * 15 sec) = 312.5 TPS
Risk: Frequent "stale blocks" (forks) because 15s may be less than the network propagation time, leading to security vulnerabilities and centralization.
Section 2: Trilemma Matrix
<table class="w-full border-collapse bg-white"><tbody><tr class="bg-slate-100 font-bold"><td class="p-3 border border-slate-300">Change</td><td class="p-3 border border-slate-300">Scalability</td><td class="p-3 border border-slate-300">Security</td><td class="p-3 border border-slate-300">Decentral.</td></tr><tr><td class="p-3 border border-slate-300">500MB Blocks</td><td class="p-3 border border-slate-300 text-center text-green-600 font-bold">+</td><td class="p-3 border border-slate-300 text-center text-red-600 font-bold">-</td><td class="p-3 border border-slate-300 text-center text-red-600 font-bold">-</td></tr><tr><td class="p-3 border border-slate-300">ASIC Hardware Req</td><td class="p-3 border border-slate-300 text-center text-slate-400">0</td><td class="p-3 border border-slate-300 text-center text-green-600 font-bold">+</td><td class="p-3 border border-slate-300 text-center text-red-600 font-bold">-</td></tr><tr><td class="p-3 border border-slate-300">Proof of Stake</td><td class="p-3 border border-slate-300 text-center text-green-600 font-bold">+</td><td class="p-3 border border-slate-300 text-center text-slate-400">0</td><td class="p-3 border border-slate-300 text-center text-green-600 font-bold">+</td></tr></tbody></table>
Discussion Prompts
Q1: Can Layer 2 solutions break the Trilemma?
Guide students to realize that L2s don't "break" it so much as inherit properties. They utilize the security/decentralization of L1 while performing computation off-chain.
Q2: Why is 'State Bloat' more dangerous than 'History Bloat'?
Fragmented States Slides Layer 1 Architectures
Fragmented
States
Scaling the base layer through partitioning and parallelism.
The Horizontal Scale
Traditional blockchains are monolithic : every node processes every transaction.
The Sharding Thesis
"Divide the network into partitions (shards), each responsible for its own state and transaction processing."
📦
Shard A
Accounts 0x0...0x3
📦
Shard B
Accounts 0x4...0x7
📦
Shard C
Accounts 0x8...0xB
📦
Shard D
Accounts 0xC...0xF
The Complexity of "Cross-Talk"
Scenario: Transfer from Shard A to Shard B
STEP 1
Debit account on Shard A & generate receipt.
STEP 2
Beacon chain / Relay validates receipt.
STEP 3
Credit account on Shard B.
Risk: Double-spending across shards if communication isn't atomic or if one shard is compromised (1% attack).
The DAS Solution
How can nodes verify data exists without downloading it all?
Erasure Coding: Expand data so only a portion is needed to reconstruct the whole.
Random Sampling: Nodes check random tiny "chunks" of a block.
Statistical Certainty: After ~20 samples, the probability of missing data is near zero.
Verification via Probability
Parallel Processing (SVM vs EVM)
Sequential (EVM)
Transactions are processed one by one. Single-core performance bottleneck.
Tx 1: Bob -> Alice
Tx 2: Carol -> Dave
Tx 3: Eve -> Frank
Parallel (SVM/Sealevel)
Transactions specify state access. Independent txs run simultaneously on multi-cores.
Tx 1: Core 1
Tx 2: Core 2
Tx 3: Core 3
Tx 4: Core 4
Cross-Shard Protocol Analysis Shard Architecture Analysis
CS602 // Layer 1 Comparative Research
STUDENT: ________________________________
SEMESTER: ________________________________
In this lab, you will analyze two divergent approaches to Layer 1 sharding. Protocol implementation details differ significantly in how they manage the "Beacon" (Coordination) layer and cross-shard atomicity.
Feature Ethereum (Danksharding) Near (Nightshade) Coordination Layer
|
| Data Availability Solution |
|
|
| Cross-Shard Interaction |
|
|
| Validator Assignment |
|
|
Protocol Synthesis
1. The "Single Secret Leader Election" vs. "Randomized Assignments":
Discuss how Near and Ethereum prevent a malicious entity from targeting specific shard validators before they propose a block.
2. Synchronous vs. Asynchronous Communication:
Analyze why most sharding implementations choose asynchronous cross-shard calls. What are the UX implications for a user moving funds from Shard 1 to Shard 16?
KZG Commitments: Polynomial commitments used in Danksharding for DA sampling.
Blob-Carrying Transactions: Temporary data storage on Ethereum (EIP-4844).
Chunk: A fragment of a block that belongs to a specific shard in Nightshade.
Sharding Case Studies Key Shard Implementation Key
TEACHER REFERENCE
Reference data for Comparative Research Lab 02: Ethereum vs. Near architectures.
Research Key
Ethereum (Danksharding Roadmap)
Coordination: Beacon Chain manages validator sets and synchronization.Data Availability: KZG Commitments and Data Availability Sampling (DAS). Blobs are ephemeral (deleted after ~18 days).Interaction: Asynchronous. L2s use blobs as a "cheap" storage layer, keeping L1 as the data availability settlement layer.Validators: Distributed via a random selection process; focus on Builder-Proposer Separation (PBS) to mitigate MEV.
Near (Nightshade)
Coordination: Single blockchain where each block contains "chunks" from all shards.Data Availability: Erasure coding + Merkle proofs. Shard data is part of the main block structure.Interaction: Asynchronous "Receipts." Transactions that cross shards generate receipts that are processed in subsequent blocks.Validators: "Hidden Validators" rotate frequently to prevent corruption of a specific shard.
Technical Context for Discussion
KZG vs. Merkle Proofs
Merkle Proofs (Near) are simple but grow logarithmically with data size. KZG Commitments (Ethereum) allow for constant-sized proofs regardless of data volume, but require a "Trusted Setup" (Powers of Tau) ceremony, introducing a minor security assumption.
The 1% Attack
In a 100-shard system, if validators are static, an attacker with 1% of the total network power can control one entire shard. Both Near and Ethereum use Random Sampling and Validator Rotation to mathematically ensure that an attacker would need nearly 51% of the entire network to successfully corrupt a single shard.
Discussion Facilitation
Q: Why not use 1,000 shards?
The bottleneck moves to the Beacon/Coordination chain . It must track the headers of all shards. If there are too many shards, the beacon chain becomes a centralized bottleneck or crashes under the weight of cross-shard metadata.
Q: What is "Atomic Composability"?
The ability to execute multiple actions across different shards in a single transaction. Sharding breaks this. Discuss how "DeFi Legos" break when a swap happens on Shard 1 but the liquidity is on Shard 4.
Off-Chain Corridors Slides Off-Chain Expansion
Off-Chain
Corridors
Scaling through channels, sidechains, and trust-minimized bridges.
State Channels: The Bar Tab
Why settle every transaction on-chain when we can settle the net difference ?
Mechanism
Open: Multi-sig deposit on L1
Exchange: Signed state updates off-chain
Close: Final state submitted to L1
10,000 txs per second
Sidechains: Sovereign Scaling
Independent Consensus
Sidechains (like Polygon POS) have their own validators and security models.
Assumed Risk: If sidechain validators collude, L1 cannot protect your funds.
The Bridge Bottleneck
Moving assets requires a "Lock and Mint" bridge. This is the #1 point of failure in modern crypto.
Lower Fees, Lower Security
Sidechains trade off Layer 1 security for extreme throughput and negligible gas costs.
The Bridge Spectrum
Trusted (Custodial)
Centralized entity holds funds on L1 and mints on sidechain.
Example: WBTC, Ronin
Bonded (Economic)
Validators stake collateral that is slashed if they misbehave.
Example: Axelar, Thorchain
Trustless (Native)
Smart contracts verify consensus of the other chain directly.
Example: Cosmos IBC, Polkadot
Why Bridges Break
01. Private Key Compromise
Multi-sig validators lose keys (Social engineering or server hacks).
02. Smart Contract Logic
Errors in the "Lock" or "Release" logic allow double-claiming.
03. Consensus Manipulation
Chain A reorganizes, but the bridge already released funds on Chain B.
Case Study: Ronin Hack
Loss: $625 Million
Bridge Security Discussion Cards Bridge Breach Analysis
CS602 // Discussion Task Cards
Cut along the dotted lines
Scenario A
The Multi-Sig Malware
A sidechain uses a 5-of-9 multi-signature bridge. The validators are all employees of the same company. An attacker spear-phishes five employees and gains access to their private keys.
Analysis Prompts
Is this a technical or social failure?
How does "Validator Diversity" mitigate this?
Scenario B
The Reorg Race
A bridge observes a transaction on Chain A and immediately releases funds on Chain B. However, Chain A suffers a 5-block reorganization (reorg), and the original transaction is removed from the history.
Analysis Prompts
What is the role of "Finality" in bridge design?
How many confirmations should a bridge wait?
Scenario C
The Infinite Mint
A smart contract bug in the bridge allows an attacker to provide a fraudulent Merkle proof that looks valid. The bridge "mints" 1,000,000 tokens on the sidechain despite no collateral being locked on the mainnet.
Analysis Prompts
Why are "Trustless Bridges" harder to code?
How would a "Rate Limit" help here?
Scenario D
The Liquidity Crunch
A state channel requires users to lock up their capital for 7 days to ensure security. A sudden market crash happens, but users cannot move their funds back to the mainnet in time to trade.
Analysis Prompts
What is "Capital Efficiency"?
Why do channels struggle with mass exits?
Teacher Note: Distribute one card per group of 3-4 students. Give them 10 minutes to formulate a defense strategy before presenting to the class.
Compression Proofs Slides Layer 2 Architectures
Compression
Proofs
Scaling through batching, data availability, and cryptographic proofs.
Rollups: Inherited Security
A Rollup executes transactions off-chain but posts transaction data to Layer 1.
The Key Difference
Unlike Sidechains, if the Rollup sequencer disappears, anyone can reconstruct the state from L1 data and withdraw funds.
1. Execute Batch
2. Compress Data
3. Post to L1 (Blob)
Optimistic: "Innocent Until Proven Guilty"
Assume transactions are valid unless challenged.
Fraud Proofs
If a state update is wrong, "watchers" submit a proof to L1. The sequencer is slashed.
The Trade-off
Withdrawals take ~7 days to allow time for challenges (Challenge Window).
Requires "Honest Majority" of Watchers
ZK-Rollups: "Mathematical Certainty"
Validity Proofs (SNARKs/STARKs)
Every batch includes a cryptographic proof that the new state is correct.
Immediate Finality
Funds can be withdrawn as soon as the proof is verified on L1 (minutes).
The Trade-off
Generating ZK proofs is computationally expensive and requires high-end servers.
The L2 Choice
Feature Optimistic ZK-Rollup Withdrawal Time 7 Days ~15 Mins EVM Compatibility High (Simple) Medium (Complex) Computation Cost Low Very High
Rollup Deep Dive Worksheet Rollup Deep Dive
CS602 // Layer 2 Engineering Analysis
NAME: ________________________________
DATE: ________________________________
1
The Fraud Proof Sequence
In an Optimistic Rollup, what happens when a watcher detects an invalid state transition? Number the steps in the correct chronological order (1-5).
The Sequencer's bond is slashed and distributed to the challenger.
The Challenger submits a "fraud proof" to the L1 settlement contract.
The L1 contract re-executes the disputed transaction step-by-step.
The Sequencer publishes a batch of transactions with a new state root.
The state of the Rollup is rolled back to the last valid root.
2
ZK-Proof Comparison
Metric zk-SNARKs zk-STARKs Trusted Setup? Required Not Required Proof Size Very Small (~200 bytes) Larger (~45-200 KB) Quantum Resistant? No Yes
Analysis Case:
If Layer 1 gas costs are extremely high, which ZK-proof type would be more economical to verify on-chain? Justify your choice based on "Proof Size" vs. "Verification Cost."
3
Data Availability Scenarios
Define why Validiums (Rollups that store data off-chain) are considered less secure than standard ZK-Rollups even though both use Validity Proofs.
Network Weaving Slides Global Interconnectivity
Network
Weaving
Breaking the silos: Interoperability protocols and cross-chain messaging.
The Island Problem
Blockchains are inherently closed systems . They cannot verify external data without help.
The Interop Goal
Transfer state, assets, and logic across chains without centralized intermediaries.
Bitcoin
Ethereum
Solana
Cosmos: Inter-Blockchain Communication
The "Hub and Spoke" Model
Chains connect to a Hub. The IBC protocol allows chains to track each other's light client headers.
Packets sent via Relayers
Trustless verification
Sovereign security
HUB
Polkadot: Shared Security
Unlike Cosmos, Polkadot chains (Parachains) outsource their security to a central Relay Chain.
XCMP Protocol
Cross-Consensus Message Passing allows parachains to exchange any data, not just tokens.
Architectural Comparison
Security Origin Centralized (Relay)
Message Type Arbitrary Data
Network Topology Sharded / Heterogeneous
Atomic Swaps (HTLCs)
// Hashed Time-Locked Contracts
Bob creates a secret (s) and its hash H(s).
Alice locks BTC on Chain A using H(s).
Bob locks ETH on Chain B using H(s).
Alice reveals (s) to claim ETH on Chain B.
Bob sees (s) on-chain and claims BTC on Chain A.
Warning: If Alice disappears, Bob's funds are locked until the timeout (T).
Bridge Design Challenge Worksheet Bridge Architect Challenge
CS602 // Interoperability Project
Design Document
The Mission
Design a trustless, light-client-based bridge connecting two chains with different consensus mechanisms. You must ensure assets cannot be double-spent or permanently locked.
1
Protocol Specification
Source Chain (Chain A)
Consensus: Proof-of-Stake (BFT)Finality: Immediate (2/3 signatures)Messaging: Smart Contract capable
Destination Chain (Chain B)
Consensus: Proof-of-Work (Nakamoto)Finality: Probabilistic (6 blocks)Messaging: Restricted script capabilities
2
Relayer Architecture
Explain your "Light Client" implementation:
How will Chain B verify the headers of Chain A without downloading the entire state? What specific cryptographic proofs (Merkle, ZK) will you use?
Handling Chain B's Reorgs:
Since Chain B has probabilistic finality, how will your bridge contract on Chain A prevent "Finality Reversion" attacks?
3
Resilience & Recovery
The "Locked Capital" Scenario:
A user locks 100 ETH on Chain A, but the relayer network goes offline before the message reaches Chain B. Describe the Time-Lock / Refund mechanism you would implement.
Security vs. Liveness:
Would you rather have a bridge that crashes (Liveness failure) or one that allows a double-spend (Safety failure) during a network split? Justify your choice.
Scalability Mastery Assessment Scalability Mastery
CS602 // Final Protocol Analysis Exam
SCORE
___ / 100
STUDENT: ________________________________
ID NUMBER: ________________________________
Part I: Theoretical Frameworks
1. In the context of the Scalability Trilemma, why does increasing a network's transaction throughput via a larger block size typically degrade its decentralization?
It requires higher bandwidth and more storage, pricing out smaller node operators.
It reduces the hashing power required for PoW, making the network easier to attack.
It decreases the time needed for nodes to reach consensus on the state root.
2. Which scalability solution inherits the full security of the Layer 1 chain by posting all transaction data to the base layer?
Sidechains
Rollups
State Channels
Sovereign Chains
Part II: Architectural Synthesis
A. The Rollup Challenge:
Compare Optimistic Rollups and ZK-Rollups in terms of capital efficiency and data availability. Why would a high-frequency trading platform prefer ZK-Rollups over Optimistic ones?
B. Sharding & Communication:
Describe the mechanism of "Data Availability Sampling" (DAS). How does it allow a consumer-grade node to verify the integrity of a sharded network without downloading all shards?
Part III: Engineering Evaluation
You are a protocol lead for a new L1 blockchain. Your community demands 50,000 TPS, but insists that the network remains runnable on a standard laptop with a 1TB SSD.
Construct a scaling roadmap that combines three technologies studied in this sequence (e.g., Sharding + L2 + IBC). Justify how your combination satisfies both requirements.
End of Examination // CS602 Protocol Series
