IOG（Input Output）は10月20日、Cardano の次のハードフォーク「Dijkstra」で Ouroboros Leios をメインネットに入れるまでの手順を、5 つの段階に分けて公開しました。ハードフォークは導入の始まりにすぎず、SPO による BLS 鍵の登録、本番での負荷試験、ガバナンス投票を経て、処理能力は今の約 3〜5 倍から 10〜15 倍へ段階的に引き上げられます。
この記事では、5 つの段階で誰が何に投票するのか、Leios がどうやって処理能力を増やすのか、Dijkstra に一緒に入る変更、そして SPO が実際にやることを、IOG の解説と、Leios の仕様を定める提案 CIP-164 にもとづいて整理します。
初期報: Leios が Dijkstra ハードフォークで Cardano に導入される
5 つの段階と、それぞれで投票する人
IOG が示した手順は次の 5 段階です。段階ごとに、投票が必要な主体と可決に必要な割合が違います。
- 1. 憲法の更新 — Dijkstra で新しく加わるプロトコルパラメーターを憲法に書き加え、安全に変更できる範囲（ガードレール）を定めます。DRep のステークの 75% と憲法委員会の 3 分の 2 が必要で、SPO の投票はありません。
- 2. Dijkstra ハードフォーク — Leios を含む新しいプロトコルのルールへ移ります。DRep のステークの 60%、SPO のステークの 51%、憲法委員会の 3 分の 2 が必要です。
- 3. BLS 鍵の登録 — SPO が Leios の投票に使う鍵を登録します。投票はなく、すべてのプールが鍵を登録する作業です。
- 4. メインネットでの負荷試験 — 計画的に取引を集中させ、本番のネットワークで Leios のブロックと投票がどれだけ速く伝わるかを測ります。ここも投票はありません。
- 5. 処理能力の引き上げ（少なくとも 2 回） — パラメーターの変更で Leios の上限を上げます。DRep のステークの 67%、SPO のステークの 51%、憲法委員会の 3 分の 2 が必要です。
IOG が SPO 向けに出した図では、5 段階目が「1 回目のパラメーター更新」と「2 回目のパラメーター更新」の 2 つに分かれ、その前に開発・監視チームによる「メインネットの観測」が置かれています。数え方は違いますが、中身は同じ手順です。
IOG はこれらを別々の節目だと強調しています。ハードフォークでプロトコルが使える状態になり、BLS 鍵の登録で Leios の投票ができるようになり、その後のパラメーター変更で Leios が扱える量が決まります。処理能力の変更には、もう一度ハードフォークをする必要はありません。
Praos の上限 4.5 TxkB/s と、Leios の仕組み
いまの Cardano は Ouroboros Praos で動いています。平均して約 20 秒に 1 回、どこかのプールがブロックを作る権利を得ます。Praos の安全性の前提を保つには、次のブロックが作られる前に新しいブロックがネットワーク全体へ届く必要があり、メインネットではその配達に約 5 秒を見込んでいます。この時間の枠があるため、ブロックを大きくし続けることはできず、処理能力は 1 秒あたり約 4.5 キロバイト分の取引（4.5 TxkB/s）が上限になっています。
需要が急に増えたときの問題はもう一つあります。Praos のノードが取引を一時的に預かるメモリープールは、ブロック約 2 つ分しか入りません。いっぱいになると新しい取引を受け付けず、ウォレットは空きができるまで送信をやり直すことになります。この待ち時間はブロックに入るまでの計測には表れないため、利用者が感じる遅れはブロックの数字より長くなります。
Leios は、いまのブロックを「ランキングブロック」として残したまま、その上に「エンドーサーブロック」を足します。取り込みを待つ取引がランキングブロックに入りきらないとき、ブロックの作り手はヘッダーでエンドーサーブロックを予告します。エンドーサーブロックには取引そのものではなく、取引への参照が順番に並んでいます。各ノードは自分のメモリープールにない取引だけを取り寄せ、そろったら隣のノードへ回します。
次に投票です。エポックの始めに、ステークの大きい順にプールが投票委員会の席に就きます。CIP-164 の想定は約 900 席で、アクティブステークの約 99% にあたります。委員は、同じスロットで 2 つの違うブロックを予告した作り手がいないかを少し待って確かめてから、エンドーサーブロックの中身を検証し、すべての取引が正しければ BLS 鍵で署名します。アクティブステーク全体の 75% 以上にあたる票が集まると、署名を 1 つにまとめた証明書ができ、数百バイトほどの大きさに収まります。後のランキングブロックが取引の代わりにこの証明書を載せることで、エンドーサーブロックの取引が台帳に入ります。
時間の制約もあります。証明書を載せられるのは、エンドーサーブロックがネットワークに行き渡る時間が過ぎてからで、CIP-164 はこれを約 14 秒と見積もっています。次のランキングブロックが早く来すぎると、そのエンドーサーブロックは捨てられ、ランキングブロックがいまの Praos と同じように取引を直接運びます。CIP-164 は、ランキングブロックの約半分がこの形になると見込んでいます。
利用者から見た時間はこうなります。ランキングブロックに直接入る取引は、いまと同じ速さで取り込まれます。エンドーサーブロックを通る取引は、台帳に入るまで約 45〜60 秒かかります。それでも、メモリープールがランキングブロック 2 つ分とエンドーサーブロック 2 つ分以上に広がるため、混雑時に送信が弾かれにくくなります。取引が増えて Praos の処理能力を超えている場面では、送信してから取り込まれるまでの時間が、全体として短くなりうると IOG は説明しています。取引が少ないときはエンドーサーブロックが予告されないので、ノードを動かす費用はいまの Praos とほぼ変わりません。
Dijkstra に一緒に入る 6 つの変更
Dijkstra に入るのは Leios だけではありません。IOG は次の変更を挙げています。これらはハードフォークと同時に入り、Leios が後の処理能力の目標に届くかどうかとは関係なく使えるようになります。
- 入れ子のトランザクション（CIP-118） — 1 つの取引の中に別の取引を含められます。DEX のコントラクトを使わない交換の同時成立、ADA 以外のトークンでの手数料の支払い、DApp が利用者の手数料を肩代わりする使い方を支えます。
- アカウントの改善 — アカウントのアドレスへ ADA を直接送れるようになります。ウォレットやバッチャーは、いまの 1 ADA の下限の何分の一かの手数料で済ませられます。
- ガードスクリプト — 共通の検査を取引ごとに 1 回だけ実行できます。DApp が同じ検査の費用を何度も払わずに済みます。
- Plutus V4 — これらの機能を開発者が使えるようにするスマートコントラクトの更新です。
- いつでも引き出せるステーキング報酬 — ADA の保有者は好きなときに報酬を引き出せます。IOG は、DRep への委任が「別の、意図して行う選択」になると説明しています。
- Pledge レバレッジ — プールの報酬を、運営者がどれだけ Pledge を積んでいるかに結びつける新しいパラメーターです。具体的な値は、IOG の記事では示されていません。
このうち報酬の引き出しと Pledge レバレッジは、委任者と SPO の両方の判断に直接関わります。どのプールに委任するか、どの DRep に投票を任せるかが、報酬の受け取りとは別の判断として並ぶことになります。Plutus V4 については、台帳の型を定める CIP-0195 や Plutus 1.71.0.0 など、開発側の準備がすでに進んでいます。
SPO がやること: Dijkstra 対応ノード、投票、BLS 鍵
SPO にとっての当面の準備は 3 つです。Dijkstra に対応したノードを動かすこと、ハードフォークの投票に参加すること、そしてアップグレードの後に BLS 鍵を登録することです。
SPO はすでに VRF 鍵と KES 鍵を運用しています。Leios はここに、エンドーサーブロックへの投票に使う BLS 鍵を加えます。BLS 署名は複数を 1 つにまとめられるため、数百のプールが投票しても委員会の証明書を小さく保てます。手順は次のとおりです。
- ハードフォークの後、各 SPO が BLS 鍵を作ります
- その鍵と、対応する秘密鍵を自分が管理している証明を含めて、プールの登録証明書を出し直します
- 鍵は次のエポックの境目から有効になります
- 鍵は定期的に入れ替えます。IOG によれば、KES 鍵とほぼ同じ四半期ごとの間隔で、CIP-164 では約 90 日です
テストネットの MusashiNet の SPO は、すでにこの手順で運用しています。9月の再構築でも、BLS 鍵の登録のやり直しが投票を続ける条件になっていました。
Leios の稼働に向けて特に大事なのは、登録率です。証明書にはアクティブステーク全体の 75% の票が要るため、止まっているプールや投票の遅いプールを見込むと、登録はそれを十分に上回る必要があります。IOG の現時点の見積もりは委任ステークの約 90〜95% で、上位およそ 500〜900 プールにあたります。メインネットの登録プールは約 2,700 あり、全体の 2〜3 割ほどのプールが鍵をそろえれば、Leios が動き出せる計算です。正確な稼働の条件は、まだ確定していないパラメーターで決まります。
BLS 鍵を持たないプールも、Praos のブロックは作れます。ただし、エンドーサーブロックへの投票には加われません。BLS 鍵の登録に DRep や憲法委員会の投票はなく、IOG は SPO に対し、ハードフォークが済んだらすぐに鍵を登録するよう求めています。委任者は、自分が委任しているプールに鍵を登録したかを尋ねることができる、とも書いています。
少しずつ上げる理由と、手数料の行方
MusashiNet では多くの試験が重ねられてきましたが、メインネットにはテストネットで再現しきれない条件があります。大陸をまたいで散らばる約 2,700 のプールが、それぞれ違う機材・設定・回線で動き、実際の資産がかかっています。そのため Leios は控えめな設定で始まります。主な調整項目は、1 つのエンドーサーブロックが参照できる取引の量と、そこに含められる Plutus の処理量です。
Leios が動き出した後、開発チームはメインネットで計画的な高負荷の試験を行います。測るのは、エンドーサーブロックが本番のネットワークに広がるまでの時間と、数百のプールから票が戻るまでの時間です。どちらもプロトコルの時間の枠に余裕をもって収まり、証明書が安定してでき、ノードに余力が残っているかを確かめます。1 回目の引き上げはこの結果で判断し、2 回目はさらに高い設定での結果を使います。各提案には直前の水準での計測結果を添えることになっており、DRep と SPO はそれを見て投票します。
処理能力が SPO に関わるのは、報酬の財源が変わっていくからです。IOG と CIP-164 によれば、いまのエポック報酬の 85% 超はリザーブから来ており、その割合はエポックごとに減っていきます。CIP-164 の試算では、手数料収入で採算が合うには 1 秒あたり約 50〜70 キロバイト分の取引が続く必要があり、これはいまの Praos の処理能力の 10 倍を超えます。
IOG は、Leios はその水準へ向かう道をつくるものの、需要そのものを生むわけではないとも書いています。10〜15 倍より先の引き上げは、実際の利用、開発者の必要、ネットワーク運営の採算で決まります。処理能力を上げるかどうかは毎回ガバナンスが決め、根拠が足りなければ据え置くこともできます。
次に見るもの
最初の手がかりは 1 段目の憲法の更新です。Dijkstra のパラメーターを憲法の付属書 I に加える改正案 CAP-12 が出ており、IOG はハードフォークより先にこの更新を提出する計画です。ガードレールは Intersect のパラメーター委員会が作り、Plutus チームがガードレールのスクリプトを更新したうえで、オンチェーンに提出されます。CAP-12 がガバナンスアクションとして GovTool に載った時点で、DRep の投票（ステークの 75%）が始まります。
SPO にとっては、その次に来る Dijkstra のハードフォークのガバナンスアクションと、Dijkstra 対応ノードのリリースが投票と作業の起点になります。ハードフォークの日程と、BLS 鍵の登録で Leios が動き出す正確な条件は、IOG の記事ではまだ示されていません。
ことば
- エンドーサーブロック — Leios で加わる、取引への参照を並べたブロック。混雑時だけ予告され、委員会の票が集まって証明書ができると、その取引が台帳に入ります。いまのブロックの大きさの制約を変えずに、運べる量を増やすための仕組みです。
- BLS 鍵 — 多くの署名を 1 つにまとめられる方式の鍵。Leios では数百のプールの票を数百バイトの証明書にするために使います。SPO が VRF 鍵・KES 鍵に続いて持つ 3 本目の運用鍵になります。
- ガードレール — 憲法が定める、各プロトコルパラメーターを変えてよい安全な範囲。Dijkstra の新しいパラメーターにも範囲が要るため、ハードフォークの前に憲法の更新が必要になります。
一次ソース / 関連リンク
- IOG 公式 X の告知
https://x.com/IOGroup/status/2112579715370270738
CIP-164（Ouroboros Leios の仕様）（cips.cardano.org）
CIP-118（入れ子のトランザクション）（cips.cardano.org）
leios.cardano-scaling.org
- Cardano PRIME による CAP-12 の説明
https://x.com/Cardano_Prime/status/2108554329275949397
Cardano
- SIPO.TOKYO: Plutus 1.71.0.0、V4 のスクリプトコンテキストを全面追加
https://sipo.tokyo/signal-20261009-34e459eb/ - SIPO.TOKYO: Daily Intel 10/10（CAP-12）
https://sipo.tokyo/daily-intel-20261010/
