コンセンサス ― リーダーとバリデータ、Tower BFT

導入

PoH によって「出来事の順序」を記録できるようになっても、「その記録を誰が作り、誰がそれを正しいと認めるか」というルールがなければ、ネットワークとして機能しません。ここで登場するのが Solana のコンセンサス（合意形成）の仕組みです。

説明

Solana のネットワークには2種類の役割があります。

• リーダー（ジェネレータ）: 送られてきた取引を順序付け、PoH 列を実際に生成するノード。1つのクラスタで、ある短い時間帯だけリーダーを務めます。
• バリデータ（ベリファイア）: リーダーが作った PoH 列と取引の記録を受け取り、複製・検証するノード。

flowchart LR
    L["リーダー<br/>取引を順序付けてPoH列を生成"] -->|ブロックを配布| V1["バリデータ1<br/>検証・複製"]
    L -->|ブロックを配布| V2["バリデータ2<br/>検証・複製"]
    L -->|ブロックを配布| V3["バリデータ3<br/>検証・複製"]

リーダーは固定ではなく、あらかじめ決まったスケジュールに従って、バリデータの間で輪番制に交代します。これは「1台のノードにずっと権限が集中する」状況を避けるための設計です。

PoH 列という共有の「時計」があることで、バリデータどうしは「今どの取引がどの順番で確定しつつあるか」を、いちいち細かくメッセージをやり取りしなくても把握できます。これが、前の章で触れた「時刻合意にかかる通信コスト」を大きく減らしている部分です。

そのうえで、Solana は Proof of Stake（PoS。SOL を多く預けている＝ステークしているバリデータほど、ブロックを検証する重みが大きい方式）をベースにした Tower BFT という合意アルゴリズムを使っています。Tower BFT は、PBFT（Practical Byzantine Fault Tolerance。一部のノードが不正・故障していても、多数決的に正しい結果へ合意できるアルゴリズムの系譜）の一種で、PoH という共通の時計を前提にしている点が特徴です。バリデータは各ブロックに「投票（このブロックを正しいと認める）」をしますが、一度投票すると、その投票を撤回できない期間（ロックアウト）が設定されます。このロックアウト期間は、同じチェーンに続けて投票するたびに倍々に伸びていきます。これにより、バリデータが後から気まぐれに違うチェーンへ乗り換える（＝合意を覆す）ことに強いペナルティが働き、ネットワーク全体の合意が素早く安定します。

ここで、コンセンサスアルゴリズムの大分類にも触れておきます。ビットコインに代表される Proof of Work（PoW）は、大量の計算競争（マイニング）に勝ったノードがブロックを作る権利を得る方式で、大きな電力消費が課題視されてきました。Proof of Stake は、計算競争の代わりに「どれだけの資産をネットワークに預けているか」で権利を割り当てる方式で、消費電力を大きく抑えられます。Solana の Tower BFT は、この PoS の考え方に、PoH という時計を組み合わせたものだと理解しておくとよいでしょう。

演習

PoW と PoS、それぞれでブロックを作る権利はどうやって決まるでしょうか。また、Tower BFT における「ロックアウトが倍々に伸びる」仕組みは、バリデータのどんな行動を抑止するためのものか考えてみましょう。