Pi Network、プロトコル28有効化(10月16日)前にノード期限が経過

10月13日のノード期限が経過

Pi Networkのプロトコル28のリリースノートは、運営者の準備期限を明確な日付で定めた。すべてのメインネットノードに対し、10月16日に予定されたメインネットの有効化に先立ち、2026年10月13日までにバージョン28のソフトウェアを導入するよう求めたのである。プロジェクトのノード手順ページと公式発表が示すインフラ面の主張は二つに整理できる。一つは台帳が取引データの遅延をより確実に処理できるようにすること、もう一つは開発者がスマートコントラクトの一括更新や保存データの変更を、より安全な手順で行えるようにすることだ。9月27日の公開を巡る告知は、プロトコルv28がPiメインネットに到達する日を2026年10月16日とすでに固定していた。期限と有効化は、同じ更新手順の中にあっても別個の出来事である。期限は参加する計算機に互換ソフトウェアの稼働を求める行為であり、有効化はメインネットが従う規則そのものを切り替える行為だ。旧バージョンのまま据え置かれた運営者のノードは、新しい取引規則が発効した瞬間に同期から外れる危険を負う。ところが、ノード手順ページにも告知にも、スループットの計測値も手数料引き下げの数字も、新機能を実際に使う本番コントラクトの一覧も示されておらず、書面の上では性能を検証する材料が何一つ存在しない。主張の内容は製品ではなく配管の話であり、具体的なアプリの開始も、利用者決済の増加も、ステーブルコインの提供も金曜日までに約束されてはいない。NODEの価格もこの仕組みの外にある。期限が扱うのは運営者の端末上のソフトウェア版本数であって、取引量ではない。版本数だけではアプリ利用の実態を測れない。Piが公開した公開手順は段階的に進む。まずソフトウェア配布、次にプロトコル有効化、最後に独立した確認である。10月13日の期限が証明するのは、せいぜい運営者に移行が求められたという事実までだ。実際にどの程度が移行したかは、証明しない。

プロトコル27の前例と版本の隙間

期限の背後にある手順をたどると、各段階が示せることと示せないことが見えてくる。Piはプロトコル28をテストネットへ移す前に、プロトコル27のメインネット更新が成功したと報告している。提案されたソフトウェアは、運営者の締め切り前に試験環境で検証されたわけだ。しかしメインネットの有効化は別の環境である。生の残高、実際の取引、そして互換バージョン上でコンセンサスメカニズムを維持し続けねばならない運営者がそこにはいる。旧プロトコルに取り残されたバリデータは、新しい取引規則の発効後に同期を保てなくなる可能性がある。だから版本の管理は運営者の実務上の課題となり、台帳の出力が途切れないことは利用者側から観測できる試金石になる。複数の相互依存コントラクトから構成されるアプリでは、一つずつ更新すると版本の食い違いが生じ得るため、まとまった更新が意味を持つ。保存データの安全な変更は、既存の残高と権限が新しいコードの下でも解釈可能かという問題に対処する。どちらの仕組みも変更を調整する道具であって、個々のコントラクトの論理を監査するものではない。この周期に先立って公開された開発者向けRPCでは、Web3の構築者にテストネットとの接点を提供したが、文書の存在と実配備は別物だ。アプリは実質的な取引を伴わないまま掲載され得るし、取引カウンタは自動テストで増え得る。プロジェクトは、バージョン28を稼働させるメインネットバリデータの割合について、日付付きの監査可能な数字を公開しておらず、ソフトウェアのダウンロードは稼働と同義ではない。準拠を確定させる材料は、稼働中のコンセンサスノードにおける版本分布と、切替後の台帳出力の継続である。ステーブルコインを巡る議論はこの手順の外にある。プロジェクトによるOpen StandardのOUSDを用いたステーブルコイン活用の検討には開始時期が示されておらず、プロトコル28の資料のどこにも、有効化と同時にOUSD製品を利用可能にする記述はない。利用の関門も残る。PiのKYCと移行の更新情報が示すとおり、メインネットの残高に到達するのは一部の利用者にとってなお途中の工程であり、2026年のロードマップは本人確認、移行、アプリの発見を、プロトコルの更新とは別の段階として列挙している。

10月16日が確認すべきこと

10月16日が自らの材料を生み出すまで、更新履歴そのものが記事の中身である。メインネット台帳の版本と途切れないブロック生成で確認された有効化は、運営者の調整が成立したことを示す。遅延処理や一括更新の機能が公開形式で実演されれば、版本ラベル以上のものが見える。基準は弊紙のビットコンノードの運用手順が述べるのと同じものだ。互換ソフトウェアと観測された出力であり、ダウンロード数ではない。ここでのDYORとは、金曜日の後に台帳版本とブロックの連続性を確認することであって、告知を読み返すことではない。更新の評価はまず技術的主張の真偽に置き、その後で需要の動向に委ねるのが順序である。