LIVE ADA-- MCAP-- TVL-- STAKE-- EPOCH-- Cardano & Midnight 総合情報ポータル
SIPO
速報 Cardano Governance Hours #10、OpenZeppelin Stack財務提案を深掘り 1日前 速報一覧 →
HOMESignal › BlockPQR 稼働、担当は Cardano の台帳・ノード・形式手法
Signal

BlockPQR 稼働、担当は Cardano の台帳・ノード・形式手法

2026-09-16SIPO

Cardano の中核プロトコルの開発を引き継ぐ BlockPQR が 9 月 15 日に稼働を始め、台帳(レジャー)、ノードとコマンドラインのツール、形式手法を受け持つと Input Output(IO)と BlockPQR が発表しました。8 月 26 日に告知された移管が実際に動き出し、次のハードフォーク Dijkstra と、その中心にある Leios に向けて誰が何を担うのかが、BlockPQR 自身の技術ノートで示されたことになります。

初期報: BlockPQR がCardanoのLedger、NodeCLI、形式手法に対応して稼働開始

SPO の運用や ADA の保有について、今日から変わることはありません。発表自身がそう明記しています。そのうえで 8 月の告知と並べると、何が具体的になり、何がまだ書かれていないのかが見えてきます。

BlockPQR is live today, taking on Cardano’s Ledger, NodeCLI, and Formal Methods!
The team is already working toward the Dijkstra hard fork and Leios’ implementation and calibration. Same engineers, same code, built in the open.

Input Output(@IOGroup)2026 年 9 月 15 日

■ 8 月に挙げられた 4 領域と、いま動いている 3 本

SIPO は 8 月 27 日の記事で IO の X 投稿だけを読み、担当領域は書かれていないとお伝えしました。ただ、同じ 8 月 26 日に IO が公式サイトで公開した記事には、BlockPQR に移る作業として 4 つの領域が挙げられていました。台帳(トランザクションの検証、ノードのエンジニアリング、運用者向けのコマンドラインツールを含む)、ブロックチェーンのインデクサー、形式手法、高可用性(監視、障害対応、ブロックを作るインフラ)です。

今回の技術ノートは、いまチームを動かしているのは台帳開発、形式手法、ノードのエンジニアリングの 3 本だとしています。インデクサーへの言及はありません。移管の対象から外れたのか、書き方の違いなのかは、発表からは読み取れません。

逆に前に出てきたのが、ノードを操作するコマンドラインの道具です。8 月には台帳の領域の一部として書かれていたものが、9 月の IO の投稿では「NodeCLI」として独立して名前が挙がりました。運用者が日々触る部分を、担当として明示した形です。

■ 責任と承認の置き場所は 8 月のまま

Input Output (IO) retains primary responsibility for the initiatives and milestones and continues to support delivery, while Intersect gates each milestone, and development continues in Cardano’s public repositories.

取り組みとマイルストーンの主たる責任は IO に残り、各マイルストーンは Intersect が関門として確認し、開発は公開リポジトリで続く。作業する会社、責任を負う会社、承認する組織を分けて書く形は、8 月から変わっていません。

ノードの運用についても、アップグレードは引き続き Intersect のハードフォーク作業部会とテストネットを経てからメインネットに入り、SPO、開発者、利用者は移行の影響を受けないとしています。Dijkstra と Leios の納品では、コンセンサスとネットワークを担う IO のチームと連携し、各チームが自分の責任範囲で貢献するとも書かれています。一つのハードフォークを、複数の組織が持ち場を分けて仕上げる形です。

■ 仕様を先に書き、実装をそれに照らす

技術ノートの半分近くは、進め方の説明にあてられています。形式仕様を実装より先に置き、次の 5 段階で進めるとしています。

  • 問題の定義: すべきこと、してはならないことを定め、曖昧さを実装の前に解消する
  • モデル化と証明: 実行可能な仕様を作り、証明か網羅的なテストで性質を確かめる
  • モデルに照らした実装: 仕様を基準に、実装を突き合わせてテストする
  • ベンチマーク: 性能目標を事前に合意し、評価の基準を明確にする
  • 堅牢化と引き渡し: 敵対的なレビューと大規模なファジングを経て、運用要件まで文書化する

狙いは、台帳の規則を実装の中に暗黙のまま置かず、不変条件として明示することです。BlockPQR のサイトのトップには、台帳の実装が仕様を満たすことを表す短いコード片が掲げられ、「価値が新たに生み出されることはない」という性質が不変条件として書かれています。新しいエラ(時代区分)のたびにトランザクションの種類や有効性の規則が変わる以上、変更の前後で壊れていないことを示す道具が要る、というのが技術ノートの説明です。

■ Dijkstra の時期は、目標と確度の幅で示されている

BlockPQR の技術ノートは、Dijkstra の第 1 段階(Ouroboros Linear Leios と入れ子トランザクション)を 2026 年第 4 四半期、第 2 段階(決済を速める投票の層 Ouroboros Peras)を 2027 年第 2 四半期の目標としています。

Intersect は 9 月 5 日の週次アップデート #127 で、技術的な実施計画を再調整した結果として、発効の可能性がある期間を二つの確度で示しました。中程度の確度では 12 月 5 日から 1 月 4 日、高い確度では 2 月 24 日から 3 月 26 日です。ノードは、Leios を除く機能一式を試せる 11.2 が 1 か月以内、Leios を含むハードフォークのリリース候補 11.3 が 1〜2 か月とされています。

二つの書き方は 12 月上旬以降という点で重なり、確度の高い窓は年明け以降にあります。8 月 22 日の記事でお伝えしたとおり、Intersect は日程のリスクをリリース候補が用意できるかどうかに置いていました。9 月 5 日の数字は、そのリスクを期間の幅として書き直したものと読めます。

■ 次に見るもの

  • ノード 11.2 と DijkstraNet の公開: 9 月 5 日時点で「1 か月以内」とされており、10 月上旬までに cardano-node のリリース欄に出るかが最初の手がかりです。SPO が Dijkstra の機能を自分の環境で試し始められる時点でもあります
  • 公開リポジトリでの BlockPQR の作業: 「同じエンジニア、同じコード」という言葉は、cardano-ledger と cardano-node の変更履歴で確かめられます。インデクサーの作業がどこで続くのかも、ここで見えてくるはずです
  • 発効時期の窓: Intersect の週次アップデートで、12 月 5 日から 1 月 4 日という窓が維持されるか、後ろへ動くかを追います

■ ことば

  • 形式手法: システムが守るべき性質を数学的に書き、実装がそれを満たすかを証明やテストで確かめる手法です。台帳の規則が大きく変わる Dijkstra では、変更の前後で壊れていないことを示す道具になります。
  • Ouroboros Linear Leios: ブロックの生産を並列化して処理能力を上げる新しいコンセンサス設計です。取引を運ぶブロック、それを認証するブロック、Praos のチェーンに固定するブロックの 3 種類を使います。仕様は CIP-0164 にまとめられています。
  • Dijkstra: Conway の次にくる台帳エラの名前で、計算機科学者エドガー・ダイクストラにちなみます。ガバナンスが中心だった Conway から、処理能力と容量の拡張へ重心が移ります。

一次ソース / 関連リンク