カルダノ最大級のアップグレード”CIP-1694”を完全解説

CIP-1694の概要を簡単に掴みたい方はこちらをご覧ください。

概要
なぜこのCIPが必要なのか？
仕様
理論的根拠
アクティブ化に向けての道
その他のアイデア／質問
参考文献

概要

Voltaireの新しい条件に対応するために、カルダノのオンチェーンガバナンスシステムの改善を提案します。既存のプロトコルパラメータの更新とMIR証明書に特化したガバナンスサポートは廃止され、通常のトランザクションボディーに2つの新しい項目が追加されます。

ガバナンスアクション
投票

また、カルダノのユーザーであれば誰でもガバナンスのアクションを提出することができるようになります。また、ガバナンスの枠組みにおいて、異なる役割を持つ3つのガバナンス組織を導入します。

憲法委員会（constitutional committee）
DReps（delegate representatives）
SPO（stake pool operators）

すべてのガバナンスのアクションは、これらの3つのガバナンス組織のうち2つの組織が投票で承認する必要があります。アクションの種類とガバナンスシステムの状態によって、どの組織がアクションを承認しなければならないかが決まります。

承認されたアクションは、明確に定義されたルールに従って、オンチェーンで実行することができます。

ステークプールと同様に、ADA保有者は誰でもDRepに登録することができ、自分自身や他人を代表として選ぶことができます。また、ステークプールと同様に、DRepに登録した人に投票権を委任することもできます。この投票権は、ADAの総保有量に基づきます。

この提案の最も重要な点は、「1Lovelace=1票」という概念です。

なぜこのCIPが必要なのか？

CIP-1694の意義

私たちはヴォルテールの時代に向かっており、分散型の意思決定のための基礎を築いています。このCIPは、カルダノのヴォルテール期を支えるオンチェーンガバナンスの仕組みを記したものです。この資料は、決まった数のガバナンス・キーに基づく、従来のカルダノガバナンスの仕組みを基に拡張したものです。このドキュメントは、価値ある最初のステップを提供するとともに、提案されているヴォルテールのガバナンスシステムの一部を、短期間のうちに技術的に導入することを目指しています。

また、適切な閾値設定やその他のオンチェーン設定など、コミュニティからの意見を継続的に取り入れるための出発点として機能することを目指します。

今後の提案では、新たなガバナンスのニーズを満たすために、この提案を修正・改良する可能性があります。

現在のガバナンスの仕組み

シェリー台帳時代に導入された、オンチェーンカルダノガバナンスの仕組みは、以下のことが可能です。

プロトコルパラメーターの値を変更する（これは「ハードフォーク」の開始を伴う）。
ADAをリザーブとトレジャリーから移動させる（または、リザーブとトレジャリーの間でADAを移動させる）。

現在の仕組みでは、ガバナンスアクションは、ガバナンスキー（Cardanoメインネットの7つのうち5つ）から、Quorum-Many認証を必要とする特別なトランザクションによって開始されます。トランザクション本文には、提案されたガバナンスアクションの詳細が記載されており、プロトコルパラメータの変更、または資金移動の開始のいずれかが書かれています。各トランザクションは正確に1種類のガバナンス・アクションを引き起こすことができますが、1つのアクションが複数の効果を持つこともあります（例えば、2つ以上のプロトコル・パラメータを変更する）。

プロトコルパラメータの更新は、トランザクションボディーのトランザクション項目の「nº6」を使用します。
トレジャリーおよびリザーブの移動は、MIR（Move Instantaneous Rewards）証明書を使用します。

適切に認可されたガバナンス・アクションは、エポック境界で実行（制定）されます。

ハードフォーク

プロトコルパラメータの中には、特別な注意を払うに値するほど重要なものがあります。それは、主要なプロトコルバージョンを変更することであり、これはカルダノの制御されているハードフォークの実行を可能にします。ハードフォークが実行されると、ステークプールは新しいプロトコルバージョンをサポートするためにノードのバージョンをアップグレードしなければならないため、この種のプロトコルパラメーターの変更は特別な地位を占めています。

シェリーガバナンスメカニズムの欠点

現在のデザインは、シンプルで暫定的な方法でガバナンスを提供することを目的としていました。今回のCIP-1694の提案は、Voltaireに移行する際に明らかになった、現在のメカニズムのいくつかの欠点に対処することも目的としています。

シェリーのガバナンスデザインでは、Ada保有者がチェーン上で積極的に関わる余地がありません。プロトコルの変更は通常、選ばれたコミュニティの関係者との議論の結果ではありますが、その処理は主に創設団体によって進められています。また、全員が自分の意見を言えるようにするのは煩雑であり、時には自分勝手な判断と受け取られる可能性もあります。
トレジャリーからの出金は、重要かつ慎重に扱わなければならないテーマです。しかし、その動向を把握するのは困難です。このような動きに対して、より透明性を高め、より多くの人々がチェックできるようにすることが重要です。
SPOによって特別な扱いを受けてはいるが、もはやハードフォークは他のプロトコルのパラメータ変更と区別されるものではなくなっている。
現在、カルダノには、創設団体や多くのコミュニティメンバーが共有するある程度共通しているビジョンがありますが、これらの指針が記録された明確に定義された文書はありません。Cardanoブロックチェーンを活用して、正式なカルダノ憲法として、共有化されたCardanoの理念を不変の方法で記録することは理にかなっています。

CIP-1694の範囲外の問題

以下のテーマは、本提案の範囲外であると考えられます。

憲法の内容
このCIPは、オンチェーンの仕組みにのみ焦点を当てています。最初の憲法の規定は非常に重要であり、憲法を改正するためのプロセスも同様です。ですが、これらはそれぞれ別々に集中して議論をする必要があります。

憲法委員会のメンバー
これはオフチェーンでの問題です。

法的な問題
カルダノプロトコルまたはカルダノ憲法に対する何らかの法的措置の可能性は、本CIPの対象外です。

ガバナンスアクションのためのオフチェーン基準
カルダノコミュニティは、このCIPで定められているガバナンスアクションの作成を扱うための適切な基準やプロセスについて深く考えなければなりません。特に、トレジャリー出金アクションの作成におけるProject Catalystの役割については、本CIPの範囲外であることが明らかです。

ADAの保有と委任
ステークプールやDRepsへの委任を含め、民間企業、公的機関、個人等がどのようにAdaの保有や委任を選択するかは、本CIPの範囲外である。

仕様

カルダノ憲法（Cardano Constitution）

カルダノ憲法は、カルダノの共通の価値観と指針を定義するテキスト文書です。現段階では、憲法はカルダノの核となる価値を明確に捉え、かつ、長期的な持続可能性を確保するための文書として提供される予定です。後の段階では、憲法がスマートコントラクトに基づく一連の規則へと発展し、ガバナンスのフレームワーク全体を牽引していくことが想像されます。しかし今のところ、憲法はオフチェーンの文書であり続け、そのハッシュダイジェスト値はオンチェーンに記録される予定です。上記のように、憲法はまだ定義されておらず、その内容は本CIPの範囲外です。

憲法委員会

憲法委員会とは、憲法を遵守する責任を持つ個人または団体（それぞれEd25519証明書のペアを持つ）の集まりを表すものである。

チェーン上で強制することはできないが、憲法委員会はガバナンスアクションが憲法に適合しているかどうかで投票することになっており、この境界を踏み外した場合は（「不信任の申し立て」によって）交代させられるべきである。別の言い方をすれば、憲法委員会とネットワークの関係者の間には、社会的な合意が存在する。憲法委員会は、ある種のガバナンス・アクションを（それに対して「No」と投票することで）拒否することができるが、そうすべきなのは、ガバナンスアクションがカルダノ憲法に抵触する場合に限られます。

例えば、「カルダノネットワークは常に新しいブロックを生成できなければならない」という憲法ルールを考えた場合、最大ブロックサイズを0にするガバナンスアクションは、事実上、違憲であるため、憲法委員会によって承認されないかもしれません。ですが、この規則では、許容できる最小の最大ブロックサイズを指定していないため、憲法委員会はこの数値を決定し、それに従って投票する必要があります。

不信任状態

憲法委員会は、常時、次の2つの状態のいずれかにあると考えられます。

通常状態（すなわち、信任状態）
不信任状態

不信任状態では、現在の委員会はもはやガバナンスアクションに関与することができず、ガバナンスアクションを承認する前に交代させる必要があります。委員会が不信任状態になると、未処理のガバナンスアクションは直ちに中止され、承認されることはありません。

憲法委員会は、既存の「ジェネシス委任証明書」の仕組みと同様に、ホットキーとコールドキーの設定を使用する予定です。

初期憲法委員会

最初の委員会はまだ定義されていません。可能性としては、カルダノの創設団体の何人かが組み込まれることになるでしょう。

憲法委員会の交代

憲法委員会は、2つの方法のいずれかで交代させることができます。

通常の状態（すなわち信任状態）にある場合、特定のガバナンス・アクション（以下のアクション2）を通じて委員会を交代させることができ、そのためには現在の憲法委員会とDRepsの両方の承認が必要です。
不信任の状態にある場合、同じガバナンス・アクション（以下のアクション2）によって委員会を交代させることができますが、この場合、代わりにSPOとDRepsの両方の承認が必要となります。

憲法委員会の規模

Shelleyのガバナンスデザインとは異なり、憲法委員会の規模は固定ではありません。新しい委員会が選出されるたびに変更することができます（以下のアクション2）。同様に、委員会のクォーラム（ガバナンスアクションを承認するために必要な委員会の賛成票の数）も固定されておらず、ガバナンスアクション2によって変更することができます。これにより、委員会の構成に対して高い柔軟性を持たせることができます。

任期の導入

憲法委員会の任期が切れると、システムは自動的に不信任状態に入ります。この任期はガバナンスに関するプロトコルパラメータであり、委員会がガバナンスアクションを承認できる最大限の期間（エポック数）を指定する。委員会の任期が切れると、すべてのガバナンスアクションは取り下げられ、新たに委員会を選出する必要があります。

同じメンバーが再選され、クォーラムに変化がない場合でも、ガバナンスアクション2が実行されるたびに、任期はリセットされます。これにより、Adaの保有者は、必要であれば、委員会に対しての信頼を確かめることができます。任期は委員会が選出された時点で計算されることに注意して下さい。また、基盤となるプロトコルパラメータの変更は、将来の委員会が該当する任期にのみ影響します。

DReps（Delegated representatives）

CIP-1694のDRepsは、Project CatalystのDRepsと混同しないように気を付けてください。

定義されたDRepオプション

Adaの保有者は、通常、登録されたDRepに投票権を委任し、そのDRepが代理で投票権を行使することになります。また、あらかじめ定義された2つのDRepオプションが用意されています。

棄権（Abstain）：Adaホルダーが棄権（Abstain）に委任した場合、そのステークスはガバナンスに参加しないものとしてアクティブに記録されます。チェーン上で棄権（Abstain）に委任すると、委任されたステークがアクティブな投票権を持つステークに含まれないとみなされます。ただし、ステークを委任することによるインセンティブのために、そのステークが登録されているとみなされます。
不信任：Ada保有者が不信任に委任した場合、そのステークは、不信任の申し立て（アクション1）を除くすべてのガバナンスアクションにおいて、反対票としてカウントされます。これはまた、既存の憲法委員会に対して信頼を置いていないことを示すものでもあります。チェーンで不信任に委任する効果は、このステークがアクティブな投票権を持つステークに含まれるとみなされることです。なぜなら、すべての不信任の申し立てアクションで賛成票、それ以外のアクションで反対票としてカウントされることになるからです。また、このステークは、常に憲法委員会の信頼度を測る指標として機能します。

＊積極的に投票に参加したい場合は、Adaホルダーであれば誰でも、自分のステーク・クレデンシャル（資格）をDRepとして登録し、自分自身に委任することができます。

DRepsの内容

Voltaireでは、既存のステーク・クレデンシャルは、登録されたDRepにステークを委任することもできるようになります。DRepへの委任は、既存のステーク委任の仕組み（オンチェーン証明書による）を真似たものです。同様に、DRepの登録も既存のステーク登録の仕組みと同じです。

登録されたDRepは、以下のようなクレデンシャルで識別されます。

検証キー(Ed25519)
ネイティブスクリプトまたはPlutusスクリプト

シリアル化されたDRepクレデンシャルのblake2b-224ハッシュ・ダイジェストは、DRep IDと呼ばれます。

また、ガバナンスのために、以下の新しいタイプの証明書が追加される予定です。

DRep登録証明書

DRep登録証明書には以下が含まれます。

DRep ID
アンカー

アンカーとは、以下のペアです。

メタデータのJSONペイロードへのURL
メタデータURLの内容のハッシュ化

このメタデータの構造と形式は、このCIPでは意図的にオープンにしています。オンチェーンルールはURLとハッシュのどちらもチェックしません。しかし、クライアントアプリケーションは、提供されたURLからコンテンツを取得する際に、通常の整合性チェックをする必要があります。

DRep退職証明書には以下が含まれます。

DRep ID
DRepが引退するまでのエポック番号
投票委任証明書

投票委任証明書には以下が含まれます。

ステークを委譲するDRep ID
委任者のステーク・クレデンシャル

認証スキーム（登録、引退、委任に必要な署名）は、既存のステーク委任証明書の認証スキームを真似ています。

DRepsにおける新しいステーク配分

既存のステーク・クレデンシャルごとの分配とステーク・プールごとの分配に加えて、台帳はDREPごとのステーク配分も定めるようになりました。この配分によって、DRepのYes投票がどれだけのステークに裏打ちされているかが分かります。

＊ブロック生成に使われるステーク配分とは異なり、Drepでは、エポック境界で与えられたDRepごとのステーク配分の最新版を常に使用します。これは、個々の投票者が深く関心を持つトピックについては、DRepとして登録し、ダイレクトに投票する時間があることを意味します。ただし、ブロック生成に用いられるステークと投票に用いられるステークには、任意のエポックにおいて差が生じる可能性があるので、その点は注意が必要です。

ADA保有者が投票権を委任することによるインセンティブ

ブートストラップフェーズの後、報酬アカウントは、関連するステーク・クレデンシャルがDRep（予め決められたまたは登録済み）に委任しない限り、報酬の引き出しがブロックされます。これにより、高い参加率、つまり正当性を確保することができます。

DRepのインセンティブ

DRepsは、その活動に対して報酬を得る必要があります。インセンティブモデルに関する研究はまだ進行中ですが、このことが解決されるまでの間、本CIPの実装を中断することは望ましくありません。

そこで私たちの暫定的な提案は、この極めて重要な決定がコミュニティによって合意されるまで、既存のカルダノトレジャリーから Lovelace をエスクローし、構築中のオンチェーンガバナンスメカニズムを利用することです。

あるいは、DRepsは、このCIPで説明されているトレジャリー引き出しアクション（アクション6）を通して、自分自身に報酬を支払うという方法もあります。このようなアクションは、オンチェーンでは監査が可能であり、オフチェーンではDRepsと委任者の間の合意を反映する必要があります。

ガバナンス・アクション

ここでは、7種類のガバナンス・アクションを定義しています。ガバナンス・アクションは、トランザクションによって引き起こされるオンチェーンイベントであり、期限を過ぎると実行できなくなります。

アクションは、（以下に詳述するルールとパラメータによって）賛成票が十分に集まると、承認されたとみなされます。
期限までに十分な賛成票が集まらなかったアクションは、期限切れになったとみなされます。
承認されたアクションは、ネットワーク上でアクティブになった時点で、実行（制定）されたとみなされます。

ただし、承認されたかどうかにかかわらず、例えば不信任の申し立てが行われた場合、アクションは実行（制定）されることなく中止されることがあります。

アクション	内容
1. 不信任の申し立て	現在の憲法委員会に対して不信任の状態を作り出すための申し立て。
2. 新しい憲法委員会および／または定足数（クォーラム）のサイズ	憲法委員会のメンバーおよび/または署名の閾値の変更。
3. 憲法の更新	テキスト文書のオンチェーンハッシュとして記録される、オフチェーン憲法の修正。
4. ハードフォークの開始	ネットワークの後方互換性のないアップグレードのきっかけとなるもので、事前にソフトウェアのアップグレードが必要となる。
5. プロトコルパラメータの変更	プロトコルの主要バージョンの変更（「ハードフォーク」）を除く、1つ以上のアップデート可能なプロトコルパラメータの変更。
6. トレジャリーからの引き出し	トレジャリーからの出金で、小口、中口、大口（引き出されるLovelaceの量に基づく）に分類される。トレジャリーからの引き出しの閾値については後述。
7. その他（Info）	オンチェーンの記録以外の、オンチェーンに影響を与えないアクションを指す。

ADAホルダーは誰でもガバナンス・アクションをチェーンに提出することができます。彼らはgovDeposit Lovelaceと呼ばれるデポジットを提供しなければなりませんが、これはアクションが終了（承認されたか、取り下げられたか、期限切れになったか）したときに返却されます。デポジット額は、ステークキーのデポジットと同様に、デポジットポットに追加されます。

なお、不信任の申し立ては、ADAホルダーが現在の憲法委員会に付与された権限を取り消すことができる極めて重要な措置である。この申し立てが承認された場合、委員会が承認したもの、またはこのエポックに承認される予定のものを含む、未処理のガバナンス・アクションはすべて破棄されます。

ガバナンス・アクションの承認

ガバナンス・アクションは、オンチェーンの投票アクションによって承認されます。ガバナンス・アクションの種類によって承認条件は異なりますが、常に3つのガバナンス団体のうち2つが関わっています。ガバナンス・アクションの種類に応じて、以下の組み合わせが発生した場合、アクションは承認されることになります。

憲法委員会がそのアクションを承認する（クォーラム数を満たす多くのメンバーが「Yes」に投票する）。
DRepsがそのアクションを承認する（「Yes」に投票したDRepsが支配するステークが、登録された投票権総数のうち一定の閾値を満たす）。
SPOがそのアクションを承認する（「Yes」に投票したSPOが支配するステークが、登録された投票権の合計のうち一定の閾値を超える）。

＊以下に説明するように、DRepsとSPOsでは異なるステーク分配が適用されます。

ガバナンス・アクション承認の条件

以下の表は、各ガバナンス・アクション・シナリオの承認要件の詳細を示しています。

ガバナンス・アクション・タイプ：プロトコルパラメータの更新は、4つのカテゴリーに分類されることに注意して下さい。
憲法委員会（略称：CC）：値が✓の場合は、クォーラムを超える数の憲法委員会による「Yes」投票が必要であることを示します。値が「-」の場合は、憲法委員会の投票が適用されないことを意味します。
DReps：DRepsは、有効な投票権に対する割合として、満たさなければならないDRepの投票の閾値です。値が「-」の場合は、DRepsの投票は適用されないことを意味します。
SPOs：すべてのステークプールが保有するステークに対する割合として満たさなければならないSPOの投票の閾値。値が「-」であれば、SPOの投票は適用されません。

ガバナンス・アクション・タイプ	CC	DReps	SPOs
1. 不信任の申し立て	–	$P_1$	$Q_1$
2. 新しい委員会・クォーラムの設定（通常状態）	✓	$P_{2a}$	–
2. 新しい委員会・クォーラムの設定（不信任状態）	–	$P_{2b}$	$Q_{2b}$
3. 憲法の更新	✓	$P_3$	–
4. ハードフォークの開始	✓	$P_4$	$Q_4$
5. プロトコルパラメーターの変更、ネットワークグループ	✓	$P_{5a}$	–
5. プロトコルパラメーターの変更、経済（エコノミック）グループ	✓	$P_{5b}$	–
5. プロトコルパラメーターの変更、技術（テクニカル）グループ	✓	$P_{5c}$	–
5. プロトコルパラメータ変更、ガバナンスグループ	✓	$P_{5d}$	–
6. トレジャリーからの引き出し	✓	$P_6$	–
7. その他（Info）	✓	$P_7$	–

＊トレジャリーからの引き出しの場合、アクションが複数の出金を指定している場合は、1回の出金額ではなく、アクションによって出金されるLovelaceの合計額が出金額となります。

これらの閾値はそれぞれガバナンスに関するパラメータです。初期の閾値は、カルダノコミュニティ全体によって決定されるべきです。

＊投票するために積極的に登録されているLovelaceに関して、一部またはすべての閾値を適応させていく方が理にかなっているかもしれません。例えば、閾値は、高いレベルの登録の場合は51％、低いレベルの登録の場合は75％の間で変化することができる、などが挙げられます。さらに、トレジャリーの閾値も、引き出されているラブレスの総量に応じて適応的に設定することができ、あるいは、異なるレベルの引き出しに対して異なる閾値を設定することができる、なども考えられます。

ガバナンス・アクションの衝突

トレジャリーからの引き出しやその他とは別に、同じタイプのガバナンス・アクションが予期せぬ形で互いに衝突しないようにするための仕組みを用意しています。

各ガバナンス・アクションは、そのタイプの前のガバナンス・アクションIDを含まなければなりません。つまり、同じタイプの2つのアクションを同時に実行することは可能ですが、そうなるように意図的に設計されている必要があります。

ガバナンス・アクションの優先順位

今のエポックで承認されたアクションは、次のように優先順位に従い制定されます。

不信任の申し立て
新しい委員会/クォーラムの設定
憲法の変更
ハードフォークの開始
プロトコルパラメーターの変更
トレジャリーからの引き出し
その他（Info）

＊その他（Info）のアクションはプロトコルに影響を与えないので、制定はない。

不信任申し立て、新しい憲法委員会の選出、または憲法改正が承認されると、まだ制定されていない他のすべてのガバナンス・アクション（それが承認されたかどうかにかかわらず）が無効になり、制定されることなく直ちに取り下げられます。ちなみに、中止されたアクションに対するデポジットは、直ちに返却されます。

ガバナンス・アクションのライフサイクル

ガバナンスアクションは、エポック境界でのみ承認が確認されます。承認されると、アクションは制定に向けてステップアップします。

したがって、提出されたすべてのガバナンス・アクションは、以下のいずれかになります。

承認された後、実行（制定）される
承認されたが、より優先順位の高いアクションにより中止される。
エポック数が経過して失効する

デポジットは、次のいずれかに該当する場合、直ちに返却されます。

承認されたアクションが実行（制定）された
アクションが期限切れになった
承認されたアクションが破棄された

いくつかのアクションはすぐに実行され（つまり、同じエポック境界で承認され）、他のアクションは次のエポック境界で初めて実行されます。

ガバナンス・アクション・タイプ	実行（制定）
1. 不信任の申し立て	即時
2. 新しい委員会 / クォーラムの設定	即時
3. 憲法の変更	即時
4. ハードフォークの開始	次のエポック境界
5. プロトコルパラメーターの変更	次のエポック境界
6. トレジャリーからの引き出し	即時
7. その他（Info）	即時

ガバナンス・アクションの内容

すべてのガバナンスアクションには、以下の内容が含まれます。

デポジット額（デポジット額は更新可能なプロトコルパラメータであるため、記録される）
デポジットが返済されたときに受け取るリワードアドレス
アクションを正当化するために必要なメタデータのためのアンカー
同じタイプの競合するアクションとの衝突を防ぐためのハッシュダイジェスト値（前述の通り）

さらに、各アクションは、そのタイプに固有のいくつかの要素を含みます。

ガバナンス・アクション・タイプ	追加データ
1. 不信任の申し立て	なし
2. 新しい委員会 / クォーラムの設定	検証鍵（verification key）のハッシュダイジェストとクォーラム数のセット
3. 憲法の変更	憲法文書のハッシュダイジェスト
4. ハードフォークの開始	新しい（より大きな）主要プロトコルバージョン
5. プロトコルパラメーターの変更	変更後のパラメータ
6. トレジャリーからの引き出し	ステーク・クレデンシャルからラブレス正数へのマップ
7. その他（Info）	–

受け入れられた各ガバナンス・アクションには、それを作成したトランザクション・ハッシュと、それを指すトランザクションボディー内のインデックスからなる固有の識別子（別名、ガバナンス・アクションID）が割り当てられます。

プロトコルパラメーターのグループ化

プロトコルパラメータの変更をグループ化しました。これにより、グループごとに異なる閾値を設定することができ、また、別々の投票に対応できるようになりました。DRepsは、自分の専門分野以外のパラメータ変更については、投票を棄権することができます。ネットワーク、経済、技術パラメータグループは、シェリー、アロンゾ、バベッジの時代に導入された既存のプロトコルパラメータをまとめたものです。さらに、CIP-1694で導入される新しいガバナンスパラメータに特化した新しいガバナンスグループも導入されます。

ネットワークグループは、以下のように構成されます。

最大ブロックボディーサイズ（maxBBSize）
最大トランザクションサイズ（maxTxSize）
最大ブロックヘッダーサイズ（maxBHSize）
プールの引退の最大エポック（eMax）
望ましいプール数（nOpt）
Plutus実行コストモデル（costModels）
シリアル化されたアセット価値の最大サイズ（maxValSize）
最大担保入力数（maxCollateralInputs）
1つのトランザクション内の最大スクリプト実行単位（maxTxExUnits）
1 つのブロック内の最大スクリプト実行単位（maxBlockExUnits）

経済グループは、以下のように構成されています。

最低手数料係数（minFeeA）
最低手数料定数（minFeeB）
委任鍵Lovelaceデポジット（keyDeposit）
プール登録Lovelaceデポジット（poolDeposit）
通貨エクスパンション（rho）
トレジャリーエクスパンション（tau）
プールの固定報酬最低額（minPoolCost）
シリアル化されたUTxOの1バイトあたりの最小Lovelaceデポジット（coinsPerUTxOByte）
Plutus 実⾏ユニットの価格（prices）
スクリプトに必要な担保の割合（collateralPercentage）
プール誓約の影響力（a0）

ガバナンスグループは、このCIPで導入されるすべての新しいプロトコルパラメータで構成されます。

ガバナンス投票閾値 ($P_1$, $P_{2a}$, $P_{2b}$, $P_3$, $P_4$, $P_{5a}$,
$P_{5b}$, $P_{5c}$, $P_6$, $P_7$, $Q_1$, $Q_{2b}$, $Q_4$)
憲法委員会の任期期限
ガバナンスアクションの有効期限
ガバナンスアクションデポジット(govDeposit)
DRep デポジット額 (drepDeposit)

投票について

各投票トランザクションは、以下の内容で構成されます：

ガバナンスアクションID
役割 – 組織委員会メンバー、DRep、SPO
役割に関するガバナンス・クレデンシャルの証人
投票に関連する情報のアンカー（上記で定義）。
賛成／反対／棄権の投票

SPOおよびDREPの場合、（「賛成」「反対」「棄権」のいずれであっても）投じられる票数は、アクションが承認チェックされる時点で委任されているLovelaceに比例します。憲法委員会メンバーについては、各メンバーが1票を持ちます。

＊「棄権」票は「有効投票数」に含まれません。明示的な棄権票は投票権の放棄とは異なることに注意してください（前者はチェーン上で見えるが、後者は見えない）。混乱を避けるため、これ以降「棄権」という言葉は、チェーン上での棄権票を意味するものとしてのみ使用することにします。

ガバナンス・クレデンシャルの証人は、既存のUTxOW台帳ルールに従って、台帳の適切な検証を引き起こします。（すなわち、検証キーの署名チェック、およびスクリプトのための特定の投票証人と新しいPlutusの目的によるバリデーターの実行）。

投票は、単一のクレデンシャルによって、各ガバナンス・アクションに対して複数回行うことができます。正しく提出された票は、同じクレデンシャルおよびロールに対する古い票を上書きします。つまり、投票者は、必要に応じて、どのアクションに対しても自分の意見を変更することができます。ガバナンス・アクションが承認されると同時に、投票は終了します。それ以降の投票は考慮されず、記録されません（「はい」、「いいえ」、「棄権」のいずれであっても）。

ガバナンスの状態

ガバナンス・アクションがチェーンに正常に提出されると、その進捗は台帳によって追跡されます。特に、以下のものが追跡されます。

ガバナンス・アクションのID
アクションが期限切れになるエポック
入金額
デポジットが返却されたときに受け取る報酬アドレス
このアクションに対する憲法委員会の賛成/反対/棄権の合計値
このアクションに対するDRepsの賛成票/反対票/棄権票の合計値
このアクションに対するSPOの賛成/反対/棄権の合計値

期限切れの投票

DRepsとSPOからの投票は、エポック境界を越えると登録されなくなり、無意味になる可能性があります。したがって、新しい投票を検討する前に、登録されていないすべての投票をキャンセルします。

ステーク・スナップショットの更新

ステーク・スナップショットは各エポック境界で更新されるため、承認されていないガバナンス・アクションが承認されたかどうかをチェックするときに、新しい記録を算出する必要があります。つまり、DRepやSPOの票が変わっていなくても、アクションが制定される可能性があるということです（票の委任が変更された可能性があるため）。

投票権に関連する定義

投票権に関連するいくつかの定義をします。

トランザクションアウトプットに含まれるLovelaceは、以下の場合、投票のためにアクティブであるとみなされます。
・登録されたステーク・クレデンシャルが含まれている。
・登録されたステーク・クレデンシャルが、その投票権を登録された DRep に委任している。
ある割合Pに対して、ガバナンス・アクションに「賛成」票を投じるDReps（SPO）に委任された相対的なステークの合計から、ガバナンス・アクションに「反対」票を投じるDReps（SPO）に委任された相対的なステークの合計を引いたものが少なくともPであれば、DRep（SPO）の投票閾値を満たしたことになる。

＊「流通するステーク総数」については、いくつかの別の定義があります。

UTxOとリワード・アカウントの合計。
UTxO、報酬アカウント、手数料ポット、およびデポジットポットの合計。
Adaの総供給量（すなわち450億Ada）から埋蔵量を差し引いたもの。

今のところ、この選択肢については議論の余地があります。

理論的根拠

憲法委員会の役割

一見すると、憲法委員会はDRepsに対して特別な権限を与えられた特別な委員会のように見えますが、DRepsはいつでも憲法委員会を交代させることができ、DRepの投票もすべてのガバナンス・アクションを承認するために必要なので、憲法委員会はDReps以上の権限はありません（むしろ、少ないかもしれない）。このように考えると、委員会はどのような役割を果たし、またなぜ必要なのでしょうか。その答えは、委員会が新しいガバナンスの枠組みの立ち上げの問題を解決してくれるからです。実際、私たちが引き金を引いてこの枠組みがオンチェーンで活動できるようになると、憲法委員会がなくても、システムがSPOの投票だけに依存しないように、十分なDRepsが急速に必要になるでしょう。コミュニティがどれだけ積極的にDRepsに登録するか、また他のAdaホルダーが票の委任にどれだけ反応するかは、まだ予測できません。

したがって、憲法委員会は、システムが現在の状態から、やがて完全な分散型ガバナンスに移行できるようにするために存在しているのです。さらに、長い目で見れば、委員会は、ガバナンスの決定において、その判断と指導のためにスポットライトを浴びる選ばれた代表者の集合体であることによって、ガバナンスの決定において指導と助言の役割を果たすことができます。何よりも、委員会は常に憲法を遵守し、憲法の規定に従って議案を承認することが求められています。

身分証明の意図的な省略

このCIPでは、憲法委員会やDRepsのメンバーの身元確認や検証について一切触れていないことに注意してください。

これは意図的なものです。

私たちは、コミュニティが、自分を識別するためにDIDのようなものを提供するDRepsにのみ投票し、委任することを強く検討することを望んでいます。しかし、身元確認を実施することは、中央集権的な機関なしでは非常に困難であり、これは不適切な方向への一歩だと考えています。

ADAを大量に持つ存在への影響力を抑える

二次投票（Quadratic voting）のような仕組みは、大きな影響力を持つ存在から身を守るために存在します。しかし、「1ラブレス、1投票」に基づくシステムでは、ステークを少量に分割し、その対策を覆すことは些か容易です。オンチェーンでの本人確認システムがなければ、このような対策は採れません。

ステークプールのステーク分配に便乗する

CardanoプロトコルはProof-of-Stakeコンセンサスメカニズムに基づいているため、ステークベースのガバナンスアプローチを使用することは賢明です。しかし、参加者間のステーク分配を記録する方法を定義するために使用できる多くの方法があります。1つはアドレスで資金のロックを解除できる人を識別するためのもの（別名：支払いクレデンシャル）、もう1つはステークプールに委任することができるもの（別名：委任クレデンシャル）です。

第3のクレデンシャルセットを定義するのではなく、既存の委任クレデンシャルを再利用し、新しいオンチェーン証明書を使用してガバナンスステークの分配を決定することを提案します。これは、DRepsのセットがSPOのセットと異なる可能性がある（そしておそらくそうなる）ことを意味し、バランスをとることができます。例えば、ウォレットソフトウェアのプロバイダーは複数の委任スキームをサポートしなければならず、Adaの保有者が複数のDRepに委任したい場合、ステークをサブアカウントに分割することを容易にしなければなりません。

しかし、この選択は、ウォレットプロバイダーの将来の実装労力を抑え、エンドユーザーがガバナンスプロトコルに参加するために必要な労力を最小限に抑えることにもなります。後者は、この決定を正当化するために非常に重要な懸念事項です。既存の構造を利用することで、システムはユーザーにとって馴染みのあるものになり、セットアップが非常に簡単になります。これにより、ガバナンスの枠組みが成功する可能性と参加率の両方が最大化されます。

ハードフォークの開始と一般的なプロトコル・パラメータの変更の分離

他のプロトコルのパラメータ更新とは対照的に、ハードフォーク（より正確には、プロトコルの主要バージョンナンバーの変更）は、より多くの注意を必要とします。実際、他のプロトコルパラメータ変更はソフトウェアの大幅な変更なしに実行できるのに対し、ハードフォークは、ネットワークの超多数が、アップグレードによって導入される新しい機能セットをサポートするためにCardanoノードをアップグレードすることを前提としています。つまり、ハードフォークが発生するタイミングは、すべてのカルダノユーザーに余裕をもって伝えなければならず、ステークプール運営者、ウォレットプロバイダー、DApp開発者、ノードリリースチームの間で調整が必要です。

したがって、この提案は、シェリー方式とは異なり、ハードフォークの開始を、プロトコルパラメータの更新とは異なる独立したガバナンスアクションとして進めるものです。

DRepsの目的

この提案では、SPOがDRepsになることは制限されていません。なぜDRepsがあるのでしょうか？その答えは、SPOは純粋にブロック生成のために選ばれるのであって、すべてのSPOがDRepsになりたいと思うわけではないからです。投票者は、DRepsが優れたブロック生成者であるかどうかを考慮する必要なく、DRepsに投票を委ねることができ、SPOはAdaホルダーを代表するかしないかを選択できます。

承認条件

承認条件について説明します。ほとんどのガバナンス・アクションは、同じような条件を備えています。すなわち、憲法委員会はクォーラム数に達し、DRepsは十分な数の「賛成」票に達しなければなりません。この条件は以下のアクションに当たります。

新しい委員会/クォーラム（通常の状態）
憲法の更新
プロトコル・パラメータの変更
トレジャリーからの引き出し

不信任の申し立て

不信任の申し立ては、カルダノコミュニティが現在の憲法委員会に信頼を置いていないことを表し、したがって憲法委員会はこのガバナンス・アクションに一切の異議を唱えられないようにすべきです。この状況では、SPOとDRepsがコミュニティの意思を代表することになります。

新しい委員会／クォーラム（不信任の状態）

不信任案と同様に、憲法委員会の選出は、SPOとDRepsの両方がコミュニティの意志を代表することになります。

その他（Info）ガバナンス・アクションの多用途性

チェーンを拘束するものではありませんが、その他（Info）ガバナンス・アクションは様々な場面で活用できます。例として以下のような場面で活用できます。

CIPの承認
新しい元帳時代のジェネシスファイルの決定
将来の提案のための初期フィードバック

ハードフォークの開始

どのようなガバナンスメカニズムであっても、ハードフォークにはSPOの参加が必要です。このため、ハードフォーク開始のガバナンスアクションでは、常に彼らの投票を要求することで、彼らの協力を明確にしています。憲法委員会も投票し、ハードフォークの適法性を表明します。DRepsも投票することで、すべてのステークホルダーの意思を代弁します。

新しいメタデータ構造

ガバナンス・アクションと投票の両方が、URLと整合性ハッシュ（ステークプール登録のメタデータ構造をミラーリング）の形で、新しいメタデータ・フィールドを使用します。メタデータはコンテキストを提供するために使用されます。例えば、憲法委員会による投票では、なぜそれが憲法に沿ったものであるのかの説明が必要です。ガバナンス・アクションには、なぜそのアクションが必要なのか、どんな専門家に相談したのか、などの説明が必要です。トランザクションサイズの制約によってこの説明データが制限されるのは避けたいので、URLを使っています。

しかし、これには新たな問題が潜んでいます。もしURLで解決しない場合、その行動に対する投票に何を期待すべきなのだろうか。全員が「棄権」に投票することを期待すべきなのでしょうか？これはガバナンスシステムに対する攻撃要因になるのでしょうか？そのようなシナリオでは、ハッシュの予備イメージを他の方法で伝えることもできますが、そのような状況に備えておくべきです。チェーン上に妥当性の要約を示すべきでしょうか？

代替案：トランザクションメタデータの使用

トランザクションフォーマットに特定の専用フィールドを設ける代わりに、既存のトランザクションメタデータフィールドを利用することが考えられます。

ガバナンス関連のメタデータは、CIP-10のメタデータラベルを登録することで、明確に識別できるようになります。その中で、メタデータの構造は、このCIP（正確なフォーマットは未定）によって、投票や提案のIDと対応するメタデータのURLやハッシュをマッピングするインデックスを使って決定することができます。

これにより、トランザクションボディーに新たなフィールドを追加する必要がなくなり、提出者が無視しやすくなるリスクも回避できる。しかし、要求されるメタデータは空でもよい（あるいは解決しないURLを指す）ので、提出者がメタデータを提供しないことはすでに容易であり、このことが状況を悪化させるかどうかは不明です。

トランザクションのメタデータは元帳の状態に保存されないので、この代替案ではメタデータをアクションや投票と組み合わせるのはクライアント次第であり、元帳の状態のクエリとして利用することはできないことに注意してください。

有効なガバナンス・アクションの数をコントロールする

ガバナンス・アクションは誰でも提出できるため、投票を担当する個人が提案の洪水で圧倒されるのを防ぐためのメカニズムが必要です。多額のデポジットはそのような仕組みの一つですが、これは一部の人がアクションを提出する際の障壁となるという不都合な代償を伴います。しかし、Plutusスクリプトによるクラウドソーシングは、デポジットを集めるためのオプションとして常に存在することに留意してください。

その代わりに、常に多数のアクションがアクティブになる可能性を受け入れ、代わりに有権者の注意をそれに値するものに導くために、チェーン外の社会化に頼ることもできます。このシナリオでは、憲法委員会は、DRepsからすでに十分な票を集めた提案のみを検討することを選択するかもしれません。

AVSTなし

このCIPの以前の草案には、「active voting stake threshold」、つまりAVSTという概念が含まれていました。その目的は、各投票の正当性を確保することであり、例えば10人中9人のLovelaceがCardano上の数百万人の存在の運命を決定できる可能性を排除することでした。ここには2つの重要な懸念があり、分けて考える余地があります。

第一の懸念は、システムのブートストラップ、すなわち、十分な数のステークが投票に登録される最初の瞬間に到達することである。第二の懸念は、時間の経過とともに参加者が減少する可能性があることです。また、AVSTの問題点のひとつは、SPOにとって、低い投票登録数を望むインセンティブを与えてしまうことです（そうすれば、彼らの票はより重みを持つからです）。これは、既存のSPOを非難しているわけではなく、インセンティブが悪いという問題です。

そこで私たちは、この2つの問題を異なる方法で解決することを選択しました。ブートストラップの問題は、ブートストラップに関するセクションで説明するように解決します。そして、ステークがDRep（「棄権」と「不信任」という2つの特別なケースを含む）に委任されない限り、報酬の引き出しを（ブートストラップ期以降）許可しないことによって、長期参加問題を解決します。

アクティブ化に向けての道

採用にあたって

上記仕様を実装したCardanoメインネットにおいて、新しい台帳時代が実現されます。

実装計画

このCIPの機能はハードフォークを必要とします。

この文書は、Cardanoのガバナンスに対する壮大な変更について記述しています。私たちは、1回のハードフォークで変更を実装することを提案します。

以下のセクションでは、すでに特定されているさまざまな実装作業項目についての詳細を説明します。さらに、最後のセクションでは、最終的に解決する必要があるいくつかの未解決の質問を明らかにします。これらの疑問は、コミュニティのワークショップや議論を通じて解決されることを期待します。

本提案の採択

本提案の採択は、最終的なガバナンスの枠組みがどうあるべきかを検討するために、何らかのガバナンスの枠組みが必要であるという、ある種の循環型問題である。何度も述べているように、CIPは権威あるものではなく、ガバナンスのメカニズムでもありません。むしろ、専門家のコミュニティによって（技術的な観点から）健全とみなされた技術的な解決策を記述するものです。

CIP-1694は、間違いなくCIPプロセスの通常の範囲を超えており、何らかのプロセスを通じてこのCIPを承認することが強く望まれています。しかし、そのプロセスはまだ定義されておらず、未解決の問題であり続けています。

最終的なプロセスは、以下のような様々なアイデアを融合したものになると思われます。

2023年2月から3月にかけて行われたコロラド州のワークショップのような、コミュニティで開催されるワークショップで意見を収集する。
十分な参加者を得て、公開テストネットで投票アクションを実施する。
既存のSPOを対象に投票を行う。
Project Catalystを活用し、既存の投票コミュニティ（アクティブな参加者は少ないが）から意見を集める。

トランザクションボディーの変更

トランザクションボディに新しい要素が追加され、既存のアップデート機能およびMIR機能は削除されます。特に、ガバナンスアクションおよび投票は、2つの新しいトランザクションボディに項目を追加することになります。
既存の証明書に加え、新たに2種類の証明書が追加されます。
・DRep登録
・DRep登録解除

同様に、現在のMIRとgenesisの証明書は削除されます。

Plutusのスクリプト・コンテキストに、新しい投票機能が追加されます。これにより、特にオンチェーンスクリプトへの投票が可能になります。

＊これらの変更のそれぞれについて、CDDL仕様が提供される予定です。いつも通りです。

既存の台帳ルールの変更点

PPUP 移行ルールは書き換えられ、UTxO ルールから LEDGER ルールに移動し、新しい TALLY ルールとして導入されます。このルールは、ガバナンス・アクションと投票を処理し、それらを承認し、ガバナンス・アクションを現在のエポックまたは次のエポックで制定するためのステージを適切に設定します。
NEWEPOCH移行ルールが修正されます。
MIRサブルールは削除されます。
新しいRATIFYルールが導入され、ガバナンスアクションを制定するためのステージングが行われます。
新しいENACTMENTルールは、EPOCHルールの直後に呼び出されます。このルールは、以前に承認されたガバナンス・アクションを制定します。
EPOCHルールでは、NEWPPサブルールの呼び出しや、PPUP状態でのクォーラム数達成の有無の計算が行われなくなります。

ローカルステート・クエリ・プロトコルの変更

オンチェーンでのガバナンスの作業負荷は大きいですが、ツールやアプリケーションなどのオフチェーンでの作業負荷は、間違いなくさらに大きいものになるでしょう。効果的なガバナンス・エコシステムを構築するために、台帳は様々なガバナンス要素に対してインターフェースを提供する必要があります。

投票とDReps（de）登録はブロックで直接見ることができ、したがって既存のローカルチェーン同期プロトコルでアクセスすることができますが、ブロックから推測するのが難しい情報（つまり台帳の状態を維持する必要があるもの）についてのさらなる手掛かりを提供するために、ローカルステートクエリープロトコルをアップグレードする必要があると思われます。新しいステート・クエリは、（少なくとも）以下をカバーする必要があります。

現在制定が進められているガバナンス・アクション
承認中のガバナンスアクション（賛成票、反対票、棄権票の合計と割合）
現在の憲法委員会、および憲法ハッシュダイジェスト

ブートストラップ段階

このまだ始まったばかりのガバナンスをどのように立ち上げるかは、慎重に判断する必要があります。関係者全員が登録し、手続きに慣れるために十分な時間が必要です。

最初の立ち上げ段階では、特別な条項が適用されます。第一に、立ち上がりの段階では、憲法委員会のクォーラムを満たせば、プロトコルのパラメータを変更することができます。第二に、立ち上げフェーズでは、ハードフォークを開始するには、憲法委員会のクォーラム投票と、十分なSPO投票があれば十分です。ブートストラップフェーズでは、他のアクションは不可能です。

ブートストラップフェーズは、以下のいずれかが発生した時点で終了します。

十分な量のステークがDRepsに委任された時
一定のエポック数が経過したとき（ハードフォークから数カ月後と思われる）

最終的な安全対策、ブートストラップ後

多くの人が、実際の投票数はシステムのスループットに負担をかけるほど大きくはないと考えている、と述べています。しかし、ブートストラップ段階が終了した時点で、最後の一時的な安全対策を行う予定です（これにより、DRepのデポジット額を低く設定することを可能にすることもできます）。

「X」と「Y」の値がまだ決まっていない場合、ブートストラップフェーズが終わり次第、次のエポック境界のDRepsのステーク配分を計算する際に、ステーク額で「上位X～」に入るDRepsか、少なくとも「Y」のLovaceを持つDRepだけを考慮します。エポックごとにXの値は増加し、Yの値は減少するため、最終的にXは実質無限大、Yはゼロになります。なお、これはあくまでインセンティブであり、DRepが投票することを妨げるものではありません（ただし、要件を満たしていない場合はカウントされません）。

ある時点でコミュニティが実際に混雑の問題があると判断した場合、DRepの数をより厳しく制限するハードフォークが制定される可能性があります。

Xの初期値の妥当な数値は、おそらく5,000～10,000でしょう。Yの初期値の妥当な数値は、Lovelaceの総数をXの初期値で割った値でしょう。

メカニズムは、半年から1年後に制限が完全になくなるような速度で緩和するようにする必要があります。

その他のアイデア／質問

誓約金（Pledge）によるSPOの重み付け投票

SPOの投票に、各SPOの誓約金（Pledge）の重み付けを追加することができる。これは、文字通りゲームに利害関係のある人がより強い票を持つことを可能にするメカニズムを提供するものです。重み付けは慎重に行われる必要があります。

DREPの自動再委任

DRepは、登録証に別のDRepのクレデンシャルを記載することができます（オプション）。DREPが引退すると、DREPのすべての委任状が自動的にそのDREPのクレデンシャルに移されます。そのDRepがすでに引退している場合、委任状は「Abstain」DRepに移されます。

DRep登録なし

DRep登録は不要な機能であるため、DRepを登録するための証明書を取り除くという選択肢もあります。DRep登録証明書の一部であるアンカーをトランザクションのメタデータに移動するコストがかかるが、この措置により、官僚主義がなくなり、DRepデポジットの必要性もなくなるため、さらに流動的な民主主義になります。

一部のガバナンス・アクションのデポジットを削減

ガバナンスアクションに付随するデポジットは、真剣でないガバナンスアクションの氾濫を防ぐために存在し、それぞれのアクションはカルダノコミュニティからの時間と意識を必要とします。私たちは、合意されたオフチェーンプロセスを経た提案について、このデポジットを減らすことができます。これは、少なくとも1人の憲法委員が承認することで、オンチェーンに表示されることになります。このアイデアの欠点は、憲法委員会に大きな権力を与えることです。

ハードフォーク提案に（将来の）ジェネシスコンフィギュレーションのハッシュを含む

ハードフォークの中には、新しいジェネシスコンフィギュレーションを必要とするものがあります。これは、ShelleyとAlonzoのハードフォークがそうでしたし（Allegra, Mary, Vasil, Valentineはそうではありません）、将来もそうかもしれません。現時点では、この提案はこのようなジェネシスコンフィギュレーションについて何も述べていません。暗黙のうちに、これはオフチェーン契約であると仮定されています。しかし、特定のジェネシスコンフィギュレーション（のハッシュ）がハードフォークガバナンスアクションに含まれることを強制することは可能です。