Cardano の憲法を Dijkstra ハードフォークに合わせて書き足す修正案 CAP-12 について、Intersect の技術運営委員会 (TSC) が 11 月 18 日の会合で、新しい処理方式 Leios を止める「停止スイッチ」を憲法の中に戻すかどうかを審査します。10 月 30 日の第 5 版でいったん消えた仕組みで、ここでの判断が、Leios に不具合が出たときにオンチェーンのガバナンスで止められるかどうかを決めます。
Intersect は 11 月 15 日の週報 #137 で、議論の中心が条文の言い回しから数値の中身へ移ったと伝え、DRep (委任代表者)、SPO (ステークプール運用者)、憲法委員会のいずれにも関わる案件として意見を求めています。この記事では、停止スイッチをめぐる経緯と、あわせて詰められている参照スクリプト手数料・処理能力の引き上げの論点を、CAP-12 のページと議論スレッドの原文から整理します。
CAP-12 が憲法に書き足すもの
CAP-12 の題は「Dijkstra era parameters」です。いまの憲法では、付録 I に名前が載っていないプロトコルパラメータはパラメータ変更の対象にできません (PARAM-01)。一方で HARDFORK-05 は、ハードフォークで新しく変更可能になったパラメータを、ガードレール (変えてよい範囲の決まり) とともに付録へ加えるよう求めています。CAP-12 はこの手当てをする修正案で、対象は次の 3 群です。
- 参照スクリプトの保護 — 2024 年 6 月のサービス妨害 (DoS) 攻撃を受けて台帳に固定値で入っていた上限と手数料の曲線が、Dijkstra で初めてパラメータになります
- Leios のパラメータ — エンドーサーブロックの大きさ、投票の期間、承認に必要なステークの割合など
- プールの経済 — CIP-0023 の最低プールマージンと、CIP-0050 の最大誓約レバレッジ
憲法に載らない限り、これらは Dijkstra の起点で与えられた値に固定されたままになります。CAP-12 は日本時間 10 月 2 日に提出され、10 月 30 日に第 5 版まで改訂されました。議論スレッドには 11 月 16 日時点で 45 件のコメントが付いています。第 5 版では、第 4 版で数値が入っていた 6 つのガードレールが「[PENDING]」に戻され、値はパラメータ委員会が根拠とともに検討してから書き込む方針になりました。
第 5 版で消えた停止スイッチ
第 3 版までの CAP-12 は、エンドーサーブロックに入る取引の大きさの上限 maxEndorserBlockTxsSize を 0 にすることを、Linear Leios を止める方法として定めていました。10 月 14 日のコメントでは、このパラメータが重要パラメータの一覧に入っているため、止めるには憲法委員会と DRep の投票に加え、ブロック生成ステークの過半による SPO の投票 (PARAM-03a) が要り、90 日前の予告 (PARAM-04a) も求められる点が指摘されています。
10 月 30 日の第 5 版は、この仕組みを外しました。Leios のパラメータは 0 にできないと定め、一時的に止める必要があるなら、Cardano ネットワークの災害復旧計画 (CIP-0135) のような、憲法の外の緊急時の計画で扱うべきだとしています。
これに対し、編集者の Thomas 氏は日本時間 11 月 3 日のコメントで、スイッチは「移された」のではなく「取り除かれた」と整理しました。リンクされている仕様書 (10 月 7 日の v1.3) には今も「0 が Linear Leios を止める指定の方法」と少なくとも 7 か所に書かれていること、0 を禁じるガードレールをスクリプトで強制すると、オンチェーンで止める道はガードレールスクリプトの改訂かハードフォークしか残らないことを挙げ、その立場を取るなら分析の本文に明記するよう求めています。10 月 28 日の TSC の報告は定足数に届かず、「何らかの停止スイッチは必要、または有用」という所見にとどまっていました。
11 月 18 日に TSC が審査する立場案
TSC の議長 Kevin Hammond 氏は 11 月 6 日、TSC がこの停止スイッチを次の会合で審査すると書き込みました。ロンドンのノード多様性ワークショップと米国の祝日が重なり、会合は 11 月 18 日になります。同氏は、SPO が個別に参加をやめるという運用上の止め方に加えて、ガバナンスが管理するプロトコル上のスイッチも持つのが理にかなうとしています。
示された立場案は、maxEndorserBlockTxsSize = 0 をネットワーク全体で Linear Leios を止める正式な方法として支持するものです。ただし次の 4 つの条件が付きます。
- 0 のときにエンドーサーブロックの告知・投票・証明書が一切出ず、ノードのふるまいが Praos と同じになることを、Linear Leios のチームが文書で確認する
- Preview と Preprod のテストネットで停止と再開を実際に行い、ブロック生成を Praos の基準と比べて測る
- すべてのノード実装で 0 の設定に対する適合テストを用意する
- ガードレールの条文を、0 を許す形に組み替える
あわせて、深刻度 1 または 2 のネットワーク障害への対応で止める場合に限り、90 日前の予告を免除する「早道」も支持しています。再開は通常の手続きに戻り、予告が外れても批准と施行にはエポックの境目を最低 1 回またぐ、と注記されています。
参照スクリプト手数料と、処理能力の段階的な引き上げ
停止スイッチと並んで詰められているのが、参照スクリプトのガードレールです。週報 #137 によると、公開のレビューで、これらの手数料の設定は 1 つずつ上限をかけるだけでは手数料が急に上がりうるため、まとめて上限をかける必要があると分かりました。提案は、より強い上限と、DoS 対策を弱める変更にはセキュリティ評価の公開を求める内容です。Hammond 氏は 11 月 6 日のコメントで、このレビューを前日にパラメータ委員会へ渡し、より詳しい版を最終承認を担うセキュリティ評議会へ送ったと説明しています。
Leios の処理能力をどう引き上げていくかにも、新しいガードレールが提案されています。1 回ごとの引き上げ幅に上限を置き、ステークプールの準備ができているかを確かめる仕組みで、暫定の費用試算が添えられています。週報はこの部分を SPO が読んでおくべき箇所として挙げています。Leios が今の 3〜5 倍の処理能力から段階的に導入される計画は、Weekly Brief #29 で、台帳側の実装の進み具合は 11 月 14 日の Signal でお伝えしました。
次に見るもの
この案件は、Leios の性能そのものより、障害が起きたときに誰がどの手続きで止められるかを憲法に書くかどうかの話です。0 による停止が憲法に戻れば、止める判断も再開の判断も DRep・SPO・憲法委員会の投票を通ることになり、外されたままなら、止める手段は憲法の外の運用とノードのリリースに委ねられます。ガバナンスが緊急時の権限をどこまで持つかを、条文の 1 行で決める線引きです。
確認できる次の一点は、11 月 18 日の TSC 会合で立場案が承認されるかどうかです。その結果を受けて出る CAP-12 第 6 版では、[PENDING] だったパラメータの値が提案として入る見込みで、CAP の提案ページ (cap.intersectmbo.org の CAP-12) の改訂履歴で、停止スイッチの条文と数値がどう変わったかを追えます。
ことば
- CAP — Constitutional Amendment Proposal の略で、Cardano 憲法の修正案。Intersect のポータルで版を重ねて意見を集め、最終版がガバナンスアクションとしてオンチェーンにかけられます。CAP-12 は Dijkstra で変更可能になるパラメータを、実際に動かせるようにするための修正です。
- ガードレール — 憲法の付録 I で、各パラメータを変えてよい範囲を定めた決まり。ガードレールスクリプトがオンチェーンで機械的に確かめるものと、憲法委員会の判断に委ねるものがあり、今回の停止スイッチは前者で 0 を禁じるかどうかが争点です。
- TSC — Intersect の技術運営委員会。議長の Hammond 氏がパラメータ委員会の立場からも CAP-12 にコメントしており、11 月 18 日の会合で停止スイッチへの立場を決めます。
一次ソース / 関連リンク
CAP-12「Dijkstra era parameters」提案ページと議論スレッド (Intersect CAP ポータル)（cap.intersectmbo.org）
Intersect weekly update #137 (11 月 15 日)
intersectmbo.org
