📡 Signal｜Leiosの「DDoS懸念」——仕様書が書いていること、書いていないこと

7 月 23 日、SundaeSwap が Linear Leios をめぐる DDoS 懸念に技術的な回答を出しました。エンドースメントブロックが破棄されると SPO のリソースが無駄になり、サービス妨害の入口になるのではないか、という指摘に対するものです。

この論点は SPO にとって他人事ではありません。負担するのはノードを動かしている側だからです。そこで CIP-0164 の記述に当たってみました。結論から言うと、仕様書は敵対的な行動にきちんと備えています。ただし今回話題になった部分そのものは、仕様書には書かれていませんでした。

何が問われていたのか

まず Linear Leios の形を確認します。ブロック生成の権利を得たプールは、2 種類のものを同時に作ります。ひとつはランキングブロック（RB）。従来の Praos のブロックを拡張したもので、ヘッダでエンドースメントブロックを予告し、ボディにその証明書を載せられるようになっています。もうひとつがエンドースメントブロック（EB）で、こちらが大量の取引を運びます。

EB は、投票で承認されて初めて有効になります。承認に足る票が集まらなければ、その EB は破棄されます。証明書を載せられる最短の遅延より前に次の RB が作られた場合も、同じく破棄されます。

ここに懸念が生まれます。破棄される EB が増えれば、その検証に費やしたノードの計算資源は何のために使われたのか。意図的にそれを起こせるなら、サービス妨害の手段になるのではないか。指摘はこういう形でした。

SundaeSwap の回答は、次のとおりです。

When a block is dropped, the actual transaction validation work isn’t lost, it simply carries over to the next one.

（ブロックが破棄されても、実際の取引検証の作業は失われません。単に次へ持ち越されるだけです）

仕様書は、別の入口を塞いでいます

CIP-0164 を読むと、敵対的な行動への備えは複数用意されています。ただし、いま挙げた「破棄されたときの持ち越し」とは別の経路です。

ひとつは、二重発行の検知です。ブロック生成の権利を得た者が、内容の異なる EB を複数作ってネットワークの別々の場所に流す、という行為が想定されています。仕様は一定の待ち時間を置くことでこれを検出し、正直なノードが投票を拒否できるようにしています。

ふたつめは、EB ひとつあたりの計算量の上限です。Plutus のステップ数とメモリ使用量に上限が設けられており、検証が時間内に終わることを担保しています。無制限に重い EB を投げ込むことはできません。

みっつめは、証明書を載せられるまでの最短遅延です。予告した RB から一定のスロット数が経つまで証明書は載せられません。攻撃を早回しにできない仕組みです。

加えて、中身のない EB を予告しないこと、同じ選出に対する予告を 2 つを超えて受け付けないこと、といった規定もあります。

つまり仕様書は、「攻撃者が EB の仕組みを悪用する」という問いに対して、悪用の入口を個別に塞ぐ形で答えています。

仕様書自身が挙げている「26%」の例

もうひとつ、仕様書にはっきり書かれていることがあります。認証しきい値をどう設定するかを論じる中で、こういう例が挙げられています。75% の認証しきい値のもとでは、26% の stake を持つ攻撃者が Leios のスループットを容易に攻撃できる、と。

算術としては単純です。承認に 75% を超える賛成が要るなら、26% が黙っているだけで残りは 74% にしかならず、しきい値に届きません。

これは「Leios が壊れている」という話ではありません。しきい値というパラメータをどこに置くかで、攻撃に必要な stake の量が決まる、という設計上のトレードオフです。高くすれば承認の確実性は上がりますが、妨害に必要な stake は下がります。仕様書はそれを隠さずに書いています。

DDoS 懸念に答えるうえで、ここが最も具体的な材料だと考えています。資源の無駄という漠然とした形ではなく、パラメータと必要 stake という測れる形になっているからです。

書かれていないこと

一方で、今回話題になった論点そのものは CIP-0164 に見当たりませんでした。

破棄された EB に含まれていた取引がどうなるのか。mempool に戻るのか。すでに済ませた検証の結果が再利用されるのか。この扱いについて、仕様書は記述していません。

これは矛盾ではありません。仕様書はプロトコルの規定を書くもので、ノード実装が検証結果をどうキャッシュするかは実装側の領分だからです。SundaeSwap の説明も、その実装レベルの話として読むのが自然です。

ただ SPO の立場からは、区別しておく意味があります。仕様で保証されていることは、どの実装でも守られます。実装の工夫であれば、ノードのバージョンや設定によって差が出る可能性があります。テストネットで見るべきなのは、まさにこの部分です。

SPO から見ると、負担と参加は同じ形をしていません

もう一点、仕様書を読んで確認しておきたい箇所があります。

投票する委員会は、エポックごとに決まります。決め方は、アクティブステークの多い順にプールを並べ、累積が設定された目標に達するまでを取る、というものです。そこで区切られ、その集合がそのエポックの委員会になります。

つまり、しきい値より下のプールは投票に参加しません。

一方で、EB の伝播と検証はネットワーク全体で起きます。運用コストについて仕様書は、mempool は RB と EB の取引量の合計の 2 倍以上が要ること、スループット増加に伴ってディスク容量が追加で要ること、大きな stake を持つ側は多数の下流ピアを抱えるぶんリレーの増強が要ることを挙げています。

負担する側と、投票する側は、完全には重なりません。小規模プールにとっての Leios は、この非対称をどう見るかという話になります。

救いもあります。仕様は適応的に設計されていて、トラフィックが少ないときは RB のほうが取り込みが速いため EB は使われません。RB だけで足りる状況では EB は予告されず、運用コストは Praos と同じ水準に戻ります。常時フル稼働の負担がかかり続けるわけではありません。

なお、具体的な必要スペック（6 コア以上、100Mbps 以上、SSD）は CIP ではなく Leios のドキュメント側に書かれている数字です。出所が違うので、分けて見ておくのがよいと思います。

いま見ておきたい点

CIP-0164 のステータスは Proposed です。Leios のドキュメントによれば開発は継続中で、テストネットは 2026 年を目標、メインネットはテストと監査、そして Cardano のガバナンス承認を経た後とされています。

そのうえで、SPO として見ておきたいのは次の点です。

• 認証しきい値が最終的にいくつに決まるか。26% の例が示すとおり、この 1 つの数字が妨害に必要な stake を決めます
• 破棄された EB の取引と検証結果の扱いが、実装でどうなるか。テストネットで実測できる部分です
• 委員会の累積ステーク目標がどこに置かれるか。小規模プールが投票に参加できるかが、ここで決まります
• EB の最大サイズがどう決まるか。ここが小規模 SPO の必要スペックを直接左右します

疑問が公開の場で提起され、公開の場で回答が出る。この往復自体は健全なものだと思います。そのうえで仕様書に当たると、答えの根拠がどこにあり、どこがまだ実装とパラメータ次第なのかが見えてきます。