Draft Cardano Constitution - Japanese Version - 2024年7月29日時点 Cardano 憲法 ドラフト版 日本語訳

日本語 エデュケーション
, ,
1

皆様
いつも大変お世話になっております。
2024年7月29日時点でIntesectが公開したCardano暫定憲法（ドラフト版を日本語に翻訳しました。
Cardanoのオンチェインガバナンスについて深く学びたい方々は以下のリンクにてご参考ください。
※日本語翻訳の品質を改善していきたいので、修正すべきなところがありましたら教えていただけばありがたいです。 :bowing_woman: :bowing_woman:
英語版（原本）：

日本語翻訳版：

※日本語翻訳の品質を改善していきたいので、修正すべきなところがありましたら教えていただけばありがたいです。 :bowing_woman: :bowing_woman:

下書き

29.07.24

CARDANO ブロックチェーン エコシステム憲法

序文

当初、Cardano ブロックチェーン エコシステムは、IOHK、Emurgo、Cardano Foundation の 3 つの先駆的団体の協力によって形成されました。彼らは力を合わせて新しいブロックチェーンであるCardano ブロックチェーンの誕生を育み、個人に力を与え、コラボレーションとイノベーションを促進する分散型ネットワークの基礎を築きました。彼らの先駆的な取り組みは、すべてのメンバーがエコシステムの成長と成功に貢献できる公平で透明な環境を確保するように設計されたブロックチェーンへの道を形作ってきました。

時間の経過とともに、Cardano ブロックチェーン エコシステムは大幅に拡大し、現在では何千もの ADA 保有者、個人、ビルダー、開発者、企業、ステークプール、Cardano Blockchain ユーザーなどで構成される Cardano ブロックチェーン エコシステムは、真に分散化された方法で運営され、Cardano ブロックチェーン エコシステムの回復力と自律性がさらに強化されています。

Cardano ブロックチェーン エコシステムが成長し続けるにつれ、Cardano ブロックチェーン エコシステムの開始以来の礎である分散化、コミュニティ参加、包括性、コラボレーションの原則を反映し、同様にそのガバナンスモデルを適応させ、進化させることが不可欠となっています。

より強固でダイナミックなガバナンスの枠組みが必要であり、ガバナンスのプロセスにおいて可能な限り有益なブロックチェーン技術を活用する必要があることを認識し、Cardanoコミュニティは、この分散型Cardanoブロックチェーンエコシステムのメンバーとして、ここに本Cardano憲法を制定する。この憲法は、私たちの集団的な取り組みの運営とガバナンスの指針となる一連の原則となり、すべての参加者がCardano ブロックチェーン エコシステム全体の向上に貢献できる環境を醸成するものとします。

この憲法を採用することにより、カルダノ ブロックチェーン エコシステムは強固なガバナンス フレームワークを確立し、カルダノ コミュニティの最善の利益に基づいて意思決定が行われるようになります。 Cardano コミュニティは、透明性、公開性、責任あるガバナンスの原則を遵守し、信頼と協力の文化を促進します。 Cardano コミュニティは、これらの原則を守り、Cardano ブロックチェーンとして知られる分散型ブロックチェーンエコシステムの継続的な改善、成長、成功に向けて協力することを約束します。

この憲法は、分散型Cardano ブロックチェーン エコシステムの運用とガバナンスに関するこれらの指針を具体化したものであり、Cardano コミュニティの継続的なニーズに対応するために時間の経過とともに適応し進化する基盤を提供します。

Cardano コミュニティのすべてのメンバーは、この憲法を遵守することが期待されており、ガバナンスプロセスに参加する権利を持ち、Cardano ブロックチェーンエコシステム全体を改善し、その成長、持続可能性、成功に貢献するために協力することが奨励されています。 Cardano ブロックチェーンは投票ベースの意思決定モデルによって管理され、包括性、視点の多様性、革新性、適応性を促進します。

すべてのADA保有者は、分散型Cardanoブロックチェーンエコシステムのガバナンスと方向性に貢献する機会を得ることができます。

この憲法に取り組むにあたり、これが単なるブロックチェーンの憲法ではなく、ブロックチェーン エコシステムの憲法でもあり、より野心的な取り組みであることを覚えておくことが重要です。したがって、ガバナンスアクションをどのように承認するかということは極めて重要ではありますが、この憲法の唯一の焦点では​​ありません。むしろ、この憲法は、Cardanoブロックチェーンエコシステムにおけるすべてのアクターが、自らを統治し、人間同士の相互作用と協力に対する根本的に新しいアプローチを形成できる基本的な基盤と枠組みを提供します。

必然的に、この憲法は、憲法委員会の役割を認識し、権限を与え、Cardanoコミュニティが協力のための団体に参加する権利を確認し、オンチェーンガバナンスを実装し、DRepsがオンチェーン投票のADA保有者の代弁者として機能する権限を与えます。

憲法はまた、この憲法にカルダノガードレールを含めることにより、Cardanoトレジャリーへのアクセスと使用を保護する必要性を認識しています。

第１条 CARDANOブロックチェーンの原則とガードレール

第１項

以下の原則は、憲法委員会を含むCardanoブロックチェーンエコシステムのすべての参加者の指針となり、提案されたガバナンスアクションはこれらの原則に照らして評価されます。

Cardano ブロックチェーン上のトランザクションは遅くなったり検閲されたりしてはならず、意図された目的のために迅速に提供される必要があります。 Cardano ブロックチェーンは、スループット、シャーディング、決済、変動料金制を考慮して拡張する必要があります。

Cardano ブロックチェーン上の取引コストは予測可能で、不合理であってはなりません。Cardano ブロックチェーンは、アクセスしやすく予測可能な価格設定モデルを促進する必要があります。

Cardano ブロックチェーン上でアプリケーションを開発および展開したいと考えている人は、意図したとおりにアプリケーションを開発および展開することを不当に妨げられるべきではありません。 Cardano コミュニティは、デジタル加入者回線、形式的検証サポート、非同期でスケーラブルなロケーション サービス、データ フィード データ、パートナー チェーンへのアクセスなど、アプリケーションの開発と展開をサポートする機能を促進する必要があります。

Cardano ブロックチェーンにおける Cardano コミュニティの貢献は、SPO や DRep との報酬共有、適切なトークンノミクス、マルチリソース コンセンサス アプローチを通じて、Cardano コミュニティによって公正に認識され、記録され、評価されるべきです。

Cardano ブロックチェーンは、ADA 所有者の同意なしにその価値をロックインしてはなりません。Cardano ブロックチェーンは、相互運用性とパートナー チェーンへのアクセスを促進する必要があります。

Cardano ブロックチェーンは、ADA 保有者が Cardano ブロックチェーンに保存しようとするあらゆる価値と情報を安全に保存します。価値と情報を安全に保護するために、Cardano ブロックチェーンは整合性、耐量子セキュリティ、分散化と分散ストレージ、ステーブルコインへのアクセス、および堅牢な鍵管理方法に焦点を当てる必要があります。

Cardano ブロックチェーンはリソースを不必要に浪費すべきではありません。 Cardano ブロックチェーンは、効率的な設計、メモリ、ストレージを促進する必要があります。

すべてのCardano ブロックチェーン ユーザーは、Cardano ブロックチェーンの持続可能性と長期的な存続可能性に従ってCardano コミュニティの集合的な要望を考慮しながら平等に扱われるものとます。持続可能性と長期的な存続可能性は、公平性、中立性、持続可能性、強固なガバナンス、分散型アイデンティティの促進、マルチリソースのコンセンサスの使用、Cardanoコミュニティメンバー全員の民主的参加など、多くの要素によって評価されます。

ワークショップでの質問

  • これらの原則はCardanoブロックチェーンの真の精神を反映していると思いますか? 財務的な持続可能性に対応する別の原則を設けるべきですか？もしそうなら、どのような内容を含めるべきですか？流通する ADA の供給量に絶対的な上限を設けるべきですか?

第２項

Cardanoブロックチェーンは、本憲法のガードレール付録に定めるCardanoブロックチェーンガードレールに従って運用されるものとする。Cardanoコミュニティは、随時、特定のCardanoブロックチェーンガードレールをデジタルコード化し、そのようなCardanoブロックチェーンガードレールがオンチェーンスクリプトまたは組み込みledgerルールを使用してCardanoブロックチェーン上で直接プログラムされ実装されるようにすることができます。

ガードレール付録に記載されているCardano ブロックチェーン ガードレールと、Cardano ブロックチェーン上でプログラムおよび実装されているCardano ブロックチェーン ガードレールとの間に矛盾がある場合、カルダノ ブロックチェーン上に直接展開されているCardano ブロックチェーン ガードレールのバージョンが優先され、憲法委員会は適切なオンチェーン ガバナンス アクションの促進を通じて、そのような矛盾を調整するよう努めるものとします。

第２条 CARDANOブロックチェーンコミュニティ

第１項

Cardanoブロックチェーンを使用し、これに参加し、その恩恵を受けるためには、正式なメンバー資格は必要ないものとします。その代わり、ADA保有者、Cardanoブロックチェーンの開発者、Cardanoブロックチェーンを構築する者、Cardanoブロックチェーンをサポート、維持、または使用する者はすべて、Cardanoブロックチェーンエコシステムの受益者であり、Cardanoコミュニティのメンバーとなります。したがって、すべてのCardanoコミュニティメンバーは、この憲法の受益者であり、その権利、特権、および保護を受ける権利があり、そのようなものとして、この憲法を支持し、守ることが期待されています。

第２項

ADAを所有するCardanoコミュニティのメンバー（およびその指名された被指名人）は、投票やCardano ブロックチェーンに関するオンチェーンガバナンスへの参加など、Cardano ブロックチェーン エコシステムのオンチェーン意思決定プロセスにアクセスし、参加する権利があります。

ワークショップの質問

  • オンチェーンガバナンスへの参加はADA保有者のみに限定されるべきでしょうか、それともADA保有者がオンチェーンガバナンスに参加する資格を持つ指定者を任命できるようにすべきでしょうか? [これは DRep への委任についての言及ではないことに注意してください]

第３項

Cardano コミュニティのメンバーは、本憲法に従い、Cardano ブロックチェーン ネットワークを運営し、Cardano ブロックチェーン ガバナンス活動に参加し、公正かつ透明な方法で紛争を解決することにより、Cardano ブロックチェーン エコシステムの完全性を維持する責任を負います。

第４項

Cardanoコミュニティは、本憲法の規定を通じて、Cardanoコミュニティ向けのアプリケーションの開発、維持、構築に協力し、CardanoコミュニティがCardano ブロックチェーン エコシステムをサポートするために望ましい、または適切であると判断した場合に、一時的または永続的な組織や団体を結成する権利と奨励を受けます。

第３条 参加型ガバナンス

第１項

Cardano ブロックチェーンのエコシステムは、オンチェーンの分散型ガバナンス モデルによって管理され、可能な範囲で有益なスマート コントラクトやその他のチェーンベースのツールを使用して意思決定を促進し、透明性を確保します。ガバナンスアクションに対するオンチェーン投票は、Cardano ブロックチェーン ガードレールの付録に概説されているプロセスに従うものとします。

第２項

３つの独立したガバナンス機関は、委任代表者（DRep）、ステークプールオペレーター（SPO）、憲法委員会（CC）から構成され、Cardano ブロックチェーンのチェックとバランスを提供するために、オンチェーンガバナンスアクションの投票に参加します。

第３項

オンチェーン ガバナンスの決定は、Cardano ブロックチェーン ガードレールで要求される特定のコンセンサスしきい値要件を伴う集団意思決定プロセスを通じて行われます。すべてのオンチェーン ガバナンス アクションは、Cardano ブロックチェーン ガードレールに従って投票されます。

第４項

すべてのADA所有者（およびその指名された被指名人）は、本憲法およびCardanoブロックチェーンガードレールに規定されている制限または要件に従って、オンチェーンガバナンスアクションの意思決定プロセスで投票する権利を有します。

ワークショップの質問

  • 投票権は所有する ADA に比例します。しかし、憲法は特定の投票モデルを規定すべきでしょうか?
  • 憲法は 1 ADA につき 1 票を定めるべきでしょうか?
  • 組織による参加にはどのように対処すればよいでしょうか? 取引所など、所有者ではない ADA 保有者に投票を許可すべきでしょうか?

すべてのADA所有者（およびその指名された被指名人）は、Cardano ブロックチェーン ガードレールに従って、Cardano ブロックチェーンエコシステムのガバナンス構造の変更を提案する権利を有します。

第５項

Cardano ブロックチェーンのオンチェーン変更をコミットすることなくコミュニティの感情を評価できるようにする特別な形式のガバナンスアクションが存在します。「情報」アクションは、Cardano ブロックチェーンでの投票結果を記録する以外には、オンチェーンには影響しません。

第６項

提案されるオンチェーン ガバナンス アクションには、文書化されたオフチェーン コンテンツにリンクされた URL とハッシュを含む、標準化された判読可能な形式が必要です。Cardano ブロックチェーンへの変更要求を正当化する十分な根拠を提供する必要があります。根拠には、少なくとも、タイトル、概要、提案の理由、および関連する裏付け資料を含める必要があります。

オンチェーンガバナンス段階に到達したガバナンスアクション提案は、そのガバナンスアクション提案の最終オフチェーンバージョンと内容が同一でなければなりません。

「ハードフォークの開始」および「プロトコルパラメータの変更」ガバナンスアクションは、ガバナンスアクションがCardanoブロックチェーンのセキュリティ、機能、またはパフォーマンスを危険にさらさないことを保証するために、Cardanoブロックチェーンガードレールによって義務付けられている十分な技術的レビューと精査を受ける必要があります。オンチェーンガバナンスアクションは、Cardanoブロックチェーンエコシステムへの予想される影響に対処する必要があります。

ADAのすべての所有者は、オンチェーンガバナンスアクションへの参加、提出、および投票のプロセスがオープンで透明であり、不当な影響や操作から保護されていることを確認する権利を有します。

第７項

Cardanoコミュニティは、この憲法を有効にし、Cardanoブロックチェーンの将来的なすべてのガバナンス活動について認識し、議論し、形成する機会を確保するために必要な、オフチェーンガバナンスプロセスの作成、維持、および継続的な管理を支援することが期待されています。

第８項

Cardano コミュニティは、少なくとも年に一度、Cardano ブロックチェーンの継続的なメンテナンスと将来の開発のための予算を提案することが期待されています。すべての ADA 所有者（およびその指名された被指名人）は、 オンチェーンガバナンスアクションを通じてカルダノブロックチェーン予算を定期的に承認することが期待されています。 Cardano ブロックチェーンバリアで要求されている有効な Cardano ブロックチェーンの予算がない限り、Cardanoトレジャリーからの出金は許可されません。

[Cardano ブロックチェーンのトレジャリーから [1,000,000] ADA を超える ADA を要求するいかなるガバナンスアクションも、その資金要求の一部として、定期的な独立監査のコストやその ADA の使用に関する監視指標の実施をカバーするための ADA の割り当てが必要になります。] [Cardano の予算に従って Cardano ブロックチェーンのトレジャリーから受け取った ADA の使用を規定する契約上の義務には、紛争解決の条項が含まれるものとします。]

ワークショップの質問

  • 憲法は、一定額以上のガバナンスアクションには、定期的な監査と監督指標の実施に充てるための予算を含めることを義務付けるべきですか。その場合、どのように強制しますか？
  • 憲法は、トレジャリーから一定額以上受領したADAの使用を規定する契約条項に、紛争解決条項を含めることを義務付けるべきですか。その場合、どのように強制しますか？
  • 憲法は予算に予備費を含めることを義務付けるべきでしょうか?もしそうなら、それはどのように機能しますか？何に使えますか?誰が管理するのでしょうか？
  • 憲法は、DRep や憲法委員会のメンバーなどのガバナンス参加者に対する潜在的な請求をカバーするための賠償基金を予算に含めることを要求すべきでしょうか？ そうであれば、それはどのように機能しますか？ 何に使用される可能性がありますか？ 誰がそれを管理するのでしょうか？
  • 予算編成プロセスを憲法にもっと詳細に明記すべきでしょうか？予算の管理方法を憲法で決めるべきでしょうか？誰が予算を管理するのかを決める必要がありますか?
  • 憲法で年間予算の上限を定めるべきでしょうか?

第４条 委任代表者

第１項

ガバナンスアクションに参加するために、ADA の所有者は DRep として登録し、そのようなガバナンスアクションに直接投票するか、登録されている他の DRep に投票権を委任して、その DRep が代わりに投票することができます。

第２項

ADA 保有者は誰でも DRep として登録することができます。 すべてのADA 所有者（およびその指名された被指名人）は、自身を含む 1 人以上の登録 DRep に議決権を委任することができます。DRep は個人または調整されたグループです。DRep は、オンチェーン ガバナンス アクションに直接投票する権利があり、投票権を委任した ada 所有者を代表します。

この投票システムは、ADA の所有者が DRep をシームレスに選択し、DRep として登録し、いつでも委任を変更できる、液体民主主義モデルに位置づけられます。

第３項

[DRep は、DRep としての活動を規定する行動規範を随時取り入れ、その行動規範を一般に公開することが求められます。]

ワークショップの質問

  • DRep がそれぞれの行動規範に含める必要がある要件に関するガイダンスを憲法に含めるべきでしょうか?
  • すべての DRep に対して 1 つの行動規範が必要ですか、それとも各 DRep が独自の行動規範を取り入れるようにするべきですか? DRep の行動規範はオンチェーンにすべきでしょうか?憲法委員会はそれらの行動規範が憲法に適合するかどうかを判断すべきでしょうか？
  • 憲法にDRepの任期制限を含めるべきでしょうか?

第４項

Cardano コミュニティは、ADA 保有者が DRep 候補を発見および評価し、適切と思われる基準に従って DRep を選択できるようにするツールの作成、保守、継続的な管理をサポートすることが期待されています。

第５項

[DRepは、Cardano ブロックチェーン エコシステムのための専門的なガバナンス集団を育成するための努力に対して報酬を得ることができます。DRepは、DRepとしての活動に関連して受け取った報酬を開示するものとします。DRepは議決権を購入することはできません。］

ワークショップの質問

  • 憲法はDRepsの補償を義務付けるべきでしょうか？もしそうであれば、憲法は報酬の決定方法を明記すべきでしょうか、または報酬の上限を含めるべきでしょうか？憲法は、Cardanoブロックチェーンに承認された予算に、DRepを補償する十分な額をCardanoブロックチェーンのトレジャリーから配分することを義務付けるべきでしょうか？

第５条 ステークプールオペレーター

第１項

SPO は、Cardano ブロックチェーン ガードレールに定められているように、DRep とは別個かつ独立して投票し、追加の監視と独立性を必要とする重要なオンチェーン ガバナンス アクションを承認する特定の役割を担います。SPO は、Cardano ブロックチェーンのコンセンサス メカニズムに参加するノードオペレーターとして、ハードフォークの開始プロセスに参加します。

第２項

SPOは、例外的な状況下において、「不信任決議案」と「委員会／しきい値の更新」というガバナンスアクションについて個別に投票することにより、憲法委員会の権限をチェックする役割を果たすことができます。

第３項

[DRepとSPOの両方であるADAの所有者は、両方の立場でオンチェーンガバナンスアクションに投票することを控えるか、オンチェーンガバナンスの権利を行使する前に、両方の立場でオンチェーンガバナンスアクションに参加していることを公に開示するものとします。]

ワークショップの質問

  • 憲法には、DRep と SPO の両方を兼ねる ADA 所有者が両方の立場で投票を控えるか、そのような二重の役割を明らかにすることを義務付ける条項を含めるべきでしょうか?憲法にはその他の利益相反規定も含めるべきでしょうか？憲法は SPO に行動規範の実施を義務付けるべきでしょうか？ そうであれば、それらはオンチェーンであるべきでしょうか？憲法委員会はそのような行動規範が憲法に準拠しているかどうかを判断すべきでしょうか？

第６条 憲法委員会

第１項

Cardano のオンチェーン ガバナンス プロセスの部門として、ガバナンスアクションが本憲法に準拠していることを保証する憲法委員会が設立されます。憲法委員会は、ADA の所有者（およびその指名された被指名人）で構成され、オンチェーンでのガバナンスアクションがオンチェーンで制定される前に合憲であることを確認する共同責任を負います。憲法委員会の投票は、ガバナンスアクションの合憲性に関するものに限定されます。憲法委員会のメンバーは、Cardano ブロックチェーン エコシステムへの過去の貢献と関与を考慮して、必要な責任を遂行するために適切な専門知識を持っていることが求められます。

第２項

憲法委員会は、Cardano ブロックチェーン ガードレール に準拠し、Cardano ブロックチェーンの継続的な整合性を保証するのに十分な、「ADA所有者によって随時決定されるメンバー数」で構成されるものとします。

ワークショップの質問

  • 憲法は憲法委員会のメンバー数をどのように決定するかを規定すべきでしょうか? （ガードレールには、最小メンバー数と最大メンバー数の両方が規定されていることに注意してください。）

憲法委員会のメンバーは、Cardano ブロックチェーン ガードレール に従って 「ADA 所有者によって随時決定される」 任期を務めますが、任期は 1 年未満であってはなりません。憲法委員会の運営の継続性を確保するため、憲法委員会のメンバーの任期は交互にずらして設定されるものとします。

ワークショップの質問

  • 憲法は憲法委員会の委員の任期制限をどのように決定するかを規定すべきでしょうか? （ガードレールには最小時間制限と最大時間制限の両方が指定されることに注意してください。）

第３項

Cardanoコミュニティは、Cardanoブロックチェーンガードレールの要件と一致する憲法委員会のメンバーを選出するためのプロセスを随時確立するものとします。

ワークショップの質問

  • 憲法には、憲法委員会のメンバーを選出するための明確なプロセスを含めるべきでしょうか?

第４項

「不信任決議」または「憲法委員会/しきい値の更新」以外のガバナンスアクションは、憲法委員会がオンチェーンアクションを通じて当該提案が本憲法に違反していないことを最初に決定し、確認しない限り、オンチェーンで実施することはできません。

憲法委員会は、常に、信任状態または不信任状態のいずれかの状態にあるものとみなされます。不信任状態では、他のオンチェーン ガバナンス アクションを進める前に、「憲法委員会/しきい値の更新」ガバナンス アクションを使用して、その時点での憲法委員会のメンバーを復帰させるか、交代させなければなりません。

第５項

憲法委員会の手続きは透明でなければなりません。憲法委員会はそれぞれの決定を公表しなければなりません。提案に「反対」票を投じる場合、[憲法委員会] [反対票を投じる憲法委員会の各委員] は、その提案と矛盾する本憲法の特定の条項を参照して、決定の根拠を示すものとします。

憲法委員会は、憲法委員会が随時発行する行動規範に従って運営され、憲法委員会がその職務を遂行する上で必要であるとみなすポリシーおよび手順を採用するものとする。

ワークショップの質問

  • 憲法は、憲法委員会の行動規範がオンチェーンで維持されることを義務付けるべきでしょうか?
  • コミュニティは憲法委員会の行動規範を承認する上で何らかの役割を果たすべきでしょうか?もしそうなら、この役割はどのように機能しますか?

第６項

Cardano コミュニティは、憲法委員会がその重要な機能を実行するために、必要かつ適切なツールの作成、保守、継続的な管理をサポートすることが期待されています。

第７項

[憲法委員会の委員は、憲法委員会の委員としての努力に対して報酬を受け取ることができる。憲法委員会のメンバーは、委員会のメンバーとしての活動に関連して受け取った報酬がすべて公的に開示されることを保証するものとする。] [カルダノブロックチェーンの承認された予算は、[憲法委員会のメンバーにそのような金額を報酬するのに十分なカルダノ財務省からの割り当てで構成される。 ADA保有者によって随時承認されるものであり、憲法委員会が随時要求する額の憲法委員会の定期的な管理経費を準備する。]

[憲法委員会メンバーは、憲法委員会メンバーとしての活動に対して報酬を受け取ることができます。憲法委員会メンバーは、メンバーとしての活動に関連して受け取った報酬がすべて開示されるようにする必要があります。] [Cardano ブロックチェーンのために承認された予算は、「ADA 所有者によって随時承認される金額で憲法委員会メンバーに報酬を支払う」のに十分なCardano ブロックチェーン トレジャリーからの配分を含むものとし、憲法委員会が随時要求する金額で憲法委員会の定期的な管理費用を提供するものとします。]

ワークショップの質問

  • 憲法は憲法委員会の委員に対する報酬を要求すべきでしょうか?もしそうなら、憲法は報酬の決定方法を明記するか、あるいは報酬の制限を含めるべきでしょうか?
  • 憲法は、Cardanoブロックチェーンのために承認された予算には、ADA によって随時承認される金額で憲法委員会のメンバーに報酬を与えるのに十分なCardanoトレジャリーからの支出を含めることを要求すべきでしょうか?
  • 憲法は予算に憲法委員会の管理費用の割り当てを含めることを要求すべきでしょうか?その場合、金額はどのように決めればよいのでしょうか？もしそうなら、誰がそのような予算を管理するのか、憲法委員会による支出は公開されるべきか、監査監視の対象となるべきかを憲法で規定すべきでしょうか?

第７条 附則

第１項

Cardano ブロックチェーン ガードレール付録に別途規定されている場合を除き、Cardano ブロックチェーン ガードレール付録を含む本規約の修正は、集団意思決定プロセスによって承認され、その時点で有効な議決権の 67% 以上のしきい値を満たす ADA所有者（およびその指名された被指名人）によるオンチェーン ガバナンス アクションが必要になります。

第2条

Cardano ブロックチェーン ガードレールの付録が、本第７条の第１項に規定されている修正しきい値とは異なるCardano ブロックチェーン ガードレールの修正しきい値を定めている場合は、そのCardano ブロックチェーン ガードレールの付録に定められたしきい値が適用されるものとします。

ワークショップの質問

  • 憲法には、第 7 条自体の改正を禁止したり、これらの改正要件を変更する効果をもたらすガバナンスアクションを許可したりする条項を含めるべきでしょうか?
  • 憲法には、憲法委員会が監督し承認できる技術的ガードレールの修正カテゴリーを含めるべきでしょうか? これはそもそも可能でしょうか? もし可能であれば、そのようなカテゴリーは、高いセキュリティリスクや緊急の問題のみに対処するように狭く定義されるべきでしょうか?

付録１: CARDANO ブロッチェーン ガードレール

1.はじめに

CIP-1694 に従って Cardano ブロックチェーンのオンチェーン ガバナンスを実装するには、Cardano ブロックチェーンが安全かつ持続可能な方法で運用を継続できるようにする適切なガードレールを確立する必要があります。

この付録では、プロトコル パラメータの変更やトレジャリーからの引き出しの制限など、Cardano ブロックチェーンのオンチェーン ガバナンス アクションに適用する必要があるガードレールについて説明します。これらのガードレールは、設定に関する必須かつ固有の制限と、経験、測定、ガバナンスの目的に基づいた推奨事項の両方をカバーしています。

これらのガードレールは、Cardano ブロックチェーンの運用における予期しない問題を回避するために設計されています。これらは、適切なパラメータ設定の選択をガイドし、セキュリティ、パフォーマンス、または機能に関する潜在的な問題を回避することを目的としています。以下で説明するように、これらのガードレールの一部は自動化可能であり、オンチェーン スクリプトまたは組み込みのledgerルールを介して適用されます。

これらのガードレールは、Cardano ブロックチェーン レイヤー 1 メインネット環境に適用されます。テスト環境や、Cardano ブロックチェーン ソフトウェアを使用する他のブロックチェーンには適用されません。

Cardano ブロックチェーンのすべてのパラメーターを独立して考慮できるわけではありません。一部のパラメーターは、内部的に他の設定と相互作用します。これらの相互作用が判明している場合は、この付録で説明します。

この付録のガードレールは現時点では技術的知見の現状を反映していますが、この付録はリビングドキュメントとして扱う必要があります。Cardano ブロックチェーンの実装の改善、新しいシミュレーション、またはパフォーマンス評価の結果により、これらのガードレールに含まれる制限の一部が、やがて緩和される可能性があります (または、状況によっては、制限を強化する必要が生じる可能性があります)。

たとえば、新しいプロトコル パラメータが導入される場合には、追加のガードレールが必要になる場合もあります。

この付録に規定されているガードレールは、この付録に規定されている適用可能な投票しきい値を満たすオンチェーンガバナンスアクションに従って、随時修正される場合があります。ガードレールの修正は、憲法自体の改正が必要であり、憲法自体の改正とみなされます。

ワークショップの質問

  • 以下のガードレールのいずれかに、第 VII 条に含まれるしきい値とは異なる修正しきい値を含める必要がありますか障壁のいずれか?

用語とガイダンス

  • すべき/すべきではない: この付録で、ある値を下回ったり上回ったり「すべきではない」と記載されている場合、これはガードレールが推奨事項またはガイドラインであり、特定の値は、Cardano ブロックチェーンのガバナンス システムまたは Cardano ブロックチェーンの運用に関する経験を考慮して、Cardano コミュニティによって認められた適切な専門家グループによって議論または変更される可能性があることを意味します。
  • しなければならない/してはならない: この付録で、ある値を下回ったり上回ったり「してはならない」と記載されている場合、これはガードレールが、Cardano ブロックチェーンのledgerルール、タイプ、またはその他の組み込みメカニズムによって可能な限り強制される要件であり、それに従わない場合は、プロトコル障害、セキュリティ侵害、またはその他の望ましくない結果を引き起こす可能性があることを意味します。
  • ベンチマーキング: ベンチマーキングとは、例えば95%のブロックがすべてのケースで所定の5秒間隔内にCardanoブロックチェーンノードのグローバルネットワーク全体に拡散されることを事前に示すことを目的とした、慎重なシステムレベルの性能評価を指します。これには、特定のテストワークフローの構築と、グローバルなCardanoブロックチェーンネットワークをシミュレーションする大規模なテストネットワーク上での実行が必要になる場合があります。
  • パフォーマンス分析: パフォーマンス分析とは、理論的なパフォーマンス、経験的なベンチマーキング、またはシミュレーションの結果を予測して、実際のシステムの動作を予測することを指します。たとえば、制御されたテスト環境 (既知のネットワーク プロパティを持つデータ センターのコレクションなど) でのテストから得られたパフォーマンス結果を推定して、実際の Cardano Blockchain ネットワーク環境で起こりそうなパフォーマンス動作を予測することができます。
  • シミュレーション： シミュレーションとは、反復的な方法でパフォーマンス/機能の決定を通知するように設計された合成実装を指します。たとえば、IOSim の Cardano ブロックチェーン モジュールを使用すると、ネットワーク スタックの動作を制御された反復可能な方法でシミュレートできるため、コードがデプロイされる前に問題を検出できます。
  • パフォーマンス監視: パフォーマンス監視とは、例えばラウンドトリップタイムを評価するためのタイミングプローブや、全体的なネットワークの健全性の状態を評価するためのテストブロックを使用して、Cardanoブロックチェーンネットワークの実際の挙動を測定することを指します。これは、シミュレーションされたワークロードや理論的分析では得られない実際のシステムの挙動に関する情報を提供することで、ベンチマーキングやパフォーマンス分析を補完します。
  • 変更を元に戻す: パフォーマンス監視により、変更後の実際のネットワーク動作が Cardano ブロックチェーンのパフォーマンス要件に準拠していないことが示された場合は、可能であれば変更を前の状態に戻す必要があります。たとえば、ブロック サイズが 100 KB から 120 KB に増加し、ブロックの 95% が 5 秒以内に分散されなくなった場合は、ブロック サイズを 100 KB に戻すように変更を加える必要があります。これが不可能な場合は、パフォーマンス要件が確実に満たされるように、1 つ以上の代替変更を行う必要があります。
  • 重大度レベル： Cardano ブロックチェーン ネットワークに影響を与える問題は、次のような重大度レベルに分類されます。
    • 重大度１ Cardano ブロックチェーン ネットワークのセキュリティ、パフォーマンス、または機能に非常に大きな影響を与える重大なインシデントまたは問題です
    • 重大度２ Cardano ブロックチェーン ネットワークのセキュリティ、パフォーマンス、または機能に重大な影響を与える重大なインシデントまたは問題です
    • 重大度３ Cardano ブロックチェーン ネットワークのセキュリティ、パフォーマンス、または機能に影響が少ない軽微なインシデントまたは問題です
  • 将来のパフォーマンス要件: メモリ外ストレージの新しいメカニズムなどの計画された開発は、ブロックの拡散やその他の時間に影響を与える可能性があります。パラメータを変更するときは、Cardano ブロックチェーンの現在の動作だけでなく、これらの将来のパフォーマンス要件も考慮する必要があります。開発が完了するまでは、要件は控えめになりますが、実際のタイミング動作を考慮して緩和される可能性があります。

自動チェック（「ガードレール スクリプト」）

「新しい憲法またはガードレール スクリプト」のガバナンス アクションが施行されると、スクリプト ハッシュが憲法ハッシュに関連付けられます。これは、ledgerルールとタイプに対する追加の保護手段として機能し、準拠していないガバナンス アクションをフィルタリングします。

ガードレール スクリプトは、次の 2 種類のガバナンス アクションにのみ影響します:

  • 「パラメータ更新」アクション
  • 「トレジャリー引き出し」アクション

スクリプトは、これらのいずれかのタイプのガバナンス アクションがオンチェーンで送信されたときに実行されます。これにより、たとえば、誤ったスクリプトによってチェーンがハード フォーク アクションを実行できなくなり、デッドロックが発生するといったシナリオを回避できます。スクリプトの使用には、3 つの異なる状況が当てはまります。

「記号と説明」

  • (y) スクリプトを使用してガードレールを強制できます。
  • (x) スクリプトを使用してガードレールを強制することはできません。
  • (~ - 理由) 指定された理由により、スクリプトを使用してガードレールを強制することはできませんが、将来のledgerの変更によりこれが可能になります。

ガードレールは重複する場合があります：この場合、最も制限の厳しいガードレール セットが適用されます。

このドキュメントにパラメータが明示的に記載されていない場合、スクリプトはパラメータの変更を許可してはなりません。

逆に、このドキュメントにパラメータが明示的に記載されているが、チェック可能なガードレールが指定されていない場合、スクリプトはパラメータの変更に制約を課してはなりません。

2.プロトコルパラメータ更新アクションに関するガードレールとガイドライン

以下は、プロトコル パラメータ更新ガバナンス アクションを介して更新可能なプロトコル パラメータ設定を変更するためのガードレールとガイドラインです。これにより、Cardano ブロックチェーンが変更の結果として回復不能な状態になることがなくなります。

パラメーター名には少なくとも 5 つの異なるソースがあり、それらは常に一貫しているわけではないことに注意してください。

  1. Genesis ファイルで使用される名前
  2. プロトコル パラメータ更新ガバナンス アクションで使用される名前
  3. ledgerルールで内部的に使用される名前
  4. 形式ledger仕様で使用される名前
  5. 研究文書で使用される名前

これらのパラメータ名が異なる場合、この付録では 2 番目の規則を使用します。

ガードレール

PARAM-01 (y) この文書で明示的に指定されていないプロトコルパラメータは、パラメータ更新ガバナンスアクションによって変更されてはなりません。

PARAM-02 (y) この文書にプロトコルパラメータが明示的に記載されているが、チェック可能なガードレールが指定されていない場合、ガードレールスクリプトはパラメータの変更に制約を課してはなりません。チェック可能なガードレールは (y) で示されます。

2.1.重要なプロトコルパラメータ

以下のプロトコル パラメータは、セキュリティの観点から重要です。

ブロックチェーンの動作において重要なパラメータ

  • ブロック本体の最大サイズ (maxBlockBodySize)
  • トランザクションの最大サイズ (maxTxSize)
  • ブロックヘッダーの最大サイズ (maxBlockHeaderSize)
  • シリアル化されたアセット価値の最大サイズ (maxValueSize)
  • 単一ブロック内のスクリプト実行/メモリユニットの最大数(maxBlockExecutionUnits[steps/memory])
  • 最低手数料係数(txFeePerByte)
  • 最小充電定数(txFeeFixed)
  • リファレンス スクリプトの バイトあたりの最小手数料(minFeeRefScriptCoinsPerByte)
  • シリアル化された UTxO のバイトあたりの最小 Lovelace デポジット(utxoCostPerByte)
  • ガバナンスアクションデポジット(govDeposit)
ガードレール

PARAM-03 (y) 重要なプロトコル パラメータには、DRep 投票に加えて SPO 投票が必要です。SPO は、すべてのアクティブなブロック生成ステークの 50% を超える集合的なサポートで「yes」と答えなければなりません。これは、ステーク プールの投票しきい値のガードレールによって強制されます。

PARAM-04 (x) 重要なプロトコルパラメータを変更するオフチェーン提案が公表されてから、対応するオンチェーンガバナンスアクションが提出されるまで、通常少なくとも3ヶ月は経過すべきです。このガードレールは、慎重な技術的議論と評価を経て、重大度１または重大度２のネットワーク問題が発生した場合に緩和されることがあります。

ガバナンスシステムにとって重要なパラメータ

  • 委任キー Lovelace デポジット(stakeAddressDeposit)
  • プール登録 Lovelace デポジット (stakePoolDeposit)
  • プールの最小固定報酬カット (minPoolCost)
  • DRep デポジット額 (dRepDeposit)+
  • 憲法委員会の最小サイズ (committeeMinSize)
  • 憲法委員会のメンバーの最大任期期間(エポック単位)(committeeMaxTermLimit)

ガードレール

PARAM-05 (y) DREPは、アクティブな全投票ステークの50%以上の支持を得て「yes」に投票しなければなりません。これはDRepの投票しきい値のガードレールによって強制されます。

PARAM-06 (x) 重要なガバナンスシステムのパラメータを変更するためのオフチェーン提案の公表と、それに対応するオンチェーンガバナンスアクションの提出の間には、通常、少なくとも3ヶ月が経過すべきです。このガードレールは、慎重な技術的議論と評価の後に、重大度１1または重大度2のネットワーク問題が発生した場合には緩和されることがあります。

2.2.経済パラメータ

経済パラメータを管理する際の全体的な目標は次のとおりです：

  1. Cardano ブロックチェーン エコシステムの長期的な経済的持続可能性を実現します。
  2. ステーク プールがCardano ブロックチェーンの維持に対して適切な報酬を得られるようにします。
  3. ADA 保有者が、ブロック生成のために ADA を委任する場合など、建設的な方法でステークを使用することに対して適切な報酬を得られるようにします。そして
  4. ステーク プール オペレーター、ADA 保有者、DeFi ユーザー、インフラストラクチャ ユーザー、開発者 (例: DApps)、金融仲介者 (例: 取引所) など、Cardano ブロックチェーン エコシステムのさまざまな利害関係者に対する経済的インセンティブのバランスをします。

変化のきっかけ

  1. セキュリティ、パフォーマンス、または機能性に潜在的な問題をもたらす、ADAのフィアット価値の大幅な変化
  2. トランザクションの量またはタイプの変更
  3. コミュニティからのリクエストまたは提案
  4. 経済パラメータの変更を必要とする緊急事態

対策指標

経済パラメータの変更は単独で行うべきではありません。次のことを考慮する必要があります：

  • 外部経済要因
  • ネットワークセキュリティに関する懸念

コア指標

  • セキュリティ、パフォーマンス、または機能に潜在的な問題を引き起こす ADA のフィアット価値
  • トランザクション量とタイプ
  • ステークプールの数と健全性
  • 外部経済要因

特定の経済パラメータの変更

バイトあたりのトランザクション手数料(txFeePerByte)および固定トランザクション手数料 (txFeeFixed)

Lovelaceにおける基本的なトランザクションのコストを定義します：

fee(tx) = txFeeFixed + txFeePerByte x nBytes(tx)

ガードレール

TFPB-01 (y) txFeePerByteは 30 (0.000030 ada) 未満であってはなりません

これにより、低コストのDoS攻撃から保護されます

TFPB-02 (y) txFeePerByteは 30 (0.000030 ada) 未満であってはなりません

これにより、トランザクションの支払いが確実に行われるようになります

TFPB-03 (y) txFeePerByte は負であってはなりません

TFF-01 (y) txFeeFixed は 30 (0.000030 ada) 未満であってはなりません

これにより、低コストのDoS攻撃から保護されます

TFF-02 (y) txFeeFixedは1,000 (0.001 ada) を超えてはなりません

これにより、トランザクションの支払いが確実に行われるようになります

TFF-03 (y) txFeeFixed は負であってはなりません

TFGEN-01 (x - 「should」) DoS 攻撃に対する一貫した保護レベルを維持するために、txFeeFixed と *txFeeFixed は、Plutus の実行価格が調整されるたびに調整されるべきです(executionUnitPrices[steps/memory])。

TFGEN-02 (x - 数値化不可能) txFeeFixedまたはtxFeeFixedへのいかなる変更も、DoS攻撃のコスト削減、あるいはトランザクションの構築が不可能になるような最大トランザクション手数料の増加を考慮しなければなりません。

バイトあたりの UTxO コスト (utxoCostPerByte)

UTxO のストレージ コストの定義

  • 単一の UTxO に保持される ADA の最小しきい値を設定します (最小で～1ADA、最悪の場合50ADA以上になることもありえます)
  • UTxO ストレージに対する低コストのDoS攻撃に対する保護を提供します。この攻撃は他のチェーンで実行されており、理論上のものではありません。

DoS 保護は、空きノード メモリに応じて減少します (UTxO の増加に比例)。

  • 長期保管コストの削減に役立ちます
  • 不要になった UTxO を返却するインセンティブを提供します

最小トランザクション コスト (~ 0.15 ada) を大幅に上回る必要があります

ガードレール

UCPB-01 (y) utxoCostPerByte は 3,000 (0.003 ada) 未満であってはなりません

UCPB-02 (y) utxoCostPerByte は 6,500 (0.0065 ada) を超えてはなりません

UCPB-03 (y) utxoCostPerByte はゼロであってはなりません

UCPB-04 (y) utxoCostPerByte は負であってはなりません

UCPB-05 (x - “should”) 変更は以下を考慮すべきです

i) 許容可能な攻撃コスト

ii) 攻撃の許容時間 (少なくとも 1 エポックと想定)

iii) フルノードユーザーに許容可能なメモリ構成(ウォレットの場合は 16 GB、ステーク プールの場合は 24 GB と想定)

iv) UTxO のサイズ (UTxO あたり最小 200B、最大約 10KB)

v) 現在のノード メモリ使用量の合計

ステークアドレスデポジット (stakeAddressDeposit)

不要になったステークアドレスを確実に廃棄します

  • 長期保管コストの削減に役立ちます
  • ledgerの CPU とメモリのコストを削減します

デポジットの理由は、希少なメモリ リソースが不要になったときに返却を促すためです。アクティブなステーク アドレスの数を減らすと、ステーク スナップショットを計算するときのエポック境界での処理とメモリのコストも削減されます。

ガードレール

SAD-01 (y) stakeAddressDeposit は 1,000,000 (1 ada) 未満であってはなりません

SAD-02 (y) stakeAddressDeposit は 5,000,000 (5 ada) を超えてはなりません

SAD-03 (y) stakeAddressDeposit は 負であってはなりません

ステークプールデポジット (stakePoolDeposit)

ステークプールオペレーターが不要になったステークプールを確実に廃止します。

  • 長期保管コストの削減に役立ちます

デポジットの根拠は、希少なメモリ リソースが不要になったときに返却されるようにインセンティブを与えることです。報酬とステーク スナップショットの計算は、アクティブなステーク プールの数によっても影響を受けます。

ガードレール

SPD-01 (y) stakePoolDeposit は 250,000,000 (250 ada) 未満であってはなりません

SPD-02 (y) stakePoolDeposit は 500,000,000 (500 ada) を超えてはなりません

SPD-03 (y) stakePoolDeposit は 負であってはなりません

最小プールコスト (minPoolCost)

報酬メカニズムの一部

  • 委任者報酬が支払われる前に、プールの最小コストがプール報酬アドレスに転送されます
ガードレール

MPC-01 (y) minPoolCost は 負であってはなりません

MPC-02 (y) minPoolCost は 500,000,000 (500 ada) を超えてはなりません

MPC-03 (x - 「should」) *minPoolCost は、プールを運営するための経済的コストに沿って設定されるべきです

トレジャリーカット (treasuryCut)

報酬メカニズムの一部

  • 金融緩和によるトレジャリーカット部分は、プール報奨金が支払われる前にトレジャリーに移されます
  • 0.0～1.0（0%～100%）の範囲で設定できます
ガードレール
TC-01 (y) treasuryCut は 0.1 (10%) 未満であってはなりません

TC-02 (y) treasuryCut は 0.3 (30%) を超えてはなりません

TC-03 (y) treasuryCut は 負であってはなりません

TC-04 (y) treasuryCut は 1.0 (100%) を超えてはなりません

TC-05 (~ - 変更履歴へのアクセス不可) treasuryCut は、36 エポック期間 (約 6 か月) 内に一度以上変更してはなりません

金融緩和率(monetaryExpansion)

報酬メカニズムの一部

  • 通貨拡張は、各エポックの報酬に使用される準備金の量を制御します

Cardano の長期的な持続可能性の管理

  • 準備金は徐々に枯渇し、報酬は供給されなくなります
ガードレール

ME-01 (y) monetaryExpansion は 0.005を超えてはなりません

ME-02 (y) monetaryExpansion は 0.001 未満であってはなりません

ME-03 (y) monetaryExpansion は 負であってはなりません

ME-04 (x - 「should」) monetaryExpansionは、73エポック期間（約12ヶ月）において、±10%を超えて変動させるべきではありません

ME-05 (x - 「should」) monetaryExpansionは、36エポック（約半年）の間に一度以上変更されるべきではありません

Plutus スクリプトの実行価格 (executionUnitPrices[priceSteps/priceMemory])

Plutus スクリプトの実行料金を定義します

Plutus スクリプトの実行により経済的利益をもたらします

低コストの DoS 攻撃に対するセキュリティを提供します

ガードレール

EIUP-PS-01 (y) executionUnitPrices[priceSteps] は 2,000 / 10,000,000を超えてはなりません

EIUP-PS-02 (y) executionUnitPrices[priceSteps] は 500 / 10,000,000未満であってはなりません

EIUP-PM-01 (y) executionUnitPrices[priceMemory] は 2,000 / 10,000を超えてはなりません

EIUP-PM-02 (y) executionUnitPrices[priceMemory] は 400 / 10,000未満であってはなりません

EIUP-GEN-01 (x - 「similar to」) 実行価格は、以下のように設定されなければなりません

i) 最大 CPU ステップでトランザクションを実行するコストは、最大サイズのスクリプトを使用しないトランザクションのコストと同程度です

ii) 最大数のメモリユニットを使用してトランザクションを実行するコストは、最大サイズのスクリプトを使用しないトランザクションのコストと同程度です

EIUP-GEN-02 (x - 「should」) 実行価格は、取引手数料が調整されるたびに調整されるべきです（txFeeFixed/txFeePerByte）。目標は、トランザクションの種類に関係なく、「完全な」トランザクションの処理待ち時間と同じになるようにすることです。

  • これにより、ブロックの拡散／伝播時間に関する要件が満たされるようになります。

リファレンス スクリプトのバイトあたりのトランザクション料金 (minFeeRefScriptCoinsPerByte)

Lovelace で Plutus リファレンス スクリプトを使用するコストを定義します

ガードレール

MFRS-01 (y) minFeeRefScriptCoinsPerByte は 1,000 (0.001 ada) を超えてはなりません

  • これにより、トランザクションの支払いが確実に行われるようになります

MFRS-02 (y) minFeeRefScriptCoinsPerByte は 負であってはなりません

MFRS-03 (x - 「should」) DoS攻撃に対する一貫した保護レベルを維持するため、プルータスの実行価格が調整(executionUnitPrices[steps/memory])されるたびに、また txFeeFixed が調整されるたびに、minFeeRefScriptCoinsPerByteは調整されるべきです

MFRS-04 (x - 定量化不可能) *minFeeRefScriptCoinsPerByte への変更は、DoS攻撃のコスト削減または最大トランザクション手数料の増加の影響を考慮しなければなりません

2.3.ネットワークパラメータ

Cardano ブロックチェーンのネットワークパラメータを管理する際の全体的な目標は次のとおりです：

  1. 利用可能な Cardano レイヤー 1 ブロックチェーンのネットワーク容量を、支払いトランザクション、レイヤー 1 DApps、サイドチェーン管理、ガバナンスのニーズなど、現在または将来のトラフィック ニーズに適合させます。
  2. 支払いトランザクション、Fungible/Non-Fungibleトークンの発行者、Plutusスクリプト、DeFi開発者、ステークプールオペレーター、投票トランザクションなど、さまざまなユーザーグループのトラフィックニーズのバランスをとります。

変化のきっかけ

ネットワークパラメータの変更は、次の原因によって発生する可能性があります:

  1. 2 エポック (10 日間) にわたるトラフィック需要の変化を測定
  2. トラフィック需要の予測される変化
  3. コミュニティからのリクエスト

対策指標

以下の場合には、変更を元に戻す必要があるか、変更を実施しない必要がある場合があります。

  • ブロックの伝播が過度に遅れる
  • ステークプールがトラフィック量を処理できない
  • スクリプトが実行を完了できない

コア指標

パラメータ変更に関するすべての決定は、以下の情報に基づいて行う必要があります：

  • ブロック伝播遅延プロファイル
  • トラフィック量 (時間の経過に伴うブロック サイズ)
  • スクリプト量 (スクリプトと実行ユニットのサイズ)
  • スクリプト実行コストベンチマーク
  • ブロック伝播遅延/拡散ベンチマーク

変更がメインネットのパフォーマンスや動作に与える影響を実施前に確認するには、詳細なベンチマーク結果が必要です。通常のトランザクション、Plutus スクリプト、ガバナンス アクションなど、さまざまなトランザクションの組み合わせの影響を分析する必要があります。

ガードレール

NETWORK-01 (x - 「should」) 個々のネットワークパラメータは、2エポックごとに1回以上変更されるべきではありません。

NETWORK-02 (x - 「should」) 直接相関がない限り、1エポックにつき、1つのネットワークパラメータのみを変更するべきです。例: トランザクションごとおよびブロックごとのメモリユニット制限。

特定のネットワークパラメータの変更

ブロックサイズ (maxBlockBodySize)

ブロックの最大サイズ (バイト単位)

ガードレール

MBBS-01 (y) maxBlockBodySize は 122,880バイト (120KB) を超えてはなりません

MBBS-02 (y) maxBlockBodySize は 24,576 バイト (24KB) 未満であってはなりません

MBBS-03 (x - 「exceptional circumstances」) *maxBlockBodySize は、セキュリティ、パフォーマンス、または機能性に潜在的な問題がある例外的な状況を除き、減少してはなりません

MBBS-04 (～ - 既存のパラメータ値へのアクセス不可)maxBlockBodySize は、少なくとも 1 つのトランザクションを含むのに十分な大きさでなければなりません。（つまり、maxBlockBodySize は少なくともmaxTxSize でなければなりません。）

MBBS-05 (x - 「should」) maxBlockBodySizeは、1エポック(5日)あたり最大で10,240バイト(10KB)、好ましくは8,192バイト(8KB)以下で変更されるべきです。

MBBS-06 (x - 「should」)ブロックサイズは、追加のTCP(Transmission Control Protocol)ラウンドトリップを引き起こすべきではありません。これを超える増加は、パフォーマンス分析、シミュレーション、ベンチマークによって裏付けられる必要があります。

MBBS-07 (x - 「unquantifiable」)maxBlockBodySizeへの変更の影響は、詳細なベンチマーク／シミュレーションによって確認されなければならず、以下に説明するように、ブロック拡散／伝播時間バジェットの要件を超えないようにしなければなりません。maxBlockBodySize を増やす場合は、Plutus スクリプトの実行に関する将来の要件も考慮する必要があります。

(maxBlockExecutionUnits[steps])ブロックの総拡散目標3秒に対して、5秒以内に95%のブロックが伝播します。最大ブロックサイズの制限は、ベンチマークと監視結果によってサポートされる場合、将来的に増加する可能性があります。

トランザクションサイズ (maxTxSize)

トランザクションの最大サイズ (バイト単位)

ガードレール

MTS-01 (y) maxTxSize は 32,768 バイト (32KB) を超えてはなりません

MTS-02 (y) maxTxSize は 負であってはなりません

MTS-03 (~ -既存のパラメータ値へのアクセス不可) maxTxSize は減少してはなりません

MTS-04 (~ -既存のパラメータ値へのアクセス不可)maxTxSizeは maxBlockBodySizeを超えてはなりません

MTS-05 (x - 「should」) maxTxSize **はいかなるエポックにおいても2,560 Byte (2.5KB) 以上増加すべきではありません。そして、エポックあたり2,048バイト(2KB)以下であるべきです

MTS-06 (x - 「should」) maxTxSize はブロックサイズの1/4を超えるべきではありません

メモリユニットの制限

(maxBlockExecutionUnits[memory]、maxTxExecutionUnits[memory])

Plutus スクリプトでトランザクションごとまたはブロックごとに使用できるメモリ ユニットの最大数の制限。

ガードレール

MTEU-M-01 (y) maxTxExecutionUnits[memory] は 40,000,000ユニットを超えてはなりません

MTEU-M-02 (y) maxTxExecutionUnits[memory] は負であってはなりません

MTEU-M-03 (～ - 既存のパラメータ値へのアクセス不可) maxTxExecutionUnits[memory] は減少させてはなりません

MTEU-M-04 (x - 「should」) maxTxExecutionUnits[memory] は、どのエポックにおいても、2,500,000 単位以上増加させるべきではありません

MBEU-M-01 (y) maxBlockExecutionUnits[memory] は 120,000,000 ユニットを超えてはなりません

MBEU-M-02 (y) maxBlockExecutionUnits[memory] は 負であってはなりません

MBEU-M-03 (x - 「should」) maxBlockExecutionUnits[memory] は、どのエポックにおいても、10,000,000 単位以上変更（増減）すべきではありません

MBEU-M-04 (x - 数値化不可能) *maxBlockExecutionUnits[memory]*への変更の影響は、詳細なベンチマーク／シミュレーションによって確認され、*maxBlockExecutionUnits[steps]*にも影響される拡散／伝播時間バジェットの要件を超えないようにしなければなりません。いかなる増加も、過去に特定された将来の要件、すなわち、合計ブロックサイズ(maxBlockBodySize)を、95%のブロック伝播が5秒以内に行われるという合計ブロック拡散目標3秒を考慮しなければなりません。将来的にPlutusのパフォーマンスが改善されると、ブロックあたりの制限が増加する可能性がありますが、前の文で指定された全体的な拡散制限と将来の要件とのバランスをとる必要があります。

MEU-M-01 (~ -既存のパラメータ値へのアクセス不可) maxBlockExecutionUnits[memory] は、maxTxExecutionUnits[memory] より小さくてはなりません

CPU ユニット制限

(maxBlockExecutionUnits[steps]、maxTxExecutionUnits[steps])

トランザクションごとまたはブロックごとに、Plutus スクリプトで使用できる CPU ステップの最大数の制限

ガードレール

MTEU-S-01 (y) maxTxExecutionUnits[steps] は 15,000,000,000 (15Bn) ユニットを超えてはなりません

MTEU-S-02 (y) maxTxExecutionUnits[steps] は 負であってはなりません

MTEU-S-03 (~ - 既存のパラメータ値へのアクセス不可) maxTxExecutionUnits[steps] は 減少させてはなりません

MTEU-S-04 (x - 「should」) maxTxExecutionUnits[steps] は、どのエポック(5日間)でも 500,000,000 (500M)ユニット以上増加させるべきではありません

MBEU-S-01 (y) maxBlockExecutionUnits[steps] は 40,000,000,000 (40Bn)ユニットを超えてはなりません

MBEU-S-02 (y) maxBlockExecutionUnits[steps] は 負であってはなりません

MBEU-S-03 (x - 「should」) maxBlockExecutionUnits[steps] は、どのエポック(5日間)でも、2,000,000,000 (2Bn)ユニット以上変更(増減)してはなりません

MBEU-S-04 (x - 数値化不可能) *maxBlockExecutionUnits[steps]*への変更の影響は、詳細なベンチマーク／シミュレーションによって確認され、*maxBlockExecutionUnits[memory]*にも影響される拡散／伝播時間バジェットの要件を超えないようにしなければなりません。いかなる増加も、過去に特定された将来の要件、すなわち、合計ブロックサイズ(maxBlockBodySize)を、95%のブロック伝播が5秒以内に行われるという合計ブロック拡散目標3秒を考慮しなければなりません。将来的にPlutusのパフォーマンスが改善されると、ブロックあたりの制限が増加する可能性がありますが、前の文で指定された全体的な拡散制限と将来の要件とのバランスをとる必要があります。

MEU-S-01 (~ - 既存のパラメータ値へのアクセス不可) maxBlockExecutionUnits[steps] は、maxTxExecutionUnits[steps] より小さくてはなりません

ブロック ヘッダー サイズ (maxBlockHeaderSize)

ブロック ヘッダーのサイズ

ブロックヘッダーのサイズを大きくすると、全体のブロックサイズ (maxBlockBodySize) に影響する可能性があることに注意してください。

ガードレール

MBHS-01 (y) maxBlockHeaderSize は 5,000バイトを超えてはなりません

MBHS-02 (y) maxBlockHeaderSize は 負であってはなりません

MBHS-03 (x - 「最大有効ヘッダー」は変更される可能性があります) maxBlockHeaderSize は、最大の有効なヘッダーに対して十分な大きさでなければなりません

MBHS-04 (x - 「should」) maxBlockHeaderSize は、通常、プロトコルが変更された場合にのみ増加されるべきです

MBHS-05 (x - 「should」) maxBlockHeaderSizeは、TCPの初期輻輳ウィンドウ（3MTUまたは10MTU）内にあるべきです

2.4.技術/セキュリティパラメータ

技術/セキュリティ パラメータを管理する際の全体的な目標は次のとおりです：

  1. 分散化、シビル攻撃および51%攻撃からの保護、DoS攻撃からの保護という観点から、Cardanoネットワークのセキュリティを確保します
  2. Plutus言語の変更を可能にします

変化のきっかけ

  1. アクティブな SPO 数の変化
  2. Plutus の言語の変更
  3. セキュリティの脅威
  4. コミュニティからのリクエスト

対策指標

  • 経済的な懸念（ステークプール数を変更する場合など）

コア指標

  • ステークプールの数
  • 分散化のレベル

特定の技術/セキュリティパラメータの変更

ステークプールのターゲット数 (stakePoolTargetNum)

ステークプールの目標数を設定する

  • ネットワークのバランスが取れている場合に予想されるプールの数
  • 主にセキュリティパラメータであり、プールの分割/複製によって分散化を保証します
  • セキュリティへの影響だけでなく、経済的な影響もあります
  • このパラメータを変更する場合は、経済的なアドバイスが必要です
  • このパラメータに大きな変更があると、大量の再委任イベントが発生します
ガードレール

SPTN-01 (y) stakePoolTargetNum は 250未満であってはなりません

SPTN-02 (y) stakePoolTargetNum は 2,000を超えてはなりません

PTN-03 (y) stakePoolTargetNum は 負であってはなりません

SPTN-04 (y) stakePoolTargetNum はゼロであってはなりません

Pledge影響係数 (poolPledgeInfluence)

Pledge保護メカニズムを有効にする

シビル攻撃に対する保護を提供します

  • より多くのPledgeを持つプールはより多くのボーナスを受け取り、より少ないPledgeのプールにはペナルティが課せられます

技術的効果だけでなく経済的効果もあるため、経済的アドバイスも必要

  • 0.0～無限大の範囲で設定可能
ガードレール

PPI-01 (y) poolPledgeInfluence は 0.1 未満であってはなりません

PPI-02 (y) poolPledgeInfluence は 1.0 を超えてはなりません

PPI-03 (y) poolPledgeInfluence は 負であってはなりません

PPI-04 (x - 「should」) poolPledgeInfluence は 18エポック期間（約3ヶ月）において、±10%を超えて変動すべきではありません

プールのリタイア期間 (poolRetireMaxEpoch)

プールが引退を計画する際に通知できるエポックの最大数を定義します。

ガードレール

PRME-01 (y) poolRetireMaxEpoch は 負であってはなりません

PRME-02 (x - 「should」) *poolRetireMaxEpoch は 1未満であるべきではありません

担保率 (collateralPercentage)

Plutus スクリプトを実行するときに、通常の実行コストのパーセンテージとして提供する必要がある担保の量を定義します

  • 担保は手数料の支払いに追加されます
  • スクリプトの実行に失敗した場合、担保は失われます
  • スクリプトの実行が成功した場合、担保が失われることはありません

失敗したスクリプトの実行コストを低くするのではなく、むしろ高くすることで、低コストの攻撃に対するセキュリティを提供します

ガードレール

CP-01 (y) collat​​eralPercentage は 100未満であってはなりません

CP-02 (y) collateralPercentage は 200を超えてはなりません

CP-03 (y) collat​​eralPercentage は 負であってはなりません

CP-04 (y) collat​​eralPercentage は ゼロであってはなりません

担保入力の最大数 (maxCollat​​eralInputs)

Plutus スクリプトの実行時に担保として使用できる最大入力値を決定します。

ガードレール

MCI-01 (y) maxCollat​​eralInputs は 1 未満であってはなりません

最大値サイズ (maxValueSize)

各値のシリアライズされたサイズの制限

ガードレール

MVS-01 (y) maxValueSize は 12,288 バイト (12KB) を超えてはなりません

MVS-02 (y) maxValueSize は 負であってはなりません

MVS-03 (~ - 既存のパラメータ値へのアクセス不可) maxValueSize は maxTxSize より小さくしなければなりません

MVS-04 (~ - 既存のパラメータ値へのアクセス不可) maxValueSize は 減少させてはなりません

MVS-05（x - 「sensible output」は解釈の対象）maxValueSizeは、適切な出力が可能な大きさでなければなりません（例：既存のオンチェーン出力、または新しいledgerルールによって生成される可能性のある予想される出力）

Plutus コスト モデル (costModels)

CPUとメモリユニットの観点から各Plutusプリミティブの基本コストを定義します

  • 合計で約150の異なるマイクロパラメータがあります

コスト モデルは、Plutus 言語バージョンごとに定義されます。新しい言語バージョンでは、追加のマイクロ パラメータが導入されたり、既存のマイクロ パラメータが削除されたりする場合があります。

ガードレール

PCM-01 (x - 定量化不可能) *Cost model 値は、リファレンスアーキテクチャでのベンチマークによって設定されなければなりません

PCM-02 (x - プリミティブと言語バージョンはトランザクションには導入されない) 新しいプリミティブが導入されたり、新しいPlutus言語バージョンが追加された場合は、cost model は更新されなければなりません

PCM-03 (~ - 「Plutus cost model」 パラメータへのアクセス不可) Cost model の値は 負であるべきではありません

PCM-04 (~ -「Plutus cost model」 パラメータへのアクセス不可) プロトコルがサポートする各 Plutus 言語バージョンに対して Cost model を提供しなければなりません

2.5.ガバナンスパラメータ

ガバナンス パラメータを管理する際の全体的な目標は次のとおりです：

  1. ガバナンスの安定性を確保する
  2. CIP-1694 に概説されている代表的なガバナンスの形態を維持する

変化のきっかけ

ガバナンス パラメータの変更は、次の原因によって発生する可能性があります：

  1. コミュニティからのリクエスト
  2. 規制要件
  3. 予期しない、または望ましくないガバナンスの結果
  4. 不信任状態に陥る

対策指標

以下の場合には、変更を元に戻す必要がある場合や、変更を実施しない必要がある場合があります：

  • ガバナンスへの予期せぬ影響
  • オンチェーン投票やガバナンスアクションの過剰によるレイヤー1の過負荷

コア指標

パラメータ変更に関するすべての決定は、以下の情報に基づいて行う必要があります：

  • ガバナンス参加レベル
  • ガバナンス行動とパターン
  • 規制上の考慮事項
  • ガバナンス システムへの信頼
  • 必要な変更を管理するガバナンス システムの有効性

特定のガバナンスパラメータの変更

ガバナンスアクションのためのデポジット (govDeposit)

ガバナンスアクションを提出するときに請求されるデポジット

  • 提出されるアクションの数を制限するのに役立ちます
ガードレール

GD-01 (y) govDeposit は 負であってはなりません

GD-02 (y) govDeposit は 1,000,000 (1 ada) 未満であってはなりません

GD-03 (y) govDeposit は 10,000,000,000,000 (1000万ADA) を超えてはなりません

GD-04 (x - 「should」) govDeposit はフィアットの変更に合わせて調整されるべきです

DReps のデポジット (dRepDeposit)

DRep を登録する際に請求されるデポジット

  • アクティブな DRep の数を制限するのに役立ちます
ガードレール

DRD-01 (y) dRepDeposit は 負であってはなりません

DRD-02 (y) dRepDeposit は 1,000,000 (1 ada) 未満であってはなりません

DRD-03 (y) dRepDeposit は 100,000,000,000 (100,000 ada) を超えてはなりません

DRD-04 (x - 「should」) dRepDepositは、フィアットの変更に合わせて調整されるべきです

DRep アクティビティ期間 (dRepActivity)

DRep がいかなる提案にも投票しない場合、投票計算の目的で非アクティブであるとみなされる期間（エポックの全体数として）。

ガードレール

DRA-01 (y) dRepActivity は 13 エポック (2 か月) 未満であってはなりません

DRA-02 (y) dRepActivity は 37エポック（6か月）を超えてはなりません

DRA-03 (y) dRepActivity は 負であってはなりません

DRA-04 (~ - 既存のパラメータ値へのアクセス不可) dRepActivity は govActionLifetime より大きくなければなりません

DRA-05 (x - 「should」) dRepActivity は人間単位（2ヶ月など）で計算されるべきです

DRep および SPO ガバナンス アクションしきい値（dRepVotingThresholds[…]、poolVotingThresholds[…])

DRep または SPO のいずれかによる特定の種類のガバナンス アクションを承認するために必要なアクティブな投票ステークのしきい値

  • 行動の正当性を保証する

しきい値パラメータは以下のとおりです:

dRepVotingThresholds（dRep投票しきい値）：

  • dvtCommitteeNoConfidence
  • dvtCommitteeNormal
  • dvtHardForkInitiation
  • dvtMotionNoConfidence
  • dvtPPEconomicGroup
  • dvtPPGovGroup
  • dvtPPNetworkGroup
  • dvtPPTechnicalGroup
  • dvtTreasuryWithdrawal
  • dvtUpdateToConstitution

poolVotingThresholds（プール投票しきい値）:

  • pvtCommitteeNoConfidence
  • pvtCommitteeNormal
  • pvtHardForkInitiation
  • pvtMotionNoConfidence
  • pvtPPSecurityGroup
ガードレール

VT-GEN-01 (y) すべてのしきい値は 50%より大きく、100%以下でなければなりません

VT-GEN-02 (y) 経済、ネットワーク、技術パラメータのしきい値は 51%～75%の範囲でなければなりません

VT-GEN-03 (y) ガバナンスパラメータのしきい値は 75%～90%の範囲でなければなりません

VT-HF-01 (y) Hard forkアクションしきい値は 51%-80%の範囲でなければなりません

VT-CON-01 (y) New Constitution or guardrails script actionのしきい値は 65%-90%の範囲でなければなりません

VT-CC-01 (y) Update Constitutional Committee actionのしきい値は 51%-90%の範囲でなければなりません

VT-NC-01 (y) No confidenceアクションしきい値は 51%-75%の範囲でなければなりません

ガバナンス アクションの有効期間 (govActionLifetime)

ガバナンスアクションが実行されなかった場合にその期限が切れるまでの期間

  • エポックの全体数として
ガードレール

GAL-01 (y) govActionLifetime は 1 エポック (5 日) 未満であってはなりません

GAL-03 (x - 「should」) govActionLifetime は 2 エポック (10 日) 未満であるべきではありません

GAL-02 (y) govActionLifetime は 15 エポック (75 日) を超えてはなりません

GAL-04 (x - 「should」) *govActionLifetime は、投票などが行われるのに十分な時間を確保するために、人間の時間（例えば30日、2週間）で調整されるべきです

GAL-05 (~ - 既存のパラメータ値へのアクセス不可) govActionLifetime は dRepActivity より小さくなければなりません

憲法委員会の最大任期 (committeeMaxTermLimit)

委員の任期の上限

ガードレール

CMTL-01 (y) committeeMaxTermLimit は ゼロであってはなりません

CMTL-02 (y) committeeMaxTermLimit は 負であってはなりません

CMTL-03 (y) committeeMaxTermLimit は 18 エポック (90 日、または約 3 か月) 未満であってはなりません

CMTL-04 (y) committeeMaxTermLimit は 293エポック（約4年）を超えてはなりません

CMTL-05 (x - 「should」) committeeMaxTermLimit は 220 エポック (約 3 年) を超えるべきではありません

憲法委員会の最小規模 (committeeMinSize)

憲法委員会を変更するガバナンスアクションの後に憲法委員会に含めることができるメンバーの最小数

ガードレール

CMS-01 (y) committeeMinSize は 負であってはなりません

CMS-02 (y) committeeMinSize は 3 未満であってはなりません

CMS-03 (y) committeeMinSize は 10を超えてはなりません

2.6.パラメータ変更の監視と復帰

すべてのネットワークパラメータの変更は、少なくとも2エポック（10日間）は注意深く監視されなければなりません

  • 6時間のローリングウィンドウにおいて、ブロックの伝播遅延がブロックの5%以上で4.5秒を超えた場合、変更はできるだけ早く元に戻さなければなりません

その他のパラメータの変更はすべて監視すべきです

  • 復帰計画は、パフォーマンス、セキュリティ、機能性への全体的な影響が容認できない場合に実施されるべきです

各パラメーターの変更について、具体的な復帰/回復計画を作成しなければなりません。この計画には以下が含まれなければなりません：

  • 以前の状態（または類似の状態）に戻すために、どのパラメータをどのように変更する必要があるか
  • 致命的な障害が発生した場合にネットワークを復元する方法

パラメータ変更後に問題が発生した場合、この計画に従うべきです。すべての変更を元に戻せるわけではないことに注意してください。これらのパラメータを変更する場合は、さらに注意する必要があります。

2.7. 更新不可能なプロトコルパラメータ

一部の基本的なプロトコル パラメータは、プロトコル パラメータ更新ガバナンス アクションでは変更できません。これらのパラメータは、ハード フォークの一部として新しい Genesis ファイルでのみ変更できます。これらのパラメータの更新に関して、特定のガードレールを提供する必要はありません。

3. トレジャリー引き出しアクションに関するガードレールとガイドライン

Treasury withdrawal アクションは、Cardano トレジャリーからの引き出し先と金額を指定します。

ガードレール

TREASURY-01 (x) DReps は、一定期間ごとに Cardano トレジャリーの残高の純変更制限を定義しなければなりません

TREASURY-02 (x) Cardano トレジャリーの予算は、一定期間の Cardano トレジャリー 残高の純変更限度を超えてはなりません

TREASURY-03 (x) Cardano トレジャリー の予算は ADA 建てでなければなりません

TREASURY-04 (x) トレジャリー引き出しは、DReps が合意した以前のオンチェーン ガバナンス アクションに従って、アクティブな投票ステークの 50% を超えるしきい値でコミュニティが承認した Cardano 予算が存在するまで、承認してはなりません

4. ハードフォーク開始アクションに関するガードレールとガイドライン

hard fork initiation アクションでは、新しいメジャー プロトコル バージョンと新しいマイナー プロトコル バージョンの両方を指定する必要があります。

  • 正の整数です

ハードフォークの結果、新しい更新可能なプロトコル パラメータが導入される可能性があります。これらのパラメータに対してガードレールが定義され、ハードフォーク後に有効になります。既存の更新可能なプロトコル パラメータもハードフォークによって廃止される可能性があり、その場合、ガードレールは将来のすべての変更に対して無効になります。

ガードレール

HARDFORK-01 (~ - 既存のパラメータ値へのアクセス不可) メジャー プロトコル バージョンは、この変更の直前に施行されるメジャーバージョンと同じか、それ以上でなければなりません。メジャープロトコルのバージョンが1つ大きい場合、マイナープロトコルのバージョンはゼロでなければなりません。

HARDFORK-02 (~ - 既存のパラメータ値へのアクセス不可) マイナー プロトコル バージョンは、この変更の直前に施行されるマイナー バージョン以上でなければなりません

HARDFORK-03 (~ - 既存のパラメータ値へのアクセス不可) 少なくとも 1 つのプロトコル バージョン (メジャー バージョン、マイナー バージョン、またはその両方) を変更しなければなりません

HARDFORK-04 (x) アクティブステークによるステークプールの少なくとも85%は、新しいプロトコルバージョンに関連付けられたルールを処理できるCardanoノードバージョンにアップグレードされているべきです

HARDFORK-05 (x) ハードフォークで導入される新しい更新可能なプロトコルパラメータはすべて、この付録に含めなければならず、それらのパラメータに対して適切なガードレールが定義されます

HARDFORK-06 (x) ハードフォークで導入される新しいプロトコルパラメータの設定は、適切な Genesis ファイルに含めなければなりません

HARDFORK-07 (x) すべての非推奨プロトコルパラメータは、この付録に記載されなければなりません

HARDFORK-08 (~ - Plutus cost model パラメータへのアクセス不可) 新しい Plutus バージョンは、新しい Plutus バージョンで使用可能な各プリミティブをカバーするバージョン固有の Plutus cost model によってサポートされなければなりません

5. 憲法委員会またはしきい値アクションの更新に関するガードレールとガイドライン

Update Constitutional Committee or Threshold ガバナンスアクションにより、憲法委員会の規模、構成、または必要な投票しきい値が変更される場合があります。

ガードレール

UPDATE-CC-01 (x) Update Constitutional Committee and/or threshold and/or termガバナンスアクションは、ADA保有者がオンチェーンガバナンスアクションを通じて最終憲法を承認するまで、承認してはなりません

6. 新しい憲法またはガードレール スクリプト アクションに関するガードレールとガイドライン

新しい憲法またはガードレール スクリプト アクションは、オンチェーン憲法のハッシュと関連するガードレール スクリプトを変更します。

ガードレール

NEW-CONSTITUTION-01 (x) ハードフォークガバナンスアクションによって導入される新しいパラメータに必要なガードレールを定義するために、New Constitution or Guardrails Scriptガバナンスアクションが提出されなければなりません

7. 不信任決議に関するガードレールとガイドライン

No confidenceアクションは、統治システムに対する不信任の状態を示すものです。No Confidenceアクションにはガードレールはありません。

ガードレール
  • ありません

8. 情報行動に関するガードレールとガイドライン

Info アクションはオンチェーンで実行されません。Info アクションにはガードレールはありません。

ガードレール
  • ありません

9. 暫定期間中のガードレール

暫定期間

暫定期間は Chang ハードフォークから始まり、コミュニティが承認した最終憲法がオンチェーンで承認された後に終了します。暫定期間中、技術的および憲法で強制されるトリガーにより、CIP-1694 の機能が徐々に有効になります。

暫定期間の技術展開:

  • Chang ハードフォークにより、最初の 3 つの CIP-1694 ガバナンス アクションが可能になり、代表的なフレームワークを確立できるようになります。

これらのアクションは、“Info”、“Hard-fork initiation”、“Protocol parameter changes” アクションです。

ADA 保有者はハードフォーク後すぐに DRep として登録し、委任することができますが、CIP-1694 に記載されているように、“Info” アクション以外では DRep 投票は利用できません。これにより、ADA 保有者は十分な時間を取って投票委任先を選択できます。

SPO は CIP-1694 に記載されているとおりに投票できます。

“Hard-fork initiation” および “Protocol parameter changes” アクションも憲法委員会によって承認される予定です。

ADA保有者は通常通りステーキング報酬を引き出すことができます。

  • Chang ハードフォークの直後に憲法委員会と SPO によって承認された後続のハードフォークにより、残りの 4 つの CIP-1694 ガバナンス アクションが有効になります：
    • “treasury withdrawals”
    • “motion of no-confidence”
    • “update constitutional committee and/or threshold and/or terms”
    • “new constitution or guardrails script”

この時点で、DRep 投票が有効になり、ADA 保有者が投票を委任した場合にのみステーキング報酬を引き出すことができます (事前定義された棄権/不信任投票オプションを含む)。

ガードレール

INTERIM-01 (x) DRep が登録してキャンペーンを実施し、ADA 保有者が最初の投票代表団を選択するのに十分な時間を確保するため、Chang ハードフォーク後、次のハードフォークが承認されるまでに少なくとも 18 エポック (90 日間、または約 3 か月) が経過しなければなりません。次のハードフォークが施行されると、CIP 1694 に記載されているように DRep 投票が行われます。

INTERIM-02 (x) トレジャリーからの引き出しは、以前のオンチェーンガバナンスアクションに従ってコミュニティによって承認されたCardanoブロックチェーンエコシステム予算が有効になるまで、承認されてはなりません

INTERIM-03 (x) トレジャリーからの引き出しは、コミュニティが承認したCardanoブロックチェーンエコシステムの予算と一致していなければなりません

INTERIM-04 (x) ADA保有者は、“new constitution”、"update constitutional committee、and/or threshold and/or terms"、および**“motion of no confidence”**のガバナンスアクションの提案を承認する前に、付録IIに指定されている最終憲法を承認していなければなりません

INTERIM-05 (x) 暫定憲法と一致する “New guardrails script” アクションは、暫定憲法自体が変更されない限り、暫定期間中に承認される可能性があります。

10. プロトコルパラメータグループのリスト

プロトコル パラメータはタイプごとにグループ化されており、グループごとに異なるしきい値を設定できます。

ネットワーク グループは以下の要素で構成されています：

  • 最大ブロック本体サイズ (maxBlockBodySize)
  • 最大トランザクションサイズ (maxTxSize)
  • 最大ブロックヘッダーサイズ(maxBlockHeaderSize)
  • シリアル化された資産価値の最大サイズ* (maxValueSize)
  • 単一トランザクション内の最大スクリプト実行単位(maxTxExecutionUnits[steps])
  • 単一ブロック内の最大スクリプト実行単位(maxBlockExecutionUnits[steps])
  • 担保入力の最大数 (maxCollat​​eralInputs)

経済グループは以下の要素で構成されています:

  • 最小手数料係数 (txFeePerByte)
  • 最小手数料定数 (txFeeFixed)
  • リファレンススクリプトのバイトあたりの最小手数料(minFeeRefScriptCoinsPerByte)
  • 委任キー Lovelace デポジット (stakeAddressDeposit)
  • プール登録 Lovelace デポジット* (stakePoolDeposit)
  • 通貨拡張 (monetaryExpansion)
  • トレジャリー拡張 (treasuryCut)
  • プールの最小固定報酬カット (minPoolCost)
  • シリアル化された UTxO のバイトあたりの最小 Lovelace デポジット (coinsPerUTxOByte)
  • Plutus 実行ユニットの価格(executionUnitPrices[priceSteps/priceMemory])

技術グループは以下の要素で構成されています：

  • プールpledgeの影響力 (poolPledgeInfluence)
  • プールリタイアの最大エポック (poolRetireMaxEpoch)
  • 必要なプールの数 (stakePoolTargetNum)
  • Plutus 実行コスト モデル (costModels)
  • スクリプトに必要な担保の割合 (collat​​eralPercentage)

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

  • ガバナンス投票しきい値(dRepVotingThresholds[…]、poolVotingThresholds[…])
  • ガバナンスアクションの最大存続期間 (エポック単位) (govActionLifetime)
  • ガバナンスアクションのデポジット (govActionDeposit)
  • DRep デポジット額 (dRepDeposit)
  • DRep アクティビティ期間 (エポック単位) (dRepActivity)
  • 憲法委員会の最小サイズ (committeeMinSize)
  • 憲法委員会メンバーの最大任期 (エポック単位) (committeeMaxTermLimit)