Leiosを動かすのは、誰のマシンか

SPO向け実機ベンチが問う、SSD・メモリと検証条件

Leiosの性能を読むうえで、新しい材料が出ました。開発チームが取引検証のベンチマークをSPOへ配布し、それぞれの設備で確かめる段階へ進んだという報告です。何を測り、何はまだ分からないのか。二つのデータベースの役割を整理し、設備と運用の違いを含めて性能を評価するための確認点を追います。

9月30日のPerformance & Tracingチーム報告は、オンディスクLedgerDBの取引検証ベンチマークを、単体で配布できる実行ファイルにしてSPOへ届けたと説明しています。NixやHaskellの開発環境を用意せず、運営者自身の機器で測れる形です。[1]

ここから問えるのは、「どの設備なら、どの条件で検証を終えられるか」です。SPO（ステークプール運営者）には将来の設備判断、委任者には運営を続けられるプールの広がり、DRepには開発成果を評価する根拠に関わります。実機から集まるデータには、性能と参加のしやすさを一緒に考える役割があります。

1．測っているのは、取引を検証する力です

まず、今回のベンチマークが測る範囲を押さえます。元の開発課題であるLeios issue #553は、実際の台帳実装を評価するための試験と位置づけ、実ネットワークにおける取引やブロックの伝播を対象から外しています。[2]

したがって、ある機器で取引検証が短時間に終わっても、それだけでLeiosネットワーク全体のTPSは求められません。別のノードへデータを届け、必要な検証と投票を済ませ、台帳へ反映するまでには、さらに工程があります。[3] 利用者が待つ時間と、台帳処理の一部分にかかった時間は、測定の始点と終点が違います。

この切り分けは、試験の価値を小さくしません。全体の処理が遅れたとき、計算、記憶装置、通信のどこを調べるべきかを絞るために、部分ごとの測定が必要になります。単体試験は原因を調べるための材料になり、統合試験ではそれらを組み合わせて確かめられます。

Leiosの技術設計も、大きなEndorser Block（EB）に含まれる取引を、与えられた時間内に検証できるかを台帳ベンチの目的に挙げています。[3] 見るべきなのは処理した件数に加え、その仕事を期限までに終えられる余裕です。

2．ディスクを読む時間が、検証の時間に入ってきます

LedgerDBは、取引の検証や適用に必要な台帳状態を扱います。オンディスク方式では、UTxOなどの台帳データを記憶装置から取り出す処理が関わります。技術設計は、メモリ使用量の制御と引き換えに、ディスクI/Oと台帳状態へのアクセス時間が重要になると説明しています。[3]

CPUが同じでも、測定結果が同じになるとは限りません。9月30日報告が幅広い構成を求める理由には、SSDと接続方式、カーネル、ファイルシステム、マウント設定の違いが挙げられています。[1] 「メモリを何GB積んだか」だけでは、再現に必要な情報が足りなくなります。

もう一つ重要なのが、キャッシュです。ディスク上にあるデータでも、直前に読んだ内容がメモリに残っていれば、実際のディスクアクセスは省かれることがあります。同じデータを何度も読む試験と、ディスク読み出しを発生させる試験では、確かめている条件が違います。

この点は測定側でも意識されています。8月28日の公式報告によると、ベンチマークツールbeaconには、OSのページキャッシュを迂回してディスクI/Oを発生させる仕組みが加わり、最大常駐メモリ量、ブロックI/O回数、実経過時間も記録するようになりました。[4]

キャッシュを使う結果にも、使わせない結果にも意味があります。前者だけでは厳しい条件を見落とし、後者だけでは普段の動作を必要以上に厳しく評価する可能性があります。結果には、その数値がどちらの条件で得られたかを添える必要があります。

3．LedgerDBとLeiosDBは、役割が違います

同じ時期の開発報告には、LeiosDBという別の名前も出てきます。台帳状態を扱うLedgerDBと、EBなどLeios固有のデータを扱うLeiosDBは、区別して読む必要があります。[3][5]

9月22日のConsensusチーム報告では、LeiosDBを、まだ巻き戻る可能性のあるデータと確定済みのデータの二つのファイルへ分けたと説明しています。別々のディスクへ配置でき、負荷の高い側に速いディスクを割り当てることもできます。不要データの削除も、対象を印づけする処理と、小分けに削除する処理へ分けられました。[5]

この変更で注目したいのは、保存する量に加え、保存と整理が他の処理へ与える影響を扱っていることです。ノードは新しい仕事を受け付けながら、古いデータを片づけます。整理が一度に集中したときにも処理が続くかは、長時間の運用で確かめたい点になります。

9月25日（UTC、日本時間では26日）公開のプロトタイプw39でも、LeiosDBの競合修正や、メモリプール読み取りのロックフリー化が報告されました。[6] 実装は更新中であり、機器構成だけを揃えても、版が違えば同じ比較にはなりません。

なお、LeiosDBの保存構造の改善を、そのままLedgerDBベンチの高速化実績として扱うことはできません。それぞれの変更が、どの処理時間へ効いたかを確かめる測定が必要です。

4．比較には、数字より先に条件表が要ります

結果が届いたとき、最初に確認したいのは測定条件です。以下は開発チームの公式合格基準ではなく、本稿で提案する読み方です。

中央値は普段の処理を読む助けになりますが、遅い側の分布も必要です。例えばp95やp99は、測定値の95％、99％が収まる位置を示します。ただし、試行数や集計方法が違えば、同じ名前でも比較の意味は変わります。期限を超えた処理を除外して平均を出していないかも確認したいところです。

ソフトウェアを比べるなら、入力と機器の条件を揃える。機器を比べるなら、ソフトウェアと入力を揃える。複数の条件を変えた場合は、原因を一つに決めつけない。この基本が、数値を設備判断へつなげます。

環境の変化は実際の比較にも影響します。9月30日報告では、クラスタ内の通信遅延が5月以降に変わったため、Node 11.0の比較基準を測り直したとしています。また、現在のLeiosプロトタイプを使うクラスタ試験の数値は、代表的な性能を示すものにはならないと明記しています。[1]

5．運用を考えるなら、結果の分布まで見たい

異なるSPOから測定値が集まれば、速い構成の特徴だけでなく、条件によって結果が大きく変わる場所も調べられます。そのためには、成功した結果と同じように、遅延した結果や完走できなかった条件にも意味があります。

もっとも、自主的に参加したSPOの設備が、ネットワーク全体を代表するとは限りません。検証へ参加しやすい高性能機だけが多く集まれば、その集計を一般的な運用環境へ当てはめるには慎重さが要ります。参加数とともに、設備や運用形態がどれだけ広く含まれたかが重要です。

例えば、同じSSDを使っていても、専用機と他の処理を共有する環境では、読み書きを待つ状況が違うかもしれません。短い試験では問題がなくても、長時間ではデータの整理や他の処理と重なるかもしれません。これは今回観測された不具合ではなく、次の試験で比較したい仮説です。

DRepが開発成果を評価する際にも、この区別は役立ちます。「目標の数値に届いた」という報告に、対象の負荷、継続時間、設備の分布、失敗時の条件が添えられれば、成果と残る課題を具体的に議論できます。機器費用を考えるにも、まず何が必要で、何が余裕なのかを知る材料が要ります。

現段階の資料から、必要なSSD性能や費用、小規模SPOへの影響を一律に決めることはできません。処理容量の向上から手数料や収益の変化へ進むには、利用状況など別の根拠も必要になります。

6．いま確認できることと、次に必要なこと

今回確認できた前進は、SPOの手元で測るための配布が報告されたことです。一方、本稿では、その配布物の正式な入手先とハッシュ、参加SPO全体の集計結果を独立に確認できていません。すぐ実行するための案内として読む段階にはありません。

今後の判断では、次の順序で確認すると整理しやすくなります。

• SPO：配布元、対象版、手順、必要な空き容量、運用中のノードへ与える負荷を確認する
• 結果の比較：同じ入力と測定範囲で比べられるか、キャッシュ条件と失敗例まで見る
• 委任者：単発の高い数値に加え、その設備で継続運用できる根拠を読む
• DRep：単体性能、ネットワーク統合、継続運用、費用の各根拠が揃っているかを確かめる

Leiosの実装が進むほど、性能を説明する資料にも具体性が求められます。どの機器で、何を、どれだけの時間に処理したか。そして同じ条件を、別の運営者が確かめられるか。

SPOの実機ベンチマークは、その問いに答える材料を増やす取り組みです。そこで見えてくる設備差や設定差を含めて評価することが、処理能力の拡張を、運営者が参加し続けられるCardanoへ結びつけていきます。

参考・出典

1. Performance & Tracing Update（2026年9月30日）
2. Leios transaction validation benchmark：Issue #553
3. Leios technical design and implementation plan（主に2.1〜2.2、3.4、4.1節）
4. Performance & Tracing Update（2026年8月28日）
5. Consensus Team Update（2026年9月22日）
6. Prototype 2026w39

関連する読み物：Leiosが広げるCardanoの処理能力、Musashi Dojoで見えた現在地（2026年7月16日）

透明性メモ：2026年10月1日に確認した公開一次資料をもとに構成しています。本稿独自のベンチマーク実行やSPO設備での実測は行っていません。確認表と今後の評価観点は編集上の分析であり、公式の最低動作要件や合否基準ではありません。