レッスン0 — Ethereum を systems engineering として読む — 必要なメンタルモデル

問い

多くの Ethereum 入門は Ethereum を 独立した特別世界 として扱う。dapp チュートリアルにはこれで十分だが、Reth・Revm・Alloy のソース読解には弱い。このカリキュラムが必要とする捉え方は: Ethereum = データベース + 分散システム + コンパイラ + ネットワーク + 並行処理ランタイム を コンセンサスで束ねた合成物。

原理（最小モデル）

• 5 サブシステム. データベース（MDBX = B+tree、reth-mdbx）/ 分散システム（コンセンサス + P2P 同期）/ コンパイラ・VM（revm / revmc）/ ネットワーク（reth-network devp2p）/ 並行処理ランタイム（Tokio）。
• 各分野は数十年の文献を持つ. バグクラス（競合状態 / DB デッドロック / TCP バックプレッシャー / JIT 誤り）は Ethereum 固有でない、見つけ方と直し方も同じ。
• スキルは複利で効く. MDBX → Snowflake / PlanetScale / Neon、Tokio → Cloudflare / Discord / AWS、revm インタープリタ → TigerBeetle / 言語ランタイム全般。Ethereum 固有知識は 上乗せ、systems 基礎が土台という順序。
• 退けるべき「魔法」. 「スマートコントラクトは特別」（違う、VM 上のプログラム）/ 「state は特別」（違う、スナップショット付き KV）/ 「コンセンサスは特別」（違う、既知 trade-off アルゴリズム）/ 「ガスは特別」（違う、計測付きリソース予算）。
• ソース読解への効き方. reth-mdbx の B+tree → SQLite 系設計、revm の 256 関数ポインタテーブル → CPython / JVM 設計、ピア評価 → BGP 由来、Ethereum 固有の奇妙さでなく 既知 systems パターンの応用 として読む。

具体例 + ステップで組み立てる

Ethereum を systems engineering として読む — 必要なメンタルモデル

多くの Ethereum 入門は、Ethereum を 独立した特別世界 として扱う。ブロックチェーンの魔法や業界固有語彙を並べるこの捉え方は dapp チュートリアルには有効だが、Reth・Revm・Alloy のソース読解には弱い。

このカリキュラムに必要な捉え方は次である。Ethereum は、データベース + 分散システム + コンパイラ + ネットワーク + 並行処理ランタイムを、コンセンサスで束ねたもの。 各部品は数十年の文献を持つ systems engineering の問題であり、「ブロックチェーン」は接着剤であって本質ではない。

この一枚の絵を持ち歩く。続く Reth / Revm / Alloy のレッスンは、既知の何かの上に着地する。

1. 5 つのサブシステム

Reth のソースツリーは、5つの systems engineering 分野にきれいに分解できる。

過去の現場で見たバグクラス（競合状態、DBデッドロック、TCPバックプレッシャー、JIT誤り）は、Ethereumでもそのまま起きる。Reth CI が捕まえるのも、コンパクション停滞、reorg競合、opcode価格付けバグ、ピア排除攻撃、高負荷時タスク餓死である。バグ種別は Ethereum 固有ではない。 見つけ方と直し方も同じである。

2. なぜソース読みでこの捉え方が効くか

reth-mdbx で「コピーオンライトページ + MVCC スナップショットの B+tree」を見たら、それは 50年級文献を背負ったDB設計 と認識するべきである。「Ethereum が奇妙に状態保存している」のではない。Reth が MDBX を選ぶ理由は SQLite が類似設計を選ぶ理由と同じで、重書き込み下の読み取り安定性、耐クラッシュ性、組み込みやすさにある。

revm で「スタックベースインタープリターが 256 関数ポインタテーブルでディスパッチする」設計を見ても、それは 1980年代CPython / 1990年代JVM から続くVM設計 であり、EVM固有の奇妙さではない。素朴な match より速い理由も、他インタープリターが計算gotoや関数ポインタテーブルを使う理由と同じである。

reth-network で「悪い振る舞いで切断するピア評価」を見たら、それは BGP 時代から続く分散システムパターン である。「Ethereum 固有のアンチDoS」ではない。

この捉え直しは広く効く。続くレッスンで逐一「OSスケジューリング理論の応用」とは書かないが、読み手がこの前提を持つことを想定して書かれている。

3. スキルが複利で効く

Ethereum は、よく研究されたシステムの合成である。だからこそ、ここで身につけるスキルは 業界をまたいで複利で効く。

Solidity しか読めない「Ethereumエンジニア」は市場が狭い。一方、Ethereum を専門にした systems エンジニアは、systems engineering 求人市場全体を退路として確保しつつ、Ethereum 専門家としての上乗せも取れる。

仮に Ethereum 業界が伸びなくても、MDBX・Tokio・本物の分散システムで ship した経験を持つ Rust エンジニアは、TigerBeetle、Cloudflare、Discord、PlanetScale、Neon などインフラ職への選択肢が広い。Ethereum 固有知識は上乗せで、systems 基礎スキルが土台という順序が成立する点が強い。

つまり Reth への賭けは、本当は Ethereum への賭けではありません。systems engineering という分野への賭け で、Ethereum はその応用先のうち特に面白く、特に報酬の大きい一例にすぎません。

4. 退けるべき「魔法」の言い回し

以下の枠付けに出会ったら、能動的に押し返す。

• 「スマートコントラクトは特別」 — 違う。VM上で走るプログラムであり、VMが決定的でガス計測付きなだけである。
• 「状態 (state) は特別」 — 違う。スナップショット付きキー・バリュー・ストアである。
• 「コンセンサスは特別」 — 違う。レイテンシ・ライブネス・スループットの既知トレードオフを持つアルゴリズムである。
• 「ガスは特別」 — 違う。計測付きリソース予算である。

続くレッスンは、この置き換えを済ませた前提で書かれる。「EVM」「state」「コンセンサス」という語は文献準拠で使うが、一般的 systems engineering 問題の具体例 として扱い、Ethereum 固有の魔法としては扱わない。

次に来るもの

これがレッスン0、全体の捉え方である。レッスン1では、Ethereum を一般的 systems engineering から区別する4つの力を名指しして、この枠を鋭くする。Module 0 残りでは、各プロジェクト（Reth・Revm・Alloy）がどのサブシステムを実装するか、なぜ Geth / ethers-rs / Solana ではなくこのスタックを選ぶか、Solidity / Solana 経験をどう持ち越すかを埋める。Module 0 後は Rust をセットアップし、ソースを読み始める。

ひとつだけ持って歩く。「ブロックチェーン」「state」「コンセンサス」「ガス」という語が出たら、頭の中で systems engineering の等価物に置き換える。レッスンはその前提で書かれる。この捉え方こそがソース読解の鍵である。

まとめ（3行）

• Ethereum = DB + 分散システム + コンパイラ + ネットワーク + 並行処理 をコンセンサスで束ねた合成物、5 サブシステム + 既知 systems 文献 + 共通バグクラス。
• Reth への賭けは Ethereum でなく systems engineering 分野 への賭け、MDBX / Tokio / 分散システム / プロファイリングが業界横断で複利。
• 「ブロックチェーン特別世界」枠を退け、既知 systems パターンの応用として読む準備、次レッスンで Ethereum を Ethereum たらしめる 4 つの力。