LIVE ADA-- MCAP-- TVL-- STAKE-- EPOCH--
SIPO
𝕏 🔍
HOME › Deep Dive › 📡Deep Dive｜Leiosが広げるCardanoの処理能力――Musashi Dojoで見えたスループット、決済時間、Linear Leiosの現在地
Deep Dive

📡Deep Dive｜Leiosが広げるCardanoの処理能力――Musashi Dojoで見えたスループット、決済時間、Linear Leiosの現在地

2026-07-16SIPO

先日、SIPOは日本で開かれたOuroboros Leios（ウロボロス・レイオス）のワークショップに参加しました。会場にはLeiosの技術設計と実装を担うセバスチャン・ナーゲル氏も参加し、SPOとの質疑を交えながら、Leiosの仕組み、開発の現在地、Musashi Dojoで進める検証、ノードの運用コストなどを説明しました。

その中で、非常に重要な問いが出ました。

Leiosは、Praosと比べて何を改善するのか。速度なのか、TPSなのか。それとも、ネットワークが処理できる容量なのか。

この問いは、Leiosを理解するうえで核心に当たります。TPS、スループット、キャパシティ、取引の取り込み時間、ファイナリティは、いずれもブロックチェーンの「速さ」を説明するときに使われます。しかし、実際にはそれぞれ別の性能です。ここを混同すると、「Leiosによって一件の決済が何倍も速くなる」という誤解につながります。

ワークショップの内容と、2022年の初期設計文書、現在のCIP-164、2026年6月版の技術設計、シミュレーション資料を照合すると、Leiosが目指しているものは明確です。

Leiosが直接拡張するのは、Cardano L1のスループット容量です。低負荷時の一件を必ず速くするためのプロトコルではありません。

一方で、これはLeiosが決済時間を無視しているという意味でもありません。現在実装されているLinear Leiosは、通常のPraos経路を残しながら、需要が増えたときだけ追加の処理経路を使う設計です。その結果、低負荷時の取引と、高負荷時にEndorser Blockへ入る取引では、取り込みまでの時間が異なります。

本稿では、ワークショップでやや曖昧に感じられた「Leiosは結局、何を速くするのか」を掘り下げます。

なお、本稿はLeiosに対する最終評価を示すものではありません。2026年7月16日時点で公開されている資料とワークショップの説明をもとに、SIPOが調査し、現時点で理解している内容をまとめたものです。Linear Leiosは公開テストネットでの検証が始まった段階にあり、今後の実測、設計変更、パラメータ調整によって、性能値や評価が更新される可能性があります。

セバスチャン・ナーゲル氏とは

セバスチャン・ナーゲル（Sebastian Nagel）氏は、Leiosの技術設計と実装に携わるリード・ソフトウェアエンジニア／アーキテクトです。Leiosの公式技術設計・実装計画にも主要執筆者として名を連ね、ワークショップでは自身がLeiosの技術面を担当していると紹介しました。

Leios以前は、Cardanoのレイヤー2スケーリング技術であるHydraのチームリードを務めました。研究論文からHydra Headのプロトタイプを作り、Cardanoメインネットで利用可能な実装へ育ててきたエンジニアです。関数型プログラミング、分散システム、Haskell、eUTXO台帳、Plutus、cardano-node、形式手法などを専門とし、現在はリヒテンシュタインを拠点に活動しています。

ワークショップでは、Hydraチームへの助言を続けながら、この約1年はLeiosへ軸足を移していることも説明しました。また、Amaru、Dingo、Haskellといった異なるCardano node実装の相互運用を目指す「ノードの多様性」にも関わっています。

Musashi Dojoでは、自身でもブロック生成ノードを立ち上げました。プロトコルを設計する側だけでなく、SPOと同じようにノードを動かす側からも、Leiosの使い勝手と運用上の問題を見ようとしています。

まず区別したい四つの言葉

Leiosについて語る前に、混同されやすい性能指標を整理します。

言葉 意味 Leiosとの関係
キャパシティ（容量） ネットワークが単位時間に持続して処理できる量の上限 Leiosが直接引き上げるもの
スループット 実際に単位時間あたり処理されたデータ量や取引量 需要があれば、拡大した容量の範囲で増える
レイテンシー 一件の取引を送ってから台帳へ入るまでの待ち時間 Leiosの第一目的ではなく、取引経路によっては長くなる
ファイナリティ／決済確度 台帳へ入った取引が覆らないと高い確度で判断できるまでの時間 Leiosではなく、主にPerasが改善する領域

道路にたとえるなら、Leiosは一台ごとの最高速度を引き上げる技術というより、道路の車線を増やす技術です。車線数がキャパシティ、一定時間に実際に通過した車の数がスループット、一台の車が通過するまでの時間がレイテンシーに当たります。

交通量が少なければ、車線を増やしても通過台数は増えません。しかし交通量が増えたとき、車線が少なければ渋滞が伸び続けます。車線を増やすことで、より多くの車を流し、待ち行列の悪化を抑えられます。

短く言えば、LeiosはCardanoを単純に「速くする」というより、まず「太くする」ためのプロトコルです。

TPSから別の目標へ変わったのか

では、Leiosは「TPSを大幅に引き上げる」という従来の方向性から、キャパシティ重視へ方針転換したのでしょうか。

結論は、目標そのものは変わっていません。

TPSはTransactions Per Second、つまり1秒あたりに処理するトランザクション数です。これはスループットを表す一つの指標であり、取引一件の待ち時間を表すものではありません。「TPSが高い」と「一件の取引が早く確定する」は、同じ意味ではないのです。

2022年に公表された初期設計文書は、Leiosの第一の設計目標をブロックチェーンのスループット向上と定めています。具体的には、次の二つが基本指標です。

  • ネットワークが運べるデータ量。bytes/秒、kB/秒などで測る
  • Plutusスクリプトなどを実行できる計算量。CPU実行時間/秒などで測る

TPSは、この二つと平均トランザクションサイズ、スクリプト負荷から計算される派生指標です。初期設計文書自身が挙げる例では、同じ500kB/秒でも、一件が512 bytesなら約1,000 TPSですが、一件が16kBなら約31 TPSにしかなりません。小さく単純な取引だけを使えば、TPSを大きく見せることもできます。

そのため現在のCIP-164では、TPSだけでなく、実際に台帳へ届くトランザクションデータ量をTransaction Bytes/秒、TxkB/秒で測ることを重視しています。

つまり、データと計算の処理容量を引き上げ、その結果として処理可能なTPSも増やすという目標は、初期設計から現在まで一貫しています。

変わったのは研究版からLinear Leiosへの実装方法

目標は同じでも、Leiosの実装方法は大きく変わりました。

初期の研究版Leiosは、Input Block（IB）、Endorser Block（EB）、Ranking Block（RB）という三種類のブロックを独立した段階で生成し、多くの取引を高度に並行処理する構想でした。ネットワーク帯域とCPUをより継続的に使えるため、非常に高いスループットを狙えます。

しかし、この研究版をCardanoの実際の台帳へそのまま導入するには、並行する取引の競合、台帳上の順序、DAppやウォレットへの影響、長い取り込み時間、実装の複雑さなど、未解決の問題が残りました。現在の技術設計も、研究論文の方式は直接実装することを意図したものではなく、Cardano台帳へ当てはめる過程で追加研究が必要な問題が見つかったと説明しています。

そこで現在実装されているのが、CIP-164のLinear Leiosです。

Linear Leiosでは、Input Blockをいったん外し、EBの生成をPraosのブロック生成機会と結び付けました。形式仕様では、取引レベルの並行性を取り除き、Praosブロックの機会ごとに最大一つの大きなEBを生成する方式として整理されています。

これは「TPSを諦めた」という話ではありません。研究版が狙う最大級の並行処理よりも、次の点を優先した実装戦略です。

  • 現実的な期間でcardano-nodeへ実装できること
  • 既存の取引順序や台帳の意味を大きく変えないこと
  • DApp、ウォレット、インデクサへの影響を抑えること
  • Praosのセキュリティ特性を維持すること
  • 十分に大きなスループット向上を段階的に実現すること

したがって、研究版からLinear Leiosへの移行は、目標の変更ではなく、最大性能を狙う研究成果を導入可能なプロトコルへ落とし込むための設計変更と見るのが正確です。

PraosとLeiosはCardanoの「二刀流」

Musashi Dojoの公式サイトは、PraosとLeiosの関係を、宮本武蔵の「二天一流」になぞらえています。より分かりやすく言えば、性質の異なる二本の刀を使う「二刀流」です。

  • 小さく素早く、安全なリズムを守るPraosのRanking Block
  • 多くのトランザクションを運び、SPOの委員会が検証・投票するEndorser Block

PraosをLeiosへ置き換えるのではありません。Praosの通常ブロックを残したまま、需要が増えたときに大きなEBを組み合わせます。

ブロック生成者が通常のRBとともにEBを作成すると、そのヘッダーとトランザクション群がネットワークへ伝播します。委員会に参加するSPOは、EBの内容とデータの可用性を検証して投票します。CIP-164の実行可能なパラメータ例では、投票ステークが75％の閾値へ達すると集約証明書を作成でき、その証明書を後続のRBへ含めることで、EBのトランザクション群が台帳へ入ります。

Leiosは別のチェーンや独立したレイヤー2ではありません。Praosと同じCardano L1の台帳を使い、通常ブロックへ直接収められる量を超えた取引を追加で運びます。

公式サイトが示すMusashi Dojoプログラムの初期目標は、Cardanoのスループット容量を5〜20倍へ引き上げることです。一方、CIP-164のシミュレーションでは、プロトコル・パラメータ次第で約140〜300 TxkB/秒、平均的な取引ならおよそ100〜200 TPS、現行メインネット容量の約4.5 TxkB/秒（4,500 TxB/秒）を基準にすると約30〜65倍に相当する範囲も検討されています。

これらの数字は同じ約束を表すものではありません。Musashi Dojoの5〜20倍は、公開テストネットから最初の導入へ向けて検証する初期目標です。CIPの30〜65倍は、特定のパラメータとシミュレーション条件から得られた、より広い性能範囲です。取引サイズとPlutus負荷が違えばTPS換算も変わるため、一つの「最大TPS」だけをLeiosの性能として固定するべきではありません。

すべての取引が45〜60秒になるわけではない

ここが、Leiosの決済時間を理解するうえで最も重要な点です。

現行のCIP-164には、低負荷時はレイテンシーの短いRBを自然に優先し、RBだけで処理できる間はEBを告知しないというAdaptive EB productionの考え方があります。

取引の流れは、負荷によって次のように変わります。

ネットワークの状態 主な取引経路 利用者から見た意味
低負荷 通常のRB 現在のPraosに近い取り込み時間。EBを使わない
RBの容量を超える需要 RBに入らない追加分をEBへ 投票と証明書作成のため、EB取引には追加の待ち時間が生じる
従来のPraos容量を超える高負荷 RBとEBを併用 一件ごとの追加遅延を受け入れながら、大量の取引を流して待ち行列を抑える
Leiosの容量も超える需要 メモリプールでバックプレッシャー 処理量は容量上限で横ばいになり、待ち時間が増える

したがって、「Leiosを導入すると、すべての取引がPraosの約20秒から45〜60秒へ遅くなる」という理解は正しくありません。

低負荷時には通常のRBが使われ、Praosに近い経路が残ります。追加遅延が問題になるのは、主にRBへ収まらずEBへ入る取引です。

スループットのために決済スピードを犠牲にするのか

EB経由の取引だけを、混雑していないPraosの取引と比べれば、答えははいです。

EBは、伝播、検証、委員会投票、証明書の集約、後続RBへの証明書の取り込みという段階を通ります。そのため現行CIP-164の「Trade-offs & Limitations」は、提案仕様における取引取り込み時間を、Praosの約20秒に対してLinear Leiosではおよそ45〜60秒と整理しています。ワークショップで示されたシミュレーションでも、メモリプールから台帳へ入るまでの中央値はPraosより約1ブロック分長い、約2ブロック相当と説明されました。

ただし、この比較には負荷という条件を加える必要があります。

Praosの「約20秒」は、次のブロックへ取引が入る余裕があるときの目安です。ブロックが満杯なら、その取引は次のブロック、さらに次のブロックを待ちます。CPS-18は、現在のCardanoでも満杯に近いブロックが連続し、メモリプールの待ち行列によって最初の確認まで長く待つ場合があると指摘しています。

従来のPraosが処理できる量を超えた負荷では、理論上の20秒はすべての取引に提供できません。これに対してLeiosは、EB経由で一定の追加時間をかけながら、より多くの取引をまとめて台帳へ運びます。

つまり、次の二つは同時に成り立ちます。

  • 空いているPraosと比べると、EB取引のレイテンシーは長くなる
  • 混雑して待ち行列が伸びたPraosと比べると、Leiosによって結果的に早く台帳へ入る取引が増える

Leiosは「一件の最短時間」を競うのではなく、需要が増えても多数の取引を予測可能な時間で流し続けることを狙っています。シミュレーションでは、需要が容量へ達するまで取り込み時間の分布はおおむね安定し、容量を超えるとメモリプールによるバックプレッシャーで待ち時間が増える挙動が確認されています。

なぜ公式FAQには「速くなる」と書かれているのか

Leiosの公式FAQには、「レイテンシーを下げる」「より速い取引取り込み」「並列処理によって短時間に多くの取引を扱う」といった説明があります。一方、CIP-164は「Trade-offs & Limitations」で提案仕様における取引取り込み時間の増加を明記しており、低負荷時のRBではなく、主にEB経由の取引で追加遅延が問題になります。

一見すると矛盾していますが、比較している条件とLeiosの設計段階が異なります。

FAQの「速い」は、主に混雑して待ち行列が発生した従来のCardanoと比べ、より多くの取引を処理できるという利用体験を表しています。またFAQには、短い間隔で多数のブロックを並行処理する、研究版を含むLeios全般に近い説明も含まれています。

一方、CIP-164と現在の形式仕様は、Musashi Dojoで導入検証されているLinear Leiosを具体的に記述しています。Linear Leiosは取引レベルの並行性を取り除き、RBとEBを組み合わせる、より実装可能な方式です。

したがって現在の実装を説明する際は、一般向けFAQの「高速化」という言葉だけでなく、CIP-164、Linear Leios形式仕様、2026年版の技術設計を合わせて読む必要があります。

Solanaのような低レイテンシーチェーンに対する限界

決済までの待ち時間だけを比較するなら、LeiosはSolanaのような低レイテンシーL1に対する優位性を作るものではありません。Solana Foundationの資料では、現行Solanaは約400msのプリコンファメーションと約12.8秒のTowerBFTファイナリティを持ち、執筆時点で開発中のAlpenglowは約150msのファイナリティを目標としています。これに対してCardanoは、低負荷時のRBでも平均ブロック間隔は約20秒で、EB経由ではさらに取り込み時間が増えます。Perasも高い確度の決済状態をブロック取り込み後約2分で判断することを目標としており、セキュリティ前提が異なるため単純比較はできないものの、汎用L1の生の決済レイテンシーではCardanoに速度上のアドバンテージがあるとは言えません。Leiosが埋めるのはSolanaとのレイテンシー差ではなく、Cardano自身の容量不足です。

では、Leiosの価値はどこにあるのか

Leiosの価値は、Cardanoを低レイテンシーチェーンへ変えることではありません。Cardanoが重視してきたPraosのセキュリティ特性と既存の台帳を残しながら、L1が運べる取引量を増やすことにあります。

具体的には、次のような価値です。

  • 通常のPraos経路を残し、低負荷時に不要なEBコストを発生させない
  • Leiosの通信や処理よりPraosを優先し、基盤となるチェーンの安全な動作を守る
  • 需要が増えたときだけ追加容量を使い、混雑による待ち行列の悪化を抑える
  • 既存のCardano取引、台帳、DApp、ウォレットとの互換性をできるだけ維持する
  • SPOが参加する委員会投票によって、大きな取引群の可用性と妥当性を確認する
  • L1の利用と手数料収入を増やせる経済的な土台を用意する

これは、他チェーンより一件の決済が速いという競争優位ではありません。Cardanoの設計思想と運用構造を保ちながら、これまでの処理上限を越えるための拡張です。

Leiosの限界をHydraはどう補うのか――Perasとの役割分担

Cardanoで「速さ」を考えるとき、Leiosだけを見ると役割を誤解します。ワークショップでセバスチャン氏は、以前はHydraの開発を担当し、ここ約1年はLeiosへ軸足を移したと説明しました。現在もHydraチームへ助言していますが、HydraはCardano L1の上で動くL2であり、Leiosとは性質が異なると明確に区別しています。

この違いは、単なる技術分類ではありません。Leiosが直接引き下げない一件ごとのレイテンシーを、Cardano全体としてどこで補うのかを理解する鍵になります。

技術 主な役割 改善するもの
Ouroboros Leios Cardano L1に追加の取引処理経路を作る スループット容量
Ouroboros Peras 投票によってブロックの決済確度を早く高める ファイナリティ／セトルメント
Hydra Head 限定された参加者間で取引をオフチェーン処理する 低レイテンシー、高スループット、低コスト

LeiosとPerasは、公式技術設計でも基本的に直交した技術として整理されています。Leiosがスループットを担当し、Perasがファイナリティを担当します。

Hydra Headは、あらかじめ決めた参加者がCardano L1上でHeadを開き、UTxOを持ち込んで作るオフチェーンのミニ台帳です。Head内ではCardano L1と同じ形式のトランザクションと検証規則を使いながら、各取引をL1へ逐次書き込まずに処理します。参加者が新しい状態をスナップショットとして承認し、終了時には合意した状態をL1へ戻します。

これにより、参加者間の通信に近い低レイテンシー、高いスループット、低い取引コストを狙えます。反復的な決済、オークション、投票など、参加者と利用範囲を定められる用途では、Leiosとは異なる形で即時性を提供できます。

ただし、HydraはCardano L1そのものを高速化する仕組みではありません。基本的なHydra Headでは参加者があらかじめ定められ、オンラインで応答し、状態更新へ合意する必要があります。Headへ持ち込んだ資金の範囲で動き、参加者数、ネットワーク構成、UTxO、Headの開設・終了などにも制約があります。誰もが同じL1へ直接取引を送るSolanaとは、利用条件と信頼モデルが異なります。

LeiosがHydra Head内部の処理を直接高速化するわけでもありません。一方、HydraはHeadの開設、資金の追加・引き出し、終了時の状態確定でCardano L1を利用します。そのため、LeiosによってL1側の混雑が緩和されれば、HydraがL1と接続する場面の余力も増える可能性があります。これは両技術の構造から導ける補完関係であり、実際の効果はLeios導入後のパラメータと実測で確認する必要があります。

Cardano全体としては、Leiosで誰もが利用するL1の容量を増やし、PerasでL1の決済確度を早め、即時性が必要で参加条件を定められる用途にはHydraを使うという役割分担になります。「LeiosかHydraか」ではなく、異なる速度の問題を異なる層で解く組み合わせです。

スループットが経済的持続可能性につながる理由

ワークショップで繰り返し説明されたのが、LeiosとCardanoの経済的持続可能性の関係です。

Cardanoでは、ステーキング報酬の一部を支えてきたリザーブが時間とともに減少します。将来もSPOと委任者への報酬を維持するには、実際の利用から生まれるトランザクション手数料が、ネットワーク運営を支える割合を高める必要があります。

しかし、需要があってもL1の容量が小さければ、手数料を生む取引を十分に台帳へ取り込めません。PraosのブロックサイズやPlutus実行予算を単純に増やす方法には、世界中のノードへ一定時間内にブロックを届け、安全性を保つうえで限界があります。

ワークショップでは、運営上の損益分岐点として毎秒約70〜75kBのトランザクションデータ、取引サイズの仮定によって約50〜75 TPSという目安が示されました。CIP-164も、将来のリザーブ減少を手数料で補うために、平均的な取引でおよそ36〜50 TPSが必要になると試算し、図8では経済的効果が明確になる持続スループットを約50〜70 TxkB/秒と示しています。

一方、Linear Leiosが検証している性能範囲は、約140〜300 TxkB/秒、平均的な取引で約100〜200 TPSです。重要なのは、数字だけ大きくすることではありません。十分な実需があり、増えた手数料収入が増加するノード運用コストを上回ることが前提です。

Leiosが作ろうとしているのは、取引需要そのものではなく、需要が生まれたときにCardanoがそれを受け止められる余地です。

Musashi Dojoとは何か

Musashi Dojo（武蔵道場）は、Ouroboros Leiosのために開かれたCardanoのパブリックテストネットです。2026年6月下旬からメインネットのハードフォークまで、初期プロトタイプ、段階的なノード更新、負荷試験、パラメータ調整を重ね、リリース候補へ近づけていく長期テストプログラムとして運営されています。

IOがネットワークの基盤を運営し、独立したSPOがLeios対応のブロック生成ノードを動かして、実際の合意形成へ参加します。DApp、ウォレット、インデクサ、監視ツールなどを開発するビルダーにとっても、Leios環境で既存の仕組みがどう動くかを事前に確認する場所です。

「道場」という名前が示す通り、ここは最大TPSを一度だけ披露するデモ会場ではありません。新しいノードリリースを導入し、ネットワークを再構築し、条件を変え、負荷をかけ、問題を見つけ、次の実装へ戻すための訓練場です。

公式プログラムは、宮本武蔵の『五輪書』にちなんだ五つの段階を進む計画です。地（Earth）で基本設計と基本動作を確かめ、水（Water）でプロトコル・パラメータを探索します。火（Fire）では地理、OS、ハードウェア、ネットワーク条件を広げた実環境と負荷を検証し、風（Wind）では敵対的条件とストレス試験へ進みます。最後の空（Void）は、メインネット準備と外部ツールを含む統合の最終確認です。

武蔵道場で本当に確かめるべきこと

今回の議論を踏まえると、Musashi Dojoの成否を「最大TPSが出たか」だけで判断することはできません。検証すべきなのは、少なくとも次の点です。

1. 持続可能なスループット

瞬間的な最大値ではなく、現実的な取引サイズとPlutus負荷で、どれだけのTxkB/秒を継続して台帳へ届けられるかを測ります。需要を増やしたとき、処理量が容量までは比例して増え、容量を超えてもプロトコル自体が崩れず、バックプレッシャーで制御できることが必要です。

2. 取引取り込み時間

RB経由とEB経由を分け、メモリプールから台帳へ入るまでの中央値だけでなく、ばらつきと長い待ち時間も測る必要があります。高いスループットを達成しても、取り込み時間が利用者やDAppにとって受け入れられない水準なら、パラメータの再調整が必要です。

3. 世界規模のネットワーク遅延

Leiosはノード間の通信遅延に敏感です。日本、シンガポール、韓国、欧州など、離れた地域にノードを配置し、メインネットに近いトポロジーとステーク分布を再現します。どの大きさのEBを、どの時間枠で安全に伝播・検証できるかは、実測をもとに決められます。

4. SPOによる投票と認証

異なる場所、運用環境、ノード実装から参加しても、委員会の投票が時間内に集まり、証明書を安定して作れるかを確認します。ブロック生成の偏り、投票の遅延、ノードの離脱、悪意あるデータにも耐える必要があります。

5. Praosを妨げないこと

LeiosはPraosの空いている資源を使う設計です。EBの伝播や大量の取引検証が、通常のPraosブロックの伝播、採用、チェーン選択を妨げてはいけません。技術設計では、処理の優先順位をPraos、最新のLeiosデータ、古いLeiosデータの順に置いています。

6. SPOの機器要件と運用コスト

ワークショップでは、CPUやRAMだけでなく、高速なSSD、ディスクI/O、ネットワーク帯域、増え続けるチェーンデータが重要な確認点として挙げられました。全ノードが台帳全体を検証する現在の設計では、ノード数を増やすだけで処理能力が増えるわけではありません。高い性能を求めすぎてSPOの参加コストが過度に上がれば、分散性とのトレードオフになります。

7. DApp、ウォレット、インデクサとの互換性

Leiosは既存の取引形式を大きく変えないことを重視していますが、新しいブロック構造、証明書、メモリプール、node-to-client通信への対応は必要です。高いスループットが出ても、ウォレットやインデクサが追従できなければ、利用者へ届けられる性能にはなりません。

研究から公開検証へ――Leiosの現在地

セバスチャン氏によると、Leiosの本格的な開発が始まってから約9か月。ワークショップ時点では約20人が関わり、そのうち5〜10人ほどが中心的に開発していました。研究開発中心の小さな体制から、コンセンサス、台帳、ネットワーク、暗号、ノード実装を横断するエンジニアリング体制へ広がっています。

公式の技術設計文書は、CIP-164のプロトコル仕様とcardano-nodeへの実装をつなぎ、Dijkstra時代のブロック構造、EBの伝播と保存、投票と証明書、ディスク上の台帳状態、負荷試験、敵対的テスト、ツールとの互換性まで具体化しています。

Musashi Dojoでは、ワークショップ当日の画面で55のステークプールが登録されていました。セバスチャン氏は、メインネットに近い分散環境を再現する目安として、100 SPO程度の参加を望んでいます。ノードのバージョンを揃え、投票機能を有効にし、継続的に運用してもらうための導線とインセンティブも、SPOとの対話を通じて検討されています。

Leiosは今、研究成果を世界中のSPOとともに本番品質のCardano実装へ変えていく段階にあります。

論文、形式仕様、シミュレーション、プロトタイプ、ローカルデモ、公開テストネットが一本につながり始めました。この段階では性能値を固定的な答えとみなさず、公開テストネットの実測をもとに、スループット、レイテンシー、セキュリティ、運用コストの均衡点を探す必要があります。

Leiosの成功を何で判断するのか

Leiosの成功は、「Cardanoが何TPSになったか」という一つの数字だけでは判断できません。

前章の検証項目を一つの合否条件にまとめるなら、現実的な取引とPlutus負荷で持続可能な容量を増やしながら、Praosの通常処理と安全性を妨げず、EBの追加レイテンシー、SPOの機器コスト、DAppやウォレットの追従負荷を受け入れ可能な範囲に収められるかということです。

さらに、増えた容量が実際に利用され、そこから生まれる手数料が追加の運用コストを支えられることも必要です。技術的な最大値と、利用者・SPO・エコシステムにとって持続可能な性能は、同じではありません。

Leiosは、Solanaのような低レイテンシーL1になるためのプロトコルではありません。また、取引需要を自動的に生み出すものでもありません。

それでも、Cardanoが現在のPraos容量を超えて利用を広げるには、需要を受け止める新しいL1の処理経路が必要です。Linear Leiosは、研究版の最大性能をそのまま追うのではなく、Cardanoの安全性、分散性、互換性を保ちながら、その処理経路を現実に導入しようとしています。

Cardanoを一件ずつ速く走らせるのではなく、混雑しても多くの取引を運べるようにする。

これが、現時点でのLeiosの最も正確な姿です。そしてMusashi Dojoは、その設計上の約束が世界規模の実ネットワークでも成立するのかを確かめる場所です。

現時点の理解から、道場での実測へ

本稿で整理したのは、あくまで現時点でのSIPOの理解です。CIP-164は提案段階にあり、Leiosの技術設計文書も、実装と検証に応じて更新される「生きた文書」と位置付けられています。Musashi Dojoから新しいデータが得られれば、現在のスループット目標、EBの取り込み時間、SPOの機器要件、運用コストに対する見方が変わる可能性もあります。

SIPOは今後、Musashi Dojoへの参加を予定しています。外から公表値を追うだけでなく、実際のテストネットに参加し、RBとEBの動き、投票と認証、ネットワーク遅延、高負荷時の挙動、ノード運用で見えてくる課題を継続して確認していきます。

Leiosについて、ここで結論を固定するのではありません。新しい設計、新しいリリース、実ネットワークでの測定結果が出たときには、本稿の理解と照らし合わせ、必要であれば評価を更新し、その変化を引き続き記事として伝えていきます。今回のディープダイブは、その継続的な検証の出発点です。

参考・出典

透明性メモ

本記事は、ユーザー提供のワークショップ文字起こしと、2026年7月16日時点で確認したMusashi Dojo、Ouroboros Leios、Cardano Improvement Proposals、Hydra、Solana Foundationの公式資料をもとに構成しました。文字起こしは読みやすさのため整理されており、逐語記録ではありません。

ワークショップ参加者の氏名は伏せ、記事中で実名を記載した参加者はセバスチャン・ナーゲル氏のみです。参加プール数、開発人数、機器要件、性能目標などは、ワークショップおよび各資料を確認した時点のスナップショットであり、今後のテスト、パラメータ調整、Cardanoガバナンスによって変わる可能性があります。

特にTPS、TxkB/秒、取引取り込み時間は、取引サイズ、Plutus負荷、ネットワーク条件、プロトコル・パラメータによって変化します。本稿では、研究版Leios全般の説明と、Musashi Dojoで検証されているLinear Leiosの現行仕様を区別しています。

関連記事

日本語版
Deep Dive｜AIエージェントの責任はどこまで追えるか｜WeAreDevelopersのセッションとMasumi Networkを分けて読む
Deep Dive
🔬 Deep Dive｜プロトコルは無傷、陥ちたのはアプリ層 ― SecondFi 事件が Cardano に残した宿題
Deep Dive
EMURGOが「Pentad」を降りた日 — 創設団体の説明責任と、Cardano執行連合という実験