lessons: complete the Solana-contrast set with 2 more callouts (consensus + P2P, EN+JA)

Adds the final 2 of the 5-callout set you originally accepted:

- consensus-ethereum-pos (Consensus Engineering tier): Tower BFT + Proof-of-History (Solana) vs Gasper (Ethereum). Different bet on the latency-vs-validator-pool-size tradeoff: ~400ms finality + high hardware requirements vs ~13min finality + ~1M-validator permissionless pool.
- p2p-fundamentals (P2P Networking tier): Turbine tree-broadcast (Solana) vs devp2p gossip (Ethereum). O(log N) shred propagation with symmetric high-bandwidth assumption vs O(N) gossip with adversarial-peer tolerance.

Together with the 3 earlier Inside REVM callouts (parallel execution, state model, VM dispatch), the curriculum now has 5 Solana-contrast callouts at the natural design-choice comparison points. Each makes the EVM choice readable as a choice, not an inevitability.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: psyto

prisma/seed-reth-consensus-engineering-en.ts

@@ -450,7 +450,9 @@ Sketch on paper:
 2. A slashing proof — what data is in it? Why is that data sufficient?
 3. The handshake from CL to EL when a new block arrives from the network
 
-> Final check: in two sentences, why is "Ethereum finality takes 13 minutes" not a bug — what does the 13 minutes buy us that 1-second BFT finality wouldn't? **If your answer doesn't include "validator decentralization at scale," re-read §1 of this lesson and §3 of last.**`,
+> Final check: in two sentences, why is "Ethereum finality takes 13 minutes" not a bug — what does the 13 minutes buy us that 1-second BFT finality wouldn't? **If your answer doesn't include "validator decentralization at scale," re-read §1 of this lesson and §3 of last.**
+
+> 🛣️ **The road not taken (Solana):** Solana's consensus is **Tower BFT + Proof-of-History (PoH)** — a fundamentally different bet from Gasper. Tower BFT is a PBFT variant where validator votes anchor to a *verifiable clock* (PoH — a SHA256 hash-chain that serves as a deterministic timeline). Validators don't agree on time first and then vote; PoH **is** the time, and votes reference points along it. The result: ~400ms finality vs Ethereum's ~13 minutes, at the cost of much higher validator hardware requirements and a single-leader-per-slot model (no per-slot committees, no ~1M validator pool). Gasper trades latency for permissionless validator participation at scale; Tower BFT trades validator-pool size for end-user latency. Both are valid BFT answers; the choice tracks what the chain optimizes for — open participation vs sub-second finality.`,
                 },
                 {
                   title: 'HotStuff and HyperBFT — the single-leader BFT family',

prisma/seed-reth-consensus-engineering-ja.ts

@@ -450,7 +450,9 @@ Ethereum ハイブリッドの 2 つの半分 (LMD-GHOST + Casper FFG) は、新
 2. Slashing proof — どんなデータが入っているか? なぜそのデータで十分なのか?
 3. ネットワークから新ブロックが来たときの CL→EL ハンドシェイク
 
-> 最終チェック: 二文で、「Ethereum の finality は 13 分」がバグではない理由 — 13 分が 1 秒の BFT finality にない何を引き換えに得ているか? **答えに「スケールでのバリデータ分散化」が出なければ、本レッスン §1 と前レッスン §3 を再読**。`,
+> 最終チェック: 二文で、「Ethereum の finality は 13 分」がバグではない理由 — 13 分が 1 秒の BFT finality にない何を引き換えに得ているか? **答えに「スケールでのバリデータ分散化」が出なければ、本レッスン §1 と前レッスン §3 を再読**。
+
+> 🛣️ **もう一つの道 (Solana):** Solana のコンセンサスは **Tower BFT + Proof-of-History (PoH)** — Gasper とは根本的に違う賭けに出ている。Tower BFT は PBFT の変種で、バリデータの投票が *検証可能なクロック* (PoH — SHA256 のハッシュチェーンで構成された決定論的なタイムライン) にアンカーされる。バリデータは「先に時間に合意してから投票する」のではない; PoH そのものが時間であり、投票はその上の点を参照する。結果: ファイナリティ ~400ms (Ethereum の ~13 分に対して)、ただしバリデータのハードウェア要求がずっと高く、スロットごとに単一リーダーモデルになる (スロットごとの委員会なし、約 100 万バリデータプールなし)。Gasper はスケールでの permissionless なバリデータ参加のためにレイテンシを犠牲にする; Tower BFT はバリデータプールのサイズをエンドユーザのレイテンシのために犠牲にする。どちらも有効な BFT の答えで、選択はチェーンが何を最適化するか — 開かれた参加 vs サブ秒ファイナリティ — に従う。`,
                 },
                 {
                   title: 'HotStuff と HyperBFT — 単一リーダー BFT 系統',

prisma/seed-reth-p2p-networking-en.ts

@@ -141,7 +141,9 @@ For Hyperliquid: their custom transport (HyperBFT communication) is **separate f
 2. Browse reth's [\`crates/net/network\`](https://github.com/paradigmxyz/reth/tree/main/crates/net/network) — find the entry point
 3. Identify: how would you add a custom sub-protocol for payment-specific gossip?
 
-> Final check: in one sentence, what's the bootstrapping problem solved by **bootnodes**? **If your answer doesn't reference "peers need peers to find peers," re-read §1.**`,
+> Final check: in one sentence, what's the bootstrapping problem solved by **bootnodes**? **If your answer doesn't reference "peers need peers to find peers," re-read §1.**
+
+> 🛣️ **The road not taken (Solana):** Solana's block propagation is **Turbine** — a tree-based broadcast protocol, not gossip. The leader splits each block into *shreds* (small packets) and propagates them via a deterministic peer tree: each shred reaches every validator in roughly O(log N) hops, vs devp2p's O(N) gossip flooding. The result: dramatically lower bandwidth waste per block, but the design assumes every validator has near-symmetric high-bandwidth connectivity. devp2p's gossip wastes bandwidth (every validator receives each tx multiple times) but tolerates wildly heterogeneous network conditions and adversarial peers gracefully. Turbine optimizes for *throughput-at-scale with good peers*; devp2p optimizes for *survivability with bad peers*. Both are valid network-layer choices; the choice tracks what kind of validator network the chain is willing to require.`,
                 },
                 {
                   title: "Reading reth's network crate",

prisma/seed-reth-p2p-networking-ja.ts

@@ -141,7 +141,9 @@ Hyperliquid の場合、独自の transport (HyperBFT 通信) は **execution 
 2. Reth の [\`crates/net/network\`](https://github.com/paradigmxyz/reth/tree/main/crates/net/network) をブラウズし、エントリポイントを見つける
 3. 自分の言葉でまとめる: 決済固有 gossip 用のカスタムサブプロトコルをどう追加するか?
 
-> 最終チェック: 一文で答えてみる。**bootnode** が解決する bootstrapping 問題とは何か? **答えに「peer を見つけるには peer が必要」というジレンマが含まれていなければ、§1 を読み直す**。`,
+> 最終チェック: 一文で答えてみる。**bootnode** が解決する bootstrapping 問題とは何か? **答えに「peer を見つけるには peer が必要」というジレンマが含まれていなければ、§1 を読み直す**。
+
+> 🛣️ **もう一つの道 (Solana):** Solana のブロック伝播は **Turbine** — gossip ではなく、ツリー型のブロードキャストプロトコル。リーダーが各ブロックを *shred* (小さなパケット) に分割し、決定論的なピアツリー経由で伝播する: 各 shred は devp2p の O(N) の gossip flooding ではなく、おおむね O(log N) ホップで全バリデータに到達する。結果: ブロックあたりの帯域浪費が大幅に下がるが、前提として全バリデータがほぼ対称的な高帯域接続を持つ必要がある。devp2p の gossip は帯域を浪費する (各バリデータが各 tx を複数回受信する) が、非対称なネットワーク状況や敵対的なピアにも優雅に耐える。Turbine は *良いピアでの規模あるスループット* を最適化する; devp2p は *悪いピアでも生き残ること* を最適化する。どちらもネットワーク層の有効な選択で、選択はチェーンがどんなバリデータネットワークを要求できるかに従う。`,
                 },
                 {
                   title: 'Reth の network crate を読む',