レッスン0 — OpenHL を自作する（cargo init → single-validator devnet）

問い

Hyperliquid 型の chain を Rust でゼロから作るとき、最初に到達すべき「動く核」はどこか？ そして、それを 読んで理解する のではなく 自分で組み上げる には何が要るか？

注: OpenHL コースのコードブロックは原則として手元で実行可能な形で示す。ただし <file> などのプレースホルダや答え合わせ用コマンドは、各レッスンの指示に従って置換してから実行すること。

原理（最小モデル）

これは「読む」コースではなく「作る」コースだ。3 つだけ掴めばいい。

• 2 つのディレクトリ。 ~/code/my-openhl/（自分で 1 行ずつ書く本番 workspace）と ~/code/openhl-reference/（psyto/openhl の clone = 答え合わせの鏡、read-only）。編集は必ず my-openhl 側。
• 30秒 BFT primer。 BFT consensus は round の繰り返し。各 round は propose（proposer がブロック提案を broadcast）→ prevote（全 validator が投票）→ precommit（投票を lock）。≥ 2/3 が precommit したら decided（確定）。proposer は validator set から決定論的に選ばれる。Malachite がこの state machine を Rust で駆動する。
• 到達点は 1 つのテスト。 レッスン15 まで来ると cargo test first_block_via_engine_actors が ~0.02 秒で pass する。EVM 層は実 Reth、BFT 層は実 Malachite。chain は CL（Consensus Layer） と EL（Execution Layer） の 2 層で、本コースで両側を bridge contract で接続する。

propose / prevote / precommit / decided / proposer — この 5 語を頭に入れれば以降の語彙がクリーンに着地する。

具体例

レッスン15 時点のコードパス。各行すべて自分が書いたコードで、マジックはない。

自分のコード →
  Malachite Driver →
    proposer election →
      build_payload (自分が書いた bridge) →
        Reth dev-node provider →
          header 構築 →
            EthBeaconConsensus validator →
              validate_payload →
                forkchoice_updated →
                  decided block

失敗例（誤解）

「openhl-reference を直接編集すれば早い」は誤り。reference は答え合わせ専用。ここに書くと、どこまでが自分の実装か追えなくなり、自分のコードと借り物の境界が消える。編集は必ず my-openhl/ 側で行う。

ここまでで「2 ディレクトリ・BFT の骨格・到達点」は着地した。ここから先はセットアップ実行・スコープ・16レッスンの地図に入る。

🛑 セルフチェック。 次に進む前に 1 文で言えるか：~/code/my-openhl と ~/code/openhl-reference の役割の違い。言えなければ下の「セットアップ」を読み直す。曖昧なまま走ると、後半で reference 側にうっかり書いて境界が消える事故が起きる。

セットアップ（いま実行する）

# 自分の workspace
mkdir -p ~/code/my-openhl && cd ~/code/my-openhl
cargo init --lib
# (root パッケージ名はレッスン1 で workspace 化する際に消える。ここでは初期 commit を取るだけ)

# reference と同じ toolchain を強制
echo -e '[toolchain]\nchannel = "1.95.0"' > rust-toolchain.toml

# 答え合わせ用リファレンス
mkdir -p ~/code && cd ~/code
git clone https://github.com/psyto/openhl.git openhl-reference
cd openhl-reference
cargo check  # 初回は時間がかかる — Reth は大きい

reference 側で cargo check が pass すれば toolchain は正しい。

スコープ — 作るもの / まだ作らないもの

本コースは OpenHL 実装のステップ1（コンセンサス基盤）のみ。扱わない: ステップ2 CLOB / ステップ3 EVM precompile / ステップ4 funding・oracle・liquidation / ステップ5 vault。これらは後続コース。本コース修了時に手に入るのは BFT と EVM を接続した最小コンセンサス基盤 で、動く perp DEX はまだ完成しない（ステップ2〜5 を積んで成立する）。スコープを正直に区切るための線引きだ。

16 レッスンの地図

各レッスンは pass する cargo test で終わる。

レッスン10 が最大の milestone — actor system 経由で BFT が end-to-end でブロックを 1 つ生成する。11〜14 で stub Reth を実 Reth に差し替え、commit を Engine API へ接続する。

前提知識

必要: Rust 1.95+ / Git / Cargo workspace・async/await・trait impl の基本（#[async_trait] や impl Trait for Foo が未知なら本コースは速すぎる — 先に Fundamentals/Advanced へ）/ Rust 対応エディタ / ~4GB の空きディスク。不要: consensus・Reth・Malachite の事前知識（進めながら学ぶ）/ マルチマシン環境（全て 1 プロセス）。

合格基準

rustc --version                                   # 1.95.x 以降
ls ~/code/my-openhl                               # Cargo.toml, src/
cd ~/code/openhl-reference && cargo check         # Finished

3 つ pass すればセットアップ完了。

まとめ（3行）

• これは「作る」コース。my-openhl に自分で書き、openhl-reference で答え合わせする（reference は編集しない）。
• BFT round = propose → prevote → precommit → decided。Malachite が駆動、自分は Context 経由で配線する。
• ゴールは first_block_via_engine_actors（CL=Malachite / EL=実 Reth）。本コースはステップ1 のみ、perp DEX はまだ完成しない。