CardanoのDijkstraはLinear LeiosとPerasを二つのフェーズに分ける

CardanoのDijkstraアップグレードは、計画されたコンセンサス変更のすべてを一度に有効化するわけではない。フェーズ1では新しい台帳の時代を導入し、

Protocol Version 12とLinear Leiosおよびより幅広い台帳の変更を伴う。一方でPerasは同じ時代の中で後日有効化される計画だ。

Intersectは現在、フェーズ1のコード完成を2026年Q4に、Perasを2027年Q2に目標設定している。これらの日付は確定したメインネットのハードフォーク日ではなく、開発上の見積もりだ。

Linear LeiosがDijkstraに先行して導入

Linear Leiosはフェーズ1の主要なスケーリング要素で、より広範なOuroboros Leios設計を簡素化して実装したものだ。

既存のPraosブロックはRanking Blocksへと拡張され、Endorser Blocksはトランザクション処理の追加容量を提供する。ステークに基づく委員会がEndorser Blockを認証し、その証明書が後続のRanking Blockに含まれて関連するトランザクションが台帳に適用される。

Linearの設計では、Input Blocksおよびより完全なLeios設計に含まれる並行的なEndorser Block生成の広範なモデルを取り除いている。

Intersectは、より広範な設計で必要となるトランザクション構造の追加的な複雑さを持ち込むことなく、Leiosアーキテクチャの一部をプロダクションに近づけるためにこの手法を選んだ。ドキュメントでは、いくつかの代替手法がdAppのユーザー体験に関する懸念を生み、初回の展開には不適切と判断されたことも指摘している。

Dijkstraのフェーズ1には、Nested Transactions、Guard Scripts、Plutus V4 Script Context、新しいブロック本体のシリアライゼーション構造など、追加の台帳変更が含まれる。これらが合わさって、新しい台帳の時代へのより広範な移行を構成する。

Dijkstraのメインネット目標として単一のTPS値は定義されていない。Linear Leiosはトランザクションのサイズやプロトコルパラメータに応じて異なる構成で動作でき、有効化直後に理論上の最大値で立ち上がるのではなく、稼働後に段階的に処理能力が増加していくことが見込まれている。

Perasは新たな台帳時代を設けずに準備される

Perasはフェーズ1では有効化されないが、そのために必要なインフラの一部はすでに導入される。

Dijkstraには、既存の時代の中でのプロトコルバージョン変更を通じて後日Perasを有効化するために必要な、CIP-140由来のコーデック拡張とプロトコルパラメータが含まれる。そのため、Perasの準備が整った際にもCardanoに再度の全面的な台帳移行を強いることなく、構造上の変更をフェーズ1の間に完了できる。

これらのプロトコルは、ネットワーク性能の異なる領域にも対処する。Linear Leiosはトランザクション処理能力を拡張し、PerasはOuroboros Praosの上に投票レイヤーを追加して、決済を加速し正準チェーンへの確信をより早く高めるよう設計されている。

したがってフェーズ2は、Leiosの展開の未完成部分ではなく、独立したコンセンサスのアップグレードだ。必要な台帳の基盤が整った後に、独自のテストと承認のプロセスを進めることができる。

コード完成はDijkstraのメインネット化を意味しない

現在の2026年Q4という目標は、保証されたメインネット有効化日ではなく、フェーズ1のコード完成を指す。

Dijkstra対応のノードがリリースされた後、このアップグレードはPreviewおよびPreprodのハードフォーク、ステークプールオペレーターによるテスト、ネットワークの準備状況の確認を経る必要がある。これらの段階が完了してはじめて、Mainnet Hard Fork Initiationというガバナンス行為に進むことができる。

Linear LeiosはMusashi Dojo環境でもテストが進められており、そこでノード同期、Endorser Blockの認証、トランザクションフローがすでに実証されている。この作業は、後に本番の挙動を左右するパラメータを洗練するために活用されている。

Dijkstraには、Cardano Constitutionへの対象を絞った改正も必要となる。新しいプロトコルパラメータには、ガバナンスが有効化後に定義された範囲内でそれらを変更できるよう、対応する憲章上のガードレールが必要だ。

提案されている改正は技術的な範囲にとどまり、既存のガバナンスの役割や投票の閾値を変更しない。現在の目標は、2026年9月11日に始まるepoch 655までに統合改正案を提出し、その後にDRepによる承認とConstitutional Committeeによる合憲性審査を受けることだ。

この手順により、エンジニアリングの完了とネットワークの有効化の間に意図的な間隔が設けられる。DijkstraはまずLinear Leiosに必要な台帳変更を確立でき、同時にフェーズ1にすでに組み込まれた基盤によって、Perasは別個のプロトコル判断として後から続くことができ、再度の全面的な台帳時代の移行を行わずに済む。