この記事のポイント
- LeiosはDijkstraで導入されます。 Cardanoの次期ハードフォークでは、Leiosに加え、ネストされたトランザクション、アカウント機能の強化、ガードスクリプト、Plutus V4、ステーキング報酬の自由な引き出しなどが導入されます。
- 導入は段階的に進められます。 憲法の更新、ハードフォーク、SPOによるBLSキーの登録、メインネットでの高負荷テストを経て、プロトコルパラメータの更新によって処理能力を引き上げます。
- 処理能力は一段階ずつ引き上げられます。 Leiosは保守的な設定で稼働を開始し、少なくとも2回のパラメータ更新を通じて処理能力を拡大します。各更新は、その前の段階でメインネットから得られた検証結果に基づいて実施されます。
- SPOには新しいキーが必要になります。 ハードフォーク後、ステークプールはLeiosの投票に使用するBLSキーを登録します。Leiosの有効化には、委任済みステークの約90〜95%に相当する登録が必要になると見込まれています。
- 最初は3〜5倍、その後10〜15倍を目指します。 Leiosは、現在の処理能力の上限である4.5 TxkB/sの約3〜5倍を初期目標としています。その後のパラメータ更新では、約10〜15倍を目指します。それ以上の拡大ペースは、需要、コミュニティのニーズ、経済的な条件によって決まります。
Ouroboros Leiosは、Cardanoの次期ハードフォークであるDijkstraとともに導入される予定です。
ただし、ハードフォークはLeiosの導入プロセスの始まりであり、その時点でCardanoがLeiosの最大処理能力を発揮するわけではありません。
まず、ステークプールオペレーター（SPO）が新しいBLS投票キーを登録します。十分なステーク量に相当する登録が完了すると、Leiosはエンドーサーブロックを利用できるようになります。
その後、メインネットでの検証結果とガバナンスによる承認に基づき、ネットワークの処理能力を段階的に引き上げていきます。
初期段階では、現在のPraosの処理能力の上限である4.5 TxkB/s（1秒あたりに処理できるトランザクションデータ量をキロバイト単位で表した指標）の約3〜5倍を目指します。
さらに、少なくとも2回のプロトコルパラメータ更新を通じて、現在のスループットの約10〜15倍まで引き上げることを目標としています。
それ以降の拡大については、ネットワークへの需要、開発者が必要とする処理能力、そしてネットワーク運用の経済性を踏まえて判断されます。
また、Dijkstraには、ネストされたトランザクション、アカウント機能の強化、ガードスクリプト、Plutus V4、ステーキング報酬の自由な引き出し、そして新しいプレッジ・レバレッジ・パラメータも含まれます。
これらの機能はハードフォークとともに導入されるため、Leiosが後続のスループット目標を達成するのを待つ必要はありません。
導入までの5つのステップ
1. 憲法の更新
Dijkstraで導入される新しいプロトコルパラメータについて、憲法に必要な規定と安全上の制約を追加します。これにより、ハードフォーク後にガバナンスを通じてパラメータを変更できるようにします。
2. Dijkstraハードフォーク
Leiosとその他のDijkstraの新機能を含む、新しいプロトコルルールへCardanoをアップグレードします。
3. BLSキーの登録
SPOがLeiosのエンドーサーブロックへの投票に必要なキーを登録します。登録済みのステーク量が十分な水準に達すると、Leiosが稼働を開始します。
4. メインネットでの高負荷テスト
計画的に大量のトランザクションを発生させ、実際のネットワーク上でエンドーサーブロックや投票がどれほど速く伝播するかを測定します。
5. スループットの引き上げ
メインネットで得られた検証データとガバナンス投票に基づき、少なくとも2回のパラメータ更新を通じて処理能力を拡大します。
これらは、それぞれ異なる段階を示しています。
ハードフォークによってプロトコルが利用可能になり、BLSキーの登録によってLeiosの投票が可能になります。そして、その後のパラメータ更新によって、Leiosが処理できる負荷の上限が変更されます。
こうした処理能力の変更に、追加のハードフォークは必要ありません。
Praosのスループットに上限がある理由
Cardanoは現在、Ouroboros Praosを採用しています。
平均すると、ステークプールは約20秒に1回の割合でブロックを生成する権利を獲得します。
Praosが証明済みのセキュリティ上の前提条件を満たして動作するためには、次のブロックが生成される可能性が高まる前に、新しいブロックがネットワーク全体へ届く必要があります。
メインネットでは、この伝播のために約5秒の時間が確保されています。
ときには、2つのステークプールが数秒の間隔でブロックを生成することがあります。この場合、チェーンの先端で一時的な分岐が発生しますが、各ノードが1つの分岐に収束する過程で、チェーン選択ルールによって解決されます。
5秒という伝播時間の制約は、こうした分岐の発生頻度を抑え、分岐が発生しても短時間で解消できるようにするためのものです。
ブロックの到着が頻繁に遅れると、正しく生成されたブロックであっても、最終的に採用されない分岐に含まれるケースが増えます。
その結果、チェーンの成長速度が低下し、同じ水準の確実性をもってトランザクションの決済完了を判断するまでに、より長い時間が必要になります。
ブロックはこの制限時間内にネットワークへ伝播しなければならないため、そのサイズを無制限に大きくすることはできません。
これにより、メインネットのトランザクション処理能力には、約4.5 TxkB/sという上限が生じています。
Praosは通常の需要には対応できますが、大規模なサービスのローンチ、エアドロップ、市場の急変などによってトランザクションが集中すると、処理待ちのキューがいっぱいになる可能性があります。
Praosのパラメータを変更するだけでは、処理能力の上限を引き上げるにも限界があります。
需要が急増した際には、もう1つ問題が発生します。
Praosノードのメモリプール（mempool）は、およそ2ブロック分のトランザクションを保持できる容量となっています。
メモリプールがいっぱいになると、ノードは新しいトランザクションの受け付けを停止します。そのため、ウォレットは空きができるまで送信を繰り返す必要があります。
この待ち時間は、トランザクションがメモリプールに入る前に発生します。そのため、ブロックへの取り込み時間を測定するだけでは、ユーザーが実際に経験する待ち時間の全体を把握できません。
Leiosによって何が変わるのか
ランキングブロックとエンドーサーブロック
Leiosでも、Praosのランキングブロックは引き続き使用されます。
ランキングブロックは、Cardanoが現在使用しているブロックに、いくつかのヘッダーフィールドを追加したものです。
処理待ちのトランザクションがランキングブロックの容量を超える場合、ブロック生成者はそのヘッダー内でエンドーサーブロックの存在を通知できます。
エンドーサーブロックには、トランザクションそのものではなく、トランザクションへの参照情報が順序付きのリストとして格納されます。
ノードはこのリストを取得し、どのトランザクションをすでに自身のメモリプールに保持しているかを確認したうえで、不足しているものをダウンロードします。
必要なトランザクションがすべて揃うと、ノードはエンドーサーブロックを他のピアへ転送します。
投票と認証
各エポックの開始時に、ステーク量の多いプールが、そのエポックの投票委員会のメンバーとなります。
CIP-164では、約900の議席でアクティブステークの約99%を代表する委員会の構成が検討されています。
委員会のメンバーは、ブロック生成者が同じスロットに対して異なる2つのブロックを通知していないか、ネットワークが検知できるように短時間待機します。
その後、エンドーサーブロックを検証します。
すべてのトランザクションが有効であると確認したメンバーは、自身のBLSキーを使って投票に署名します。
アクティブステーク全体の少なくとも75%に相当する投票が集まると、それらの署名を1つの証明書にまとめることができます。
この証明書には、集約された1つの署名と署名者の記録が含まれ、全体のサイズはわずか数百バイト程度です。
その後に生成されるランキングブロックには、トランザクションそのものの代わりに、この証明書が格納されます。
これにより、エンドーサーブロックのトランザクションが台帳に反映されます。
ここで重要になるのが、タイミングです。
証明書をランキングブロックに含めるには、エンドーサーブロックがネットワークに十分伝播する時間が必要です。
CIP-164では、その時間として約14秒という値が検討されています。
次のランキングブロックが早すぎるタイミングで到着した場合、エンドーサーブロックは破棄されます。
その場合、ランキングブロックは従来のPraosブロックと同様に、トランザクションを直接格納します。処理待ちのトランザクションは、後続のブロックに含めることができます。
この設計では、ランキングブロックのおよそ半数で、こうしたフォールバックが発生することを想定しています。
75%という認証のしきい値は、アクティブステークの大部分がエンドーサーブロックを受信し、検証することを求めるものです。
これは、ランキングブロックの生成タイミングをPraosと同じまま維持し、現在Praosが提供しているセキュリティ保証を保ちながら、Leiosによって処理能力を拡大できる仕組みの重要な要素です。
トランザクションが少ないときには、エンドーサーブロックは通知されません。そのため、ネットワークの運用コストはPraosに近い水準に抑えられます。
トランザクションの処理時間はどう変わるのか
Leiosでも、Cardanoのトランザクションは従来どおり、決められた順序で処理されます。
トランザクションは決定論的な順序で適用されるため、スマートコントラクトが前提としているトランザクションの順序に関する性質は維持されます。
ランキングブロックに直接収まるトランザクションは、現在と同じ速さでブロックに取り込まれます。
一方、エンドーサーブロックを経由するトランザクションは、およそ45〜60秒で台帳に反映されます。
ただし、この時間だけでユーザー体験のすべてを説明できるわけではありません。
ユーザーが待ち始めるのは、ノードがトランザクションを受け付けたときではなく、送信ボタンを押した瞬間だからです。
Leiosでは、ブロックの処理能力とともに、メモリプールの容量も拡張されます。
CIP-164では、少なくともランキングブロック2個分とエンドーサーブロック2個分のトランザクションを保持できる容量が規定されています。
メモリプールの容量を拡大することで、トランザクションが急増した際にも、新しいトランザクションの受け付けが拒否されるケースを減らすことを目指しています。
トランザクションがブロックに取り込まれるまで待つ場合はありますが、ウォレットが繰り返し再送信する代わりに、ネットワーク側でトランザクションを保持できるようになります。
トラフィックがPraosの処理能力を超えている場合、エンドーサーブロックを経由する個々のトランザクションの処理に、ランキングブロックへ直接取り込まれる場合より長い時間がかかったとしても、スループットの向上によって、最初の送信からブロックへの取り込みまでの時間を短縮できます。
SPOにとって処理能力の向上が重要な理由
Cardanoのリザーブ（準備金）が減少するにつれて、トランザクション手数料の重要性はさらに高まっていきます。
現在、各エポックの報酬の85%以上はリザーブから支払われていますが、リザーブからの拠出額はエポックごとに減少しています。
CIP-164では、手数料収入によって収支均衡を達成するには、約50〜70 TxkB/sのトラフィックが継続的に必要になると推定しています。
これは、現在のPraosが対応できるスループットの10倍以上に相当します。
Leiosは、この水準のネットワーク利用を実現するための道筋を提供します。
ただし、Leios自体が需要を生み出すわけではありません。
そのため、今後の処理能力の拡大は、ネットワークが実際にどのように利用されるかにも左右されます。
処理能力を段階的に引き上げる理由
LeiosのテストネットであるMusashiNetでは、これまでに広範なテストが実施されてきました。
しかし、メインネットには、テストネットでは完全に再現できない条件が存在します。
約2,700の登録済みステークプールが世界各地に分散し、それぞれ異なるハードウェア、ソフトウェア構成、ネットワーク接続環境で稼働しています。
さらに、メインネットでは実際の価値を持つ資産が扱われます。
そのため、Leiosは当初、保守的なプロトコル設定で稼働を開始する計画です。
主な制御項目には、エンドーサーブロックが参照できるトランザクションの数や、そこに含められるPlutusの処理量などがあります。
これらの制限は、憲法に定められた安全上の制約の範囲内であれば、追加のハードフォークを行わずに、ガバナンスによるプロトコルパラメータの更新を通じて引き上げたり、引き下げたりできます。
Leiosが有効化された後、開発チームはメインネット上で計画的な高負荷テストを実施する予定です。
このテストでは、エンドーサーブロックが実際のネットワーク上でどのように伝播するか、委員会の投票がどれほど速く返ってくるか、証明書が安定して生成されるか、そしてノードにどの程度の処理余力が残っているかを確認します。
最初の処理能力の引き上げは、これらの検証結果に基づいて判断されます。
次の引き上げについても、引き上げ後の負荷設定で得られた検証結果を使用します。
SPOにかかる負荷は、一度に急増するのではなく、段階的に高まっていきます。
開発者は発表された処理能力の引き上げ計画に合わせて準備を進めることができ、ガバナンスには、それぞれの変更を承認または否決する権限が引き続き残されます。
ガバナンスのロードマップ
| ステップ | 実施内容 | DRep | SPO | 憲法委員会 |
|---|---|---|---|---|
| 憲法の更新 | Dijkstraの新しいパラメータに安全上の制約を追加 | ステークの75% | 投票不要 | 委員の3分の2 |
| ハードフォーク | Leiosを含むDijkstraへの移行 | ステークの60% | ステークの51% | 委員の3分の2 |
| BLSキーの登録 | SPOがLeiosの投票キーを登録し、十分な登録後に有効化 | 投票不要 | 各プールがキーを登録 | 投票不要 |
| メインネットでの高負荷テスト | 高負荷状態でネットワークの伝播性能と投票処理を検証 | 投票不要 | 投票不要 | 投票不要 |
| スループットの引き上げ（少なくとも2回） | パラメータ変更によってLeiosの処理能力を拡大 | ステークの67% | ステークの51% | 委員の3分の2 |
※ 表中の割合は、各ガバナンスアクションの承認に必要な賛成割合を示しています。DRepとSPOについては、ステーク量に基づく割合です。投票が不要なステップでは、独立したガバナンスアクションではなく、運用上の対応が求められます。
1. 憲法の更新
ガバナンスによってプロトコルパラメータを変更できるようにするには、まず憲法にそのパラメータを明記し、将来の変更に適用される安全な範囲を定義する必要があります。
Dijkstraでは、Leiosのスループットを制御するものを含め、新しいパラメータが導入されます。
それぞれについて、憲法への追加と安全上の制約の設定が必要です。
計画では、ハードフォークに先立って憲法の更新案を提出します。
これにより、Dijkstraがメインネットに導入された後、検証によって十分な根拠が得られ次第、最初のスループット引き上げを提案できるようになります。
IntersectのParameters Committeeが安全上の制約を策定し、Plutusチームがその制約を適用するスクリプトを更新します。その後、提案がオンチェーンで提出されます。
承認には、ステークの75%を代表するDRepの賛成と、憲法委員会の3分の2以上の賛成が必要です。
DRepには、協議期間中に草案を確認し、同意できない制限について質問するとともに、ガバナンスアクションが提出された際に投票することが求められます。
2. Dijkstraハードフォーク
ハードフォークは、ネットワーク全体で協調して実施するアップグレードです。
コミュニティがオンチェーンで変更を承認すると、各ノードは同じエポックの境界で新しいルールを適用します。
Plomin以降、Cardanoのハードフォークには、コミュニティガバナンスによる投票が必要となっています。
LeiosはDijkstraで導入される機能の1つです。
このリリースには、次の機能も含まれます。
- ネストされたトランザクション： 1つのトランザクションの中に、別のトランザクションを含められるようになります。これにより、分散型取引所（DEX）のコントラクトを必要としないアトミックスワップ、ADA以外のトークンによる手数料の支払い、DAppによるユーザーの手数料負担などが可能になります。
- アカウント機能の強化： ADAをアカウントアドレスに直接送信できるようになります。これにより、ウォレットやバッチ処理を行うサービスは、現在の最低額である1 ADAを大幅に下回る金額を請求できるようになります。
- ガードスクリプト： 共通の検証処理をトランザクションごとに1回だけ実行できるようになります。これにより、DAppが同じ検証処理の費用を繰り返し負担する必要がなくなります。
- Plutus V4： これらの機能を開発者が利用できるようにするスマートコントラクトのアップグレードです。
- ステーキング報酬の自由な引き出し： ADA保有者は、希望するタイミングで報酬を引き出せるようになります。また、DRepへの委任は、ステーキング報酬の引き出しとは切り離された、独立した意思決定となります。
- プレッジ・レバレッジ： ステークプールの報酬と、オペレーター自身が誓約するADAの量を関連付ける新しいパラメータです。
ハードフォークの承認には、ステークの60%を代表するDRep、ステークの51%を代表するSPO、そして憲法委員会の3分の2以上の賛成が必要です。
SPOはDijkstraに対応したノードへアップグレードし、投票する必要があります。
取引所、ウォレット、SDKのメンテナー、インデクサー、DApp開発チームは、公開テストネットでこのリリースに対するテストを実施することが望まれます。
DRepはアップグレードについて投票を行います。
3. BLSキーの登録
SPOは現在、VRFキーとKESキーを運用しています。
Leiosでは、エンドーサーブロックへの投票に使用する新しいBLSキーが導入されます。
BLS署名は1つの集約署名にまとめることができるため、数百のステークプールが投票した場合でも、委員会の証明書を小さなサイズに保てます。
ハードフォーク後、各SPOはBLSキーを生成し、そのキーと、対応する秘密鍵を自身が管理していることを証明する情報を含めた、更新済みのプール登録証明書を提出します。
登録されたキーは、次のエポックの境界で有効になります。
SPOは、KESキーとほぼ同じ約3か月ごとの周期で、BLSキーを定期的に更新します。
MusashiNet上のSPOは、すでにこの手順に従って運用しています。
Leiosの証明書には、アクティブステーク全体の75%に相当する投票が必要です。
BLSキーを登録していないプールもPraosブロックを生成することはできますが、Leiosのエンドーサーブロックには投票できません。
オフラインのプールや、投票が遅れるプールが存在することを考慮すると、キーの登録率は75%を十分に上回っている必要があります。
現時点では、委任済みステークの約90〜95%に相当する登録が必要と見積もられています。
これは、おおむねステーク量上位500〜900のプールに相当します。
正確な有効化要件は、現在最終調整中のプロトコルパラメータによって決まります。
BLSキーの登録について、DRepや憲法委員会による個別のガバナンス投票は必要ありません。
SPOはハードフォーク後、できるだけ速やかにキーを登録することが望まれます。
委任者は、自分が委任しているプールに対して、BLSキーの登録状況を確認できます。
4. メインネットでの高負荷テスト
十分なステーク量に相当するBLSキーの登録が完了すると、トランザクションの処理待ちがランキングブロックの容量を超えた際に、Leiosが動作できるようになります。
開発チームは、部分的に制御された条件下でプロトコルの挙動を観測するため、計画的に大量のトランザクションを発生させる高負荷テストも実施する予定です。
このテストでは、ランキングブロックの処理能力を超えるトラフィックを発生させ、エンドーサーブロック、委員会による投票、証明書の生成を実際に動作させます。
主な測定項目は、エンドーサーブロックがメインネット全体へ伝播するまでの時間と、数百のステークプールから投票が返ってくるまでの時間です。
どちらも、プロトコルが定める時間制限に対して十分な余裕をもって完了する必要があります。
また、証明書が安定して生成されるか、ノードに十分な処理余力が残っているかについても確認します。
これらの検証結果は、最初の処理能力の引き上げが適切かどうかを判断する材料となります。
なお、この高負荷テスト自体には、DRep、SPO、憲法委員会の投票は必要ありません。
5. スループットの引き上げ
Leiosは、現在の約3〜5倍のスループットを目標とする設定で稼働を開始します。
高負荷テストによって、エンドーサーブロックと投票が十分な時間的余裕をもって伝播することが確認できれば、少なくとも2回のパラメータ更新を実施し、Praosの処理能力の上限の約10〜15倍までスループットを引き上げる計画です。
各提案には、直前の処理能力の設定で測定されたデータを添付することが求められます。
処理能力の引き上げは、それぞれ独立したガバナンスアクションとなり、すでに承認された安全上の制約の範囲内で行われなければなりません。
承認には、ステークの67%を代表するDRep、ステークの51%を代表するSPO、そして憲法委員会の3分の2以上の賛成が必要です。
DRepとSPOは、各提案に添付された検証データを確認したうえで投票することが望まれます。
開発者は、ガバナンスによって実際に承認された上限に基づいて、サービスのローンチ計画を立てる必要があります。
こうした初期段階の引き上げ以降については、需要、コミュニティの優先事項、経済的な状況によって判断されます。
十分な根拠があればガバナンスは処理能力を引き上げることができ、必要がなければ現状の水準を維持することもできます。
今後必要となる対応
SPOにとって直近の準備は、Dijkstraに対応したノードを稼働させ、ハードフォークの投票に参加し、アップグレード後にBLSキーを登録することです。
DRepは、憲法の更新、ハードフォーク、そしてその後のパラメータ変更について、それぞれ評価・判断する必要があります。
ウォレット、取引所、SDK、インデクサー、DAppの開発チームは、公開テストネットでDijkstraのリリースを検証し、ガバナンスが実際に承認した処理能力の上限を継続的に確認することが望まれます。
Leiosは、段階的なプロセスを経てメインネットへの導入に近づいています。
ハードフォークによってプロトコルが導入され、BLSキーの登録によって投票が可能になります。
そして、メインネットで得られた検証結果に基づき、処理能力をいつ引き上げるかが決定されます。
