LIVE ADA-- MCAP-- TVL-- STAKE-- EPOCH-- Cardano & Midnight 総合情報ポータル
SIPO
速報 Intersect Weekly Update #125を公開、Dijkstra進捗など報告 4時間前 速報一覧 →
HOMESignal › Dijkstra の「2026 年内」に、Intersect が留保をつけました——ノードのリリース候補が出せるかというリスクです
Signal

Dijkstra の「2026 年内」に、Intersect が留保をつけました——ノードのリリース候補が出せるかというリスクです

2026-08-22SIPO

Intersect の週次アップデート #125(2026 年 8 月 21 日公開)が、Dijkstra の日程についてこう書きました。「The Haskell node teams remain committed to achieving enactment in 2026, although the timeline carries risk around the availability of a node release candidate.」——2026 年内という目標そのものは動いていません。動いたのは、その目標に添えられた但し書きのほうです。SIPO は日程の数字よりも「日程にどんな条件が付いたか」を観測点に置いています。条件が言語化された瞬間は、遅れが実際に起きるより前に、遅れの起きうる場所を教えてくれるからです。何が留保されたのか、そしてその留保がなぜ 9 月 1 日という別の締切とつながるのかを、順に見ていきます。

初期報: Intersect Weekly Update #125を公開、Dijkstra進捗など報告

■ 「2026 年内」に留保がついた

該当箇所の全文は次のとおりです。

The Haskell node teams remain committed to achieving enactment in 2026, although the timeline carries risk around the availability of a node release candidate. Stability and release quality remain the priority.

意味を分けて読みます。前半は「Haskell ノードのチームは 2026 年内の発効に引き続きコミットしている」。ここまでは、これまで繰り返されてきた内容と同じです。変わったのは後半で、「ただし日程には、ノードのリリース候補が用意できるかどうかというリスクがある」と続きます。そして最後に、「安定性とリリース品質が引き続き優先される」と置かれています。

直前の 2 週と並べると、書き方の変化がはっきりします。週次アップデート #123(8 月 7 日)は「The Haskell node team’s current objective is to deliver Phase 1 (Nested Transactions and Linear Leios) to Mainnet by the end of 2026」と目標だけを述べ、#124(8 月 14 日)は「agreed scope and target dates remaining unchanged」——合意された範囲も目標日も変わっていない、と報告していました。少なくともこの 2 週には、日程に添えられた留保はありません。8 月 19 日にお伝えした内容も、公式が二週続けて同じ言葉を使っている、という確認でした。#125 は、その同じ言葉に条件を一つ足した回です。

ここで言う「node release candidate」は、リリース候補のことです。開発途上のビルドではなく、これで本番に出せるという前提で外部に配られる版を指します。SPO の側から見ると、この版が出て初めて、自分のプール環境での検証を本番と同じ条件で始められます。逆に言えば、リリース候補が出るまでは、エコシステム側の準備は待つしかない部分が残ります。日程のリスクがここに置かれたということは、開発の終わりではなく、開発から検証への受け渡しの一点に不確実性が集まっている、という意味になります。

そして「安定性とリリース品質が引き続き優先される」という一文は、優先順位の宣言です。日程と品質のどちらかを選ぶ場面が来たときに、後者を取ると先に述べている。これは日程が動きうることを認める側の書き方であり、同時に、動いた場合の理由をあらかじめ示しておく書き方でもあります。

■ readiness tracker は置かれた、ただし中身はまだ見えない

同じ節には、もう一つ新しい要素があります。

The initial Dijkstra readiness tracker is now in place and will be expanded with more detailed criteria and ecosystem reporting.

Dijkstra の準備状況を追うトラッカーの初期版が置かれ、今後より詳細な判定基準とエコシステム側の報告を加えて拡張していく、という内容です。#125 の本文には、このトラッカーの公開 URL も、現時点で何を指標として測っているのかも記載がありません。確認できるのは「置かれた」ところまでです。

それでも、この一行は日程の話として小さくありません。ハードフォークが「間に合うかどうか」は、これまで各チームの内部感覚と週次の文章に依存していました。判定基準が明文化され、エコシステム側の報告が乗るようになれば、同じ問いを外側からも数えられるようになります。留保が付いた週に、留保の中身を測る器も置かれた——この二つは対になっています。

同じ節の前段では、現在の作業の中身も示されています。「documenting the impact of each included CIP, defining the necessary protocol parameter and constitutional changes, and expanding ecosystem readiness activities」——含まれる各 CIP の影響の文書化、必要なプロトコルパラメータと憲法上の変更の定義、そしてエコシステムの準備活動の拡大です。コードを書く段階ではなく、変更が何に触れるかを書き出して合意する段階に入っている、と読めます。この最後の「憲法上の変更」が、次の節につながります。

■ 9 月 1 日が Dijkstra の日程に触れる理由

#125 は、投票中のガバナンスアクションについてもこう書いています。

With this action due to expire on September 1, failure to ratify and enact it could interrupt Cardano’s governance continuity and consequently affect the Dijkstra timeline.

対象は「Update Constitutional Committee 2026」——憲法委員会の更新アクションです。9 月 1 日に失効し、批准・発効に至らなければ Cardano のガバナンスの連続性が途切れ、結果として Dijkstra の日程に影響しうる。この因果を主張しているのは外部の観測者ではなく、Intersect 自身です。

つながり方はこうです。前節で見たとおり、Dijkstra には憲法上の変更の定義が含まれます。憲法にかかわる変更を通すには、それを審査する委員会が機能している必要があります。現委員の任期が切れた状態で更新アクションが通っていなければ、審査する側の席が空きます。器が止まれば、その器を通す予定だった議案も止まる。日程表の上では別々に見える二つの締切が、ここで一本につながります。

票の状況について、#125 は 8 月 21 日時点として「DRep support currently sits at 37% against the 67% threshold, and SPO support at 7.9% against the required 51% to pass」と記載しています。可決には DRep 67% と SPO 51% の双方が要り、どちらもまだ距離があるという記載です。この値は 8 月 21 日時点のものですので、現在値は下にあるアクションのページでご確認ください。

同じ 9 月 1 日に失効するもう一件、「minPoolCost を 75 ada へ引き下げ、Plutus のメモリ上限を引き上げる(Part 2)」については、本稿執筆にあたって取得した値を記します。2026 年 8 月 22 日 20 時 22 分(JST)時点で、DRep の賛成は可決基準の分母で 43.85%(98 票)、閾値は 67% です。投票済みの反対は 2.93%(15 票)、AlwaysNoConfidence が 3.77%、そして未投票が 49.46% を占めています。念のため申し添えると、この未投票分は反対ではありません。反対と言えるのは、投票済みの反対にあたる 2.93% だけです。失効はエポック 653、取得時点のエポックは 650 でした。

SPO の方にとって重要なのは、この 2 件がいずれも SPO の投票を必要とする種別だという点です。憲法委員会の変更と、ネットワークグループを含むプロトコルパラメータの変更は、DRep とは別枠で SPO のしきい値が課されます。委任先を選ぶ側から見れば、投票していないプールがどれだけあるかは、9 月 1 日を過ぎた時点で結果として現れます。

■ 次に見るもの

エポック 653 までの区間で、観測点は三つです。

一つ目は、readiness tracker の判定基準が公開されるかどうか。#125 は「より詳細な基準」を今後加えると書いています。基準が外から見える形で出た時点で、「2026 年内」という言葉の確からしさは、文章ではなく項目で判断できるようになります。

二つ目は、憲法委員会の更新アクションが 9 月 1 日までに批准へ届くかどうか。しきい値に達しなければ、内容の是非以前に不成立です。

三つ目は、ノードのリリース候補そのものです。#125 が日程のリスクを置いた場所がここである以上、リリース候補が公表された日が、2026 年内という目標の実効性が最初に検証される日になります。

■ 二つの分岐

Base として置けるのは、リリース候補が期日内に出て、「2026 年内」が留保付きのまま維持される道です。この場合、留保は結果的に注意書きとして残り、readiness tracker の項目が順に埋まっていきます。

Risk は、9 月 1 日に憲法委員会の更新が不成立となる道です。Intersect 自身が Dijkstra の日程への影響を認めている以上、この一件は委員会人事の話であると同時に、ハードフォークの日程の話でもあります。9 月 1 日以降に議論の焦点がガバナンスの復旧へ移れば、その分だけ準備活動に使える時間は削られます。

どちらに転ぶかは、これから 3 エポックのあいだに投票所で決まります。今回の #125 が示したのは、その投票所と開発の工程表が、思っていたより近い場所にあるということでした。


一次ソース / 関連リンク