Cardano の次の処理能力拡張 Leios の試作版「prototype-2026w40」が、日本時間 10 月 5 日朝に IOG（Input Output）の GitHub で公開されました。Anastasia Labs の監査で指摘された 3 件（LEI-004・005・009）を解消し、エンドーサーブロックの取引の保存の仕方を変えたリリースで、動かすにはノードのデータベースを消して同期し直す必要があります。
Leios 試作版 2026w40 のリリースノート（GitHub）（GitHub）
リリースノートは自らを「内部の変更が中心の小さなリリース」と書いています。ただ、中身を読むと、ノードが他のノードから受け取るデータをどこまで信じるかという、本番に近づくほど重くなる部分に手が入っています。10 月 1 日の Deep Dive では Leios の性能を SPO の設備から読みましたが、今回はノードの守りの側です。変更点、監査の 3 件、試作版を動かしている運用者の手順を順に整理します。
10 月 1 日の Deep Dive: Leiosを動かすのは、誰のマシンか（2026年10月1日）
取引の保存を、エンドーサーブロックごとに
Leios では、通常のブロック（Praos のブロック）のヘッダーで告知される形で、取引の束を別に運ぶ「エンドーサーブロック」が加わります。ノードはこの束に含まれる取引を、Leios 用のデータベース（LeiosDb）に保存しています。
w40 では、その保存の単位が、取引のハッシュごとからエンドーサーブロックごとに変わりました。リリースノートが挙げる効果は次のとおりです。
- エンドーサーブロックの保存が順番どおりの書き込みになり、破棄も 1 回の削除で済む。データベースがチェーンの選択に追いつきやすくなる
- 複数のエンドーサーブロックが同じ取引を参照する場合、取引はブロックごとに保存される。ディスクの容量を使うかわりに、書き込みを軽くする設計
- すでに手元にある取引を後のエンドーサーブロックが参照したときは、もう一度ダウンロードせずに使い回す
- 書き込みの途中で送り手のノードが切断しても、そのエンドーサーブロックが、持っているのに取り出せない状態で取り残されない
容量と速さの交換を、速さの側に倒した変更です。Leios はブロックの外で大量の取引を運ぶ設計なので、書き込みが追いつかなければ、そのままノード全体の遅れになります。9 月の w38・w39 でもデータベースの書き込みの競合を直しており、ここ数週はこの部分の手直しが続いています。
監査の 3 件は、受け取ったデータの長さと件数
修正のプルリクエスト（ouroboros-consensus #2358）は、Leios の追跡用 issue #1125 を閉じるものとして出されています。issue に書かれた 3 件の題名は次のとおりです。
- LEI-004: 信頼できない取引のハッシュが、検査なしに固定長のキャッシュへ届く
- LEI-005: 取り込みの入口で、Leios の本体のサイズ上限が守られていない
- LEI-009: CBOR の要素数の申告が、検証の前にメモリの確保を決めてしまう
どれも、他のノードが送ってきた値を確かめる前に使ってしまう点への指摘です。一般に、相手が申告した件数をそのまま信じて先にメモリを確保するノードは、大きな数を申告するだけで資源を使い切らせることができます。w40 のリリースノートは、この点を「ノードが確かめていない申告で、相手がメモリを確保させることはもうできない」と書いています。
具体的な修正は 4 つです。取引とエンドーサーブロックのハッシュは 32 バイトに固定され、それ以外の長さは保存せずに拒否します。相手が申告する件数は、すべてメモリを確保する前に検査します。頼んだ件数と食い違う返事や、空・範囲外・重複した番号を含む要求も拒否します。古いビルドが書いたデータベースに不正な長さのハッシュが残っていた場合は、読み飛ばさずに原因を名指しする例外で止まります。
プルリクエストは互換性の注意も添えています。ヘッダーの中のエンドーサーブロックのハッシュが 32 バイトでない場合、新しいノードは読み込みませんが、古いノードは受け入れます。正しく動くブロック生成者は必ず 32 バイトで作るため、版の混ざったネットワークで分岐が起きうるのは、悪意のあるリーダーがいる場合だけだという説明です。
なお、日本時間 10 月 6 日昼の時点で issue #1125 は開いたままです。修正はマージされ、リリースにも入っていますが、追跡の issue を閉じる作業は別に残っています。
試作版を動かしている運用者がすること
w40 は LeiosDb の構造が変わり、移行の仕組みがありません。既存のデータベースのまま起動すると、ノードはすぐに「no such table: ebTxBytes」というエラーで止まります。リリースノートの手順は次のとおりです。
- チェーンのデータベースと、leios.vol.db・leios.imm.db の 2 つのファイルを消す
- ジェネシスから同期し直すか、IOG のリレーから取り込む（サイドロード）
Leios 用の 2 ファイルだけを消すのでは足りません。認証済みのブロックをすでに持つチェーンが残っていると、その中身を解決できずに止まります。9 月の w38 で起きたのと同じ失敗だと、リリースノートは書いています。
一方で、ノード同士の通信の形式は変わっていません。w39 と w40 のノードはそのまま通信できるため、試験ネットワーク全体を作り直す必要はないとしています。データベースの作り直しが必要だったのは w38 と今回で、間の w39 は不要でした。いずれも試作版を動かしている参加者向けの手順で、メインネットで動いている Cardano のノードには関わりません。
次に見るもの
確認先は、ouroboros-leios の GitHub のリリースページと issue #1125 の 2 つです。
- 次の試作版（w41）のリリースノート: 9 月以降はほぼ毎週出ています。今回の保存方式の変更で増えるディスクの使用量や、同期の速さについての記述が出てくるか
- issue #1125 の閉じ方と、監査の残りの番号: 今回の 3 件は少なくとも LEI-009 まで番号が振られた指摘のうちの一部です。他の番号がリリースノートに出てくるかで、監査の対応がどこまで進んだかが見えてきます
ことば
- エンドーサーブロック（EB） — Leios で加わる、取引の束を運ぶブロック。通常のブロックのヘッダーで告知され、委員会の投票で認証されたものがチェーンに取り込まれます。今回の変更は、この束をノードがどう保存するかの話です。
- ステートワイプ — ノードが持つデータベースを消して、一から同期し直すこと。データの構造が変わり、古い形式から移す仕組みが用意されていない試作版で求められます。
- CBOR — Cardano のノード同士がデータをやり取りするときの符号化の形式。要素の数を先に申告する書き方ができるため、その数を確かめずに使うと今回のような指摘につながります。
一次ソース / 関連リンク
