レッスン6 — bera-reth を読む（PoL をコンセンサスカスタマイズとして）
問い
「うちは違うコンセンサスを使っている」というピッチの大半は、結局トークン名を変えただけの PoS に落ち着く。Berachain の Proof-of-Liquidity（PoL）は珍しい例外で、誰が検証できるか、報酬がどこに流れるかを実際に変えている。そして実装 — berachain/bera-reth — は本番で動いており、Reth 上にあって、差分は半日あれば読み切れる。
原理（最小モデル）
- PoL は PoS の派生. Validator set / Slashing / BFT finality / 経済モデルの骨格は PoS と同じ。変わるのは ① バリデータ適格性（LP ベース）、② 報酬の流れ（LP に戻る）、③ ブロック時間（~2s）。
- bera-reth のカスタマイズは 4 ディレクトリ.
consensus/（trait 実装）+evm/（PoL precompile）+chainspec/（fork heights、genesis）+node/（NodeBuilder 配線）。 - 完全カスタム L1 = ~2000 行のカスタマイズ. Tendermint 系コンセンサスエンジンが揃っていれば、仕事の大半はプロトコル再実装ではなく 統合。
- 同じパターンが Tempo にも効く.
tempoxyz/tempoは公開済み、tempoxyz/rethは upstream に対して 0 commits ahead — fork せず合成。
具体例
bera-reth のディレクトリ構造:
bera-reth/
├── consensus/ ← カスタムコンセンサス impl
├── chainspec/ ← Berachain mainnet/testnet 仕様
├── evm/ ← カスタム EVM config + precompile
├── node/ ← NodeBuilder 配線
└── rpc/ ← bera_* RPC namespace
各ディレクトリの責務:
| ディレクトリ | 何を書くか | 規模 |
|---|---|---|
| consensus/ | Consensus 実装、proposer 検証、署名方式 | ~500 行 |
| evm/ | 報酬分配 precompile、Validator registry precompile | ~600 行 |
| chainspec/ | fork heights、genesis、precompile アドレス、base fee | ~300 行 |
| node/ | 上 3 つを NodeBuilder に配線 | ~200 行 |
| rpc/ | bera_* namespace（pol_、validator_） | ~400 行 |
PoS vs PoL の差分:
| 機能 | PoS | PoL | 同じ？ |
|---|---|---|---|
| 有界 validator set | あり（~100 万） | あり（~100） | 構造同じ |
| Double-sign に対する slashing | あり | あり | 同じ |
| Finality gadget | Casper FFG | CometBFT 系 | 違うエンジン |
| ブロック時間 | 12s | ~2s | 違う |
| トークンモデル | 単一（ETH） | 二重（BGT + Bera） | 違う |
失敗例（誤解）
「PoL は新コンセンサス系統」— 間違い。PoL は PoS にひねりを加えたもの。BFT finality + slashing + validator set のコア構造は同じ。変わるのは経済層と適格性ゲート。
「Reth を fork する必要がある」— 間違い。tempoxyz/reth は upstream に 0 commits ahead = fork せず合成。bera-reth はカスタム実装を別 crate に置いて NodeBuilder で配線する設計。
🛑 予測。 Ethereum PoS では 32 ETH をステークすることでバリデータになる。Berachain の PoL ではそれに相当するステップは何か？（ヒント: 「BGT をステーク」ではない。）（答え: ① BEX に流動性を提供 → BGT を獲得、② BGT をステーク → バリデータ特権。BGT は譲渡不能なガバナンス資産で、唯一の入手経路が LP。バリデータ経済が DEX 流動性に整合する設計。）
ステップで組み立てる
Step 1: 4 ディレクトリの責務を即答できる
consensus / evm / chainspec / node + rpc。各 ~200-600 行。
Step 2: PoL ↔ PoS の差分 3 つを言える
- バリデータになれる人（LP ベースのゲート）
- 報酬の流れ（ステークだけでなく LP に戻る）
- ブロック時間（~2s）
Step 3: 自分の L1 への落とし込み
| bera-reth の部品 | 自分の L1 で書き換えるもの |
|---|---|
| TempoConsensus impl | 自分の validator set ルールに置き換え |
| Executor pre-execution hook | PoL hook → 自分のビジネスロジック |
| NodeBuilder 配線 | 自分のコンポーネントに |
| chainspec | 自分の genesis / fork / precompile |
骨格は bera-reth テンプレート。
Step 4: リポで読む順序
bera-reth/consensus/src/lib.rs—Consensus実装bera-reth/node/src/lib.rs— NodeBuilder への配線bera-reth/chainspec/src/lib.rs— どのプロトコルパラメータに依存するかbera-reth/evm/src/lib.rs— このコンセンサスの下で走る executor hook
各ファイル <500 行。
答え合わせ
- bera-reth が vanilla Reth より持っているもの: コンセンサス固有のコードパス（PoL バリデータ適格性、報酬分配 precompile、BLS 集約署名検証、~2s ブロック向け base fee パラメータ）。「ただの config 差分」ではない。
- Tempo / Hyperliquid 出荷の道筋: bera-reth テンプレート → 自分の validator set ルール + executor hook + NodeBuilder 配線 + chainspec。~2000 行のカスタム実装で完走可能（Tendermint 系エンジンは Malachite を使う前提）。
- fork せず合成の意味: tempoxyz/reth = upstream に 0 commits ahead = upstream の進化を自動で取り込める。カスタム L1 = カスタム crate の集合 + 配線。
合格基準
- bera-reth の 4 ディレクトリの責務を即答できる。
- PoL ↔ PoS の差分 3 つを 1 文で言える。
- 「カスタム L1 ≒ Reth へのカスタマイズ ~2000 行」を 1 文で説明できる。
- リポを開いて consensus → node → chainspec → evm の順で読める。
まとめ（3行）
- PoL = PoS にバリデータ適格性ゲート + 報酬流の変更 + 高速ブロック時間を加えた派生（コア構造は同じ）。
- bera-reth の 4 ディレクトリ（consensus / evm / chainspec / node）が「Reth 上のカスタム L1 」のテンプレート、~2000 行。
- fork せず合成（upstream に 0 commits ahead）+ カスタム crate の集合 + NodeBuilder 配線 = 自分の L1 chain。