Cardanoブロックチェーンエコシステム暫定憲法(AI翻訳版)と要約

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

要約

Cardanoブロックチェーンエコシステム暫定憲法は８つの章と２つの付録で構成されます。最初の１ー３章ではCardanoとガバナンスについての全体像が記載されます。４−６章はガバナンスの３つの主人公であるDRep、SPO、憲法委員会について記載されます。７章では改正手続き、８章では最終憲法の承認までの暫定期間における説明が記載されます。

前文 (Preamble)：Cardanoの歴史と、暫定憲法の設立目的について説明しています。

第I章：Cardano Blockchain Ecosystem Principles

第1節: 強固なガバナンスフレームワークの確立
第2節: 投票ベースの意思決定モデル
第3節: Cardano Blockchainガードレールに基づく運営

第II章：The Cardano Blockchain Community

第1節: 形式的なメンバーシップ要件なし
第2節: ADA保有者の権利と参加
第3節: コミュニティメンバーの責任
第4節: コラボレーションとアプリケーション開発

第III章：Participatory Governance

第1節: 分散型オンチェーンガバナンスモデル
第2節: 三つの独立したガバナンス機関
第3節: 集団意思決定プロセス
第4節: ADA保有者の投票権
第5節: コミュニティの意見を反映する特別なガバナンスアクション
第6節: ガバナンスアクションの標準化と透明性
第7節: オフチェーンガバナンスプロセスのサポート
第8節: 100万ADAを超える財務要求に対する独立監査

第IV章：Delegated Representatives (DReps)

第1節: DRepの登録と投票
第2節: DRepのオプションと権利
第3節: DRepの報酬と透明性

第V章：Stake Pool Operators (SPOs)：SPOsの役割と重要なガバナンスアクションの監視。

第VI章：Constitutional Committee

第1節: 憲法委員会の設立と役割
第2節: 憲法委員会の構成と任期
第3節: 憲法委員会のプロセスと透明性
第4節: コミュニティサポート

第VII章：Amendments：暫定憲法やガードレールの改正手続き。

第VIII章：Interim Period：最終憲法が承認されるまでの暫定期間に関する説明。

付録I: Cardano Blockchain Guardrails：Cardanoブロックチェーンの運営に関する具体的なガイドラインやパラメータの設定。

付録II: Ratification of Final Constitution：最終憲法の承認手続きに関する詳細。

全文

序文

これは、CIP-1694 が発効するために必要な条項とガードレールを含む、暫定的な最小限の実行可能な憲法です。暫定的なものです。最終憲法は、ADA 保有者によって批准される必要があります。このような批准は、2024 年末または 2025 年初頭に行われると予想されています。したがって、最終憲法は、Cardano コミュニティの希望に基づいて、この暫定憲法とは大幅に異なる可能性があります。2024 年中に、Cardano コミュニティが最終憲法を完成させるプロセスに参加できるように、世界中で一連のワークショップが開催されます。さらに、最終憲法は発効前に ADA 保有者の承認が必要になります。このような承認は 2025 年の初めに行われると予想されています。ただし、オンチェーン ガバナンスは 2024 年中に導入され、最終憲法が批准される前に強力な憲法と憲法委員会が必要になるため、この暫定憲法には、CIP-1694 のニーズと要件をサポートして実行するために必要な規定とガードレールが含まれ、最終憲法が批准される日まで、この暫定憲法で特定された原則が損なわれないことを保証する必要があります。

この暫定憲法に取り組むにあたっては、これがブロックチェーンだけの憲法ではなく、ブロックチェーン エコシステムの憲法であり、はるかに野心的な取り組みであることを忘れてはなりません。したがって、ガバナンス アクションの承認方法は非常に重要ですが、この暫定憲法の唯一の焦点では​​ありません。むしろ、この暫定憲法は、Cardano ブロックチェーン エコシステムのすべての関係者が集まって自らを統治し、人間の相互作用とコラボレーションに対する根本的に新しいアプローチを形成するための基礎と基本的な枠組みを提供します。必然的に、この暫定憲法は、憲法委員会の役割を認識して権限を与え、Cardano コミュニティが共同体に参加してコラボレーションを行う権利を確認し、オンチェーン ガバナンスを実施し、委任された代表者 (DReps と呼ばれる) にオンチェーン投票で Ada 保有者の代弁者として行動する権限を与えます。また、暫定憲法は、この暫定憲法に Cardano ガードレールを組み込むことにより、暫定期間中に Cardano の資金へのアクセスと使用を保護する必要性を認識しています。

前文

Cardano ブロックチェーン エコシステムの始まりには、IOHK、Emurgo、Cardano 財団という 3 つの先駆的な組織が協力して、新しいブロックチェーンである Cardano ブロックチェーンの出現を促進し、個人に力を与え、コラボレーションとイノベーションを促進する分散型ネットワークの基盤を築きました。彼らの先駆的な取り組みにより、すべての参加者が Cardano ブロックチェーン エコシステムの成長と成功に貢献できる、公正で透明な環境を確保するように設計されたブロックチェーンへの道が形作られました。

時間の経過とともに、Cardano ブロックチェーン エコシステムは大幅に拡大し、現在では何千もの ADA 保有者、個人、ビルダー、開発者、企業、ステーク プール、Cardano ブロックチェーン ユーザーなどで構成される Cardano ブロックチェーン エコシステムは、真に分散化された方法で運営され、Cardano ブロックチェーン エコシステムの回復力と自律性がさらに強化されています。Cardano ブロックチェーン エコシステムが成長を続けるにつれ、Cardano ブロックチェーン エコシステムの始まりからの基礎となっている分散化、コミュニティの関与、包括性、コラボレーションの原則を反映して、同様にガバナンス モデルを適応および進化させることが不可欠になっています。

より堅牢でダイナミックなガバナンス フレームワークの必要性、そしてガバナンス プロセスにおいて可能な限り有益なブロックチェーン テクノロジーを活用するフレームワークの必要性を認識し、分散型 Cardano ブロックチェーン エコシステムのメンバーである Cardano コミュニティは、ここに Cardano 暫定憲章を制定します。これは、私たちの共同の取り組みの運営とガバナンスの指針となる一連の原則として機能し、すべての参加者が Cardano ブロックチェーン エコシステム全体の改善に貢献できる環境を育みます。

カルダノ コミュニティは、この暫定憲法の原則を遵守し、カルダノ ブロックチェーンとして知られる分散型ブロックチェーン エコシステムの継続的な改善、成長、成功に向けて協力することを約束します。

この暫定憲法は、分散型カルダノ ブロックチェーン エコシステムの運用とガバナンスの指針となる原則を具体化したものであり、カルダノ コミュニティの継続的なニーズを満たすために時間の経過とともに適応し進化する基盤を提供します。カルダノ コミュニティのすべてのメンバーは、この暫定憲法を遵守することが求められ、ADA 保有者によって承認される最終憲法の完成を含むガバナンス プロセスに参加する権利があり、カルダノ ブロックチェーン エコシステム全体の改善に向けて協力して取り組み、その成長、持続可能性、成功に貢献することが奨励されます。

第1条 カルダノブロックチェーンエコシステムの原則

セクション1

カルダノ ブロックチェーン エコシステムは、憲法を採択することで、堅牢なガバナンス フレームワークを確立し、カルダノ コミュニティの利益を最優先に考えた決定が確実に行われるようにします。カルダノ コミュニティは、透明性、オープン性、責任あるガバナンスの原則を守り、信頼とコラボレーションの文化を促進します。

第2節

Cardano ブロックチェーンは、投票ベースの意思決定モデルに基づいて管理され、包括性、多様な見解、革新性、適応性を促進します。すべての ADA 保有者は、分散型 Cardano ブロックチェーン エコシステムのガバナンスと方向性に貢献する機会を持ちます。

セクション3

カルダノ ブロックチェーンは、この暫定憲章のガードレール付録に規定されているカルダノ ブロックチェーン ガードレールに従って運営されるものとします。

第2条 カルダノブロックチェーンコミュニティ

セクション1

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

第2節

ADA を保有する Cardano コミュニティのメンバーは、Cardano ブロックチェーンに関するオンチェーン ガバナンスへの投票や参加など、Cardano ブロックチェーン エコシステムのオンチェーン意思決定プロセスにアクセスして参加する権利を持ちます。

セクション3

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

セクション4

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

第3条 参加型ガバナンス

セクション1

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

第2節

3 つの独立したガバナンス機関が、オンチェーン ガバナンス アクションの投票に参加し、委任代表者 (DRep)、ステーク プール オペレーター (SPO)、​​憲法委員会 (CC) で構成される Cardano ブロックチェーンのチェックとバランスを実現します。

セクション3

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

セクション4

すべての ADA 保有者は、CIP-1694 および Cardano ブロックチェーン ガードレールを含むこの暫定憲法で規定されている制限または要件に従い、オンチェーン ガバナンス アクションの意思決定プロセスで投票する権利を持ちます。投票権は保有する ADA に比例します。

すべてのADA保有者は、CIP-1694およびCardano Blockchain Guardrailsに従って、Cardano Blockchainエコシステムのガバナンス構造の変更を提案する権利を有します。

セクション5

チェーン上の変更をコミットせずにコミュニティの感情を測定できるようにするための特別な形式のガバナンス アクションが存在します。「情報」アクションは、アクションに対する投票を記録する以外にはチェーン上の効果はありません。

セクション6

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

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

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

すべての ADA 保有者は、ガバナンス活動への参加、提出、投票のプロセスがオープンかつ透明であり、不当な影響や操作から保護されていることを保証する権利を有します。

セクション7

カルダノ コミュニティは、CIP-1694 の要件を実施し、将来のすべてのガバナンス アクションを認識し、議論して形作る機会を確保するために、必要に応じてオフチェーン ガバナンス プロセスの作成、維持、継続的な管理をサポートすることが期待されています。

セクション8

1,000,000ADAを超えるADAをCardano財務から要求するガバナンスアクションには、定期的な独立監査の費用と、そのようなADAの使用に関する監視指標の実装をカバーするために、そのような資金要求の一部としてADAの割り当てが必要になります。

第4条 代表者

セクション1

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

第2節

すべての Ada 保有者は、DRep として登録するオプションがあります。すべての Ada 保有者は、自分自身を含む 1 人以上の登録済み DRep に投票権を委任できます。DRep は個人または調整されたグループです。DRep は、オンチェーン ガバナンス アクションに直接投票する権利があり、投票権を委任した Ada 保有者を代表します。この投票システムは、Ada 保有者がシームレスに DRep を選択し、DRep として登録し、いつでも委任を変更できる流動的な民主主義モデルを制定します。

Cardano コミュニティは、Ada 保有者が DRep 候補を探索および評価し、関連性があると思われる基準に基づいて DRep を選択できるようにするためのツールの作成、保守、継続的な管理をサポートすることが期待されています。

セクション3

DRep は、Cardano ブロックチェーン エコシステムの専門的なガバナンス コホートの作成を促進する取り組みに対して報酬を受け取る場合があります。DRep は、DRep としての活動に関連して受け取った報酬をすべて開示する必要があります。

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

SPO は、CIP-1694 および Cardano Blockchain Guardrails に規定されているように、DRep とは別個かつ独立して投票し、追加の監視と独立性を必要とする重要なオンチェーン ガバナンス アクションを承認する特定の役割を担います。SPO は、Cardano Blockchain のコンセンサス メカニズムに参加するノードのオペレーターとして、ハード フォークの開始プロセスに参加します。SPO は、例外的な状況下で「不信任動議」および「委員会/しきい値の更新」ガバナンス アクションに投票することにより、憲法委員会の権限をチェックする役割を果たします。

第六条 憲法委員会

セクション1

憲法委員会は、カルダノのオンチェーン ガバナンス プロセスの部門として設立され、ガバナンス活動がこの暫定憲法に準拠していることを保証します。憲法委員会は、オンチェーンでの制定前にオンチェーン ガバナンス活動が合憲であることを確認する共同責任を負う一連の ADA 保有者で構成されます。憲法委員会は、ガバナンス活動の合憲性に関する投票に限定されます。憲法委員会のメンバーは ADA 保有者であり、カルダノ ブロックチェーン エコシステムへの過去の貢献と関与を考慮して、適切な専門知識を持っていることが期待されます。

第2節

当初、憲法委員会は 7 名のメンバーで構成されます。最初の憲法委員会メンバーは、Chang ハードフォークの日付から始まる 73 エポックの就任任期を務めます。その後、オンチェーン ガバナンス アクションを通じて、ADA 保有者は Cardano ブロックチェーン ガードレールに従って憲法委員会のメンバー数を調整できます。Cardano コミュニティは憲法委員会メンバーの選出プロセスを確立し、Cardano ブロックチェーン ガードレールに従って憲法委員会の規模を随時決定し、Cardano ブロックチェーンの整合性を保証するために十分な数の憲法委員会メンバーが常に存在するようにします。憲法委員会メンバーの任期は、Cardano ブロックチェーン ガードレールに従って設定されます。

セクション3

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

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

セクション4

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

セクション5

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

第7条 改正

セクション1

カルダノ ブロックチェーン ガードレール付録を含むこの暫定憲法の修正は、適用される承認基準を満たすオンチェーン ガバナンス アクションを必要とする集団的意思決定プロセスによって承認されるものとします。

第8条 暫定期間

セクション1

暫定期間は、付録 II に規定されている最終憲法の批准に従って、ADA 保有者によって最終憲法が批准される日まで継続する一時的な期間とします。

第2節

この暫定憲法から最終憲法への移行プロセスについては付録 II に記載されています。

付録 I: カルダノ ブロックチェーン ガードレール

1 はじめに

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

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

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

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

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

この付録のガードレールは現時点では技術的知見の現状を反映していますが、この付録は生きた文書として扱われるべきです。Cardano ブロックチェーンの実装の改善、新しいシミュレーション、またはパフォーマンス評価の結果により、これらのガードレールに含まれる制限の一部が、いずれ緩和される可能性があります (または、状況によっては、制限が厳しくなる可能性があります)。たとえば、新しいプロトコル パラメーターが導入される場合、追加のガードレールが必要になることもあります。この付録に記載されているガードレールは、適用される投票しきい値を満たすオンチェーン ガバナンス アクションに従って、随時修正される場合があります。ガードレールの修正には、憲法自体の修正が必要であり、憲法自体の修正とみなされます。

用語とガイダンス

すべき/すべきでない。 この付録で、ある値を「下回って設定すべきではない」と記載されている場合、これはガードレールが推奨事項またはガイドラインであり、特定の値は、Cardano ブロックチェーンのガバナンス システムまたは Cardano ブロックチェーンの運用に関する経験を考慮して、Cardano コミュニティによって認められた適切な専門家グループによって議論または変更される可能性があることを意味します。

必須/必須ではありません。 この付録で、ある値を「ある値より下または上に設定してはならない」と記載されている場合、これはガードレールが、Cardano ブロックチェーンの元帳ルール、タイプ、またはその他の組み込みメカニズムによって可能な限り強制される要件であり、それに従わないと、プロトコル障害、セキュリティ侵害、またはその他の望ましくない結果が発生する可能性があることを意味します。

ベンチマーク。 ベンチマークとは、たとえば、すべてのケースで必要な 5 秒の時間間隔内に、Cardano ブロックチェーン ノードのグローバル ネットワーク全体にブロックの 95% が拡散されることを事前に示すように設計された、慎重なシステム レベルのパフォーマンス評価を指します。これには、特定のテスト ワークフローの構築と、Cardano ノードの大規模なテスト ネットワークでの実行が必要になり、グローバルな Cardano ブロックチェーン ネットワークをシミュレートする必要がある場合があります。

パフォーマンス分析。 パフォーマンス分析とは、理論的なパフォーマンス、経験的なベンチマーク、またはシミュレーションの結果を予測して、実際のシステムの動作を予測することを指します。たとえば、制御されたテスト環境 (既知のネットワーク プロパティを持つデータ センターのコレクションなど) でのテストから得られたパフォーマンス結果を推定して、実際の Cardano Blockchain ネットワーク環境での可能性のあるパフォーマンス動作を予測することができます。

シミュレーション。 シミュレーションとは、パフォーマンスや機能の決定を反復可能な方法で通知するように設計された合成実行を指します。たとえば、IOSim Cardano Blockchain モジュールを使用すると、ネットワーク スタックの動作を制御された反復可能な方法でシミュレートできるため、コードを展開する前に問題を検出できます。

パフォーマンス監視。 パフォーマンス監視には、タイミング プローブを使用してラウンドトリップ時間を評価したり、ブロックをテストしてネットワーク全体の健全性を評価したりするなど、Cardano ブロックチェーン ネットワークの実際の動作を測定することが含まれます。シミュレートされたワークロードや理論的な分析では取得できない実際のシステム動作に関する情報を提供することで、ベンチマークとパフォーマンス分析を補完します。

変更を元に戻す。 パフォーマンス監視により、変更後の実際のネットワーク動作が Cardano ブロックチェーンのパフォーマンス要件と一致していないことが判明した場合、可能であれば変更を以前の状態に戻す必要があります。たとえば、ブロック サイズが 100 KB から 120 KB に増加し、ブロックの 95% が 5 秒以内に拡散されなくなった場合は、ブロック サイズを 100 KB に戻す変更を行う必要があります。これが不可能な場合は、パフォーマンス要件が満たされるように 1 つ以上の代替変更を行う必要があります。

重大度レベル。Cardano ブロックチェーン ネットワークに影響を与える問題は、重大度レベルによって分類されます。

  • 重大度1は、Cardanoブロックチェーンネットワークのセキュリティ、パフォーマンス、または機能に非常に大きな影響を与える重大なインシデントまたは問題です。
  • 重大度2は、Cardanoブロックチェーンネットワークのセキュリティ、パフォーマンス、または機能に重大な影響を与える重大なインシデントまたは問題です。
  • 重大度3は、Cardanoブロックチェーンネットワークのセキュリティ、パフォーマンス、または機能への影響が低い軽微なインシデントまたは問題です。

将来のパフォーマンス要件。 メモリ外ストレージの新しいメカニズムなどの計画された開発は、ブロックの拡散やその他の時間に影響を与える可能性があります。パラメータを変更するときは、Cardano ブロックチェーンの現在の動作だけでなく、これらの将来のパフォーマンス要件も考慮する必要があります。開発が完了するまで、要件は控えめになりますが、実際のタイミング動作を考慮して緩和される可能性があります。

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

スクリプト ハッシュは、規約の更新または提案ポリシーの ガバナンス アクションが施行されるときに、規約ハッシュに関連付けられます 。これは、台帳のルールとタイプに対する追加の保護手段として機能し、準拠していないガバナンス アクションをフィルター処理します。

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

  • パラメータ更新 アクション、および
  • 財務省の引き出し 措置。

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

シンボルと説明

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

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

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

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

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

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

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

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

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

ガードレール

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

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

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

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

ブロックチェーンの運用に重要なパラメータ
  • 最大ブロック本体サイズ ( maxBlockBodySize )
  • 最大トランザクション サイズ ( maxTxSize )
  • 最大ブロック ヘッダー サイズ ( maxBlockHeaderSize )
  • シリアル化された資産値の最大サイズ ( maxValueSize )
  • 1ブロックあたりのスクリプト実行/メモリ単位の最大数 ( maxBlockExecutionUnits[steps/memory] ​​)
  • 最小手数料係数 ( txFeePerByte )
  • 最低手数料定数 ( txFeeFixed )
  • 参照スクリプトのバイトあたりの最小料金 ( minFeeRefScriptCoinsPerByte )
  • シリアル化された UTxO のバイトあたりの最小 Lovelace デポジット ( utxoCostPerByte )
  • ガバナンスアクションデポジット ( govDeposit )
ガードレール

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

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

ガバナンスシステムにとって重要なパラメータ
  • 委任キー Lovelace デポジット ( stakeAddressDeposit )
  • プール登録 Lovelace デポジット ( stakePoolDeposit )
  • プールの最小固定報酬カット ( minPoolCost )
  • DRepデポジット額 （dRepDeposit ）
  • 憲法委員会の最小規模 ( committeeMinSize )
  • 憲法委員会メンバーの最大任期（エポック単位） （committeeMaxTermLimit ）
ガードレール

PARAM-05 (y) DRep は、すべての有効な投票権の 50% を超える集合的な支持を得て「はい」に投票する必要があります 。これは、DRep 投票しきい値のガードレールによって強制されます。

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

2.2 経済パラメータ

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

  1. Cardano ブロックチェーン エコシステムの長期的な経済的持続可能性を実現します。
  2. ステークプールがCardanoブロックチェーンの維持に対して適切な報酬を受け取ることを保証する。
  3. ブロック生成のためにADAを委任する場合を含め、建設的な方法でステークを使用することでADA保有者が適切に報酬を得られるよう保証する。
  4. ステークプールオペレーター、ADA保有者、DeFiユーザー、インフラストラクチャユーザー、開発者（DAppsなど）、金融仲介者（取引所など）など、Cardanoブロックチェーンエコシステムのさまざまな利害関係者に対する経済的インセンティブのバランスをとる
変化のきっかけ
  • ADAの法定通貨価値の大幅な変化により、セキュリティ、パフォーマンス、機能に潜在的な問題が発生する可能性があります。
  • 取引量や取引形態の変化
  • コミュニティからのリクエストや提案
  • 経済パラメータの変更を必要とする緊急事態
カウンターインジケーター

経済指標の変更は単独で行うべきではありません。以下の点を考慮する必要があります。

  • 外部経済要因
  • ネットワークセキュリティの懸念
コアメトリクス
  • ADAの法定価値により、セキュリティ、パフォーマンス、機能に潜在的な問題が生じる可能性がある
  • 取引量と種類
  • ステークプールの数と健全性
  • 外部経済要因

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

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

Lovelace での基本トランザクションのコストを定義します。

手数料(tx) = txFeeFixed + txFeePerByte x nBytes(tx)

ガードレール

TFPB-01 (y) txFeePerByteは30（0.000030 ada）未満であっては なりません。 これにより、低コストのサービス拒否攻撃から保護されます。

TFPB-02 (y) txFeePerByteは1,000（0.001 ada）を超えては なりません。 これにより、トランザクションの支払いが確実に行われます。

TFPB-03 (y) txFeePerByte は 負であってはならない

TFF-01 (y) txFeeFixedは100,000 (0.1 ada) 未満であっては なりません。 これにより、低コストのサービス拒否攻撃から保護されます。

TFF-02 (y) txFeeFixedは10,000,000（10 ada）を超えては なりません 。これにより、トランザクションの支払いが確実に行われます。

TFF-03 (y) txFeeFixedは 負であってはならない

TFGEN-01 (x - 「すべき」) サービス拒否攻撃に対する一貫したレベルの保護を維持するために、 Plutus 実行価格が調整されるたびにtxFeeFixed とtxFeeFixed を調整する 必要があります (executionUnitPrices[steps/memory])

TFGEN-02 (x - 定量化不可) txFeeFixed またはtxFeeFixed への変更は、 サービス拒否攻撃のコスト削減の影響、またはトランザクションの構築が不可能になるような最大トランザクション手数料の増加を考慮する必要があります。

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

UTxOsのストレージコストを定義する

  • 単一の UTxO 内に保持される ada の最小しきい値を設定します (最小 ~1 ada、最悪の場合 >= 50 ada になる可能性があります)
  • UTxO ストレージに対する低コストのサービス拒否攻撃に対する保護を提供します。この攻撃は他のチェーンで実行されていますが、理論上のものではありません。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 - 「すべき」) 変更では、i) 攻撃の許容コスト、ii) 攻撃の許容時間 (少なくとも 1 エポックと想定)、iii) フルノード ユーザーの許容メモリ構成 (ウォレットの場合は 16 GB、ステーク プールの場合は 24 GB と想定)、iv) UTxO のサイズ (UTxO あたり最小 200B、最大約 10KB)、v) 現在のノード メモリ使用量の合計を考慮する必要があります。

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

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

  • 長期保管コストの削減に役立ちます
  • 元帳のCPUとメモリのコストを制限するのに役立ちます

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

ガードレール

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

SAD-02 (y)ステークアドレスデポジットは 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)財務カットは 0.1 (10%) 未満であってはならない

TC-02 (y)財務カットは 0.3（30%）を超えてはならない

TC-03 (y) treasuryCut は マイナスであってはならない

TC-04 (y)財務カットは 1.0 (100%) を超えてはならない

TC-05 (~ - 変更履歴にアクセスできません) treasuryCut は 、36 エポック期間 (約 6 か月) 内に 1 回以上変更することはできません。

通貨拡張率 (monetaryExpansion)

報酬メカニズムの一部

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

カルダノの長期的な持続可能性を左右する

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

ME-01 (y)金銭的拡張は 0.005を超えてはならない

ME-02 (y)通貨拡張は 0.001未満であってはならない

ME-03 (y)通貨拡張は 負であってはならない

ME-04 (x - 「すべき」)通貨拡張は、 73エポック期間（約12か月）で+/- 10%を超えて変化してはならない

ME-05 (x - 「すべき」)通貨拡張は、 36エポック期間（約6か月）内に1回以上変更してはならない

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

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

Plutusスクリプトの実行に対して経済的な利益をもたらす

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

ガードレール

EIUP-PS-01 (y)実行単位価格[価格ステップ] は2,000 / 10,000,000を超えてはなりません

EIUP-PS-02 (y)実行単位価格[価格ステップ] は500 / 10,000,000未満であってはなりません

EIUP-PM-01 (y)実行単位価格[priceMemory]は 2,000/10,000を超えてはならない

EIUP-PM-02 (y)実行単位価格[priceMemory]は 400/10,000未満であってはならない

EIUP-GEN-01 (x - 「類似」) 実行価格は、i ) 最大 CPU ステップでトランザクションを実行するコストが最大サイズの非スクリプト トランザクションのコストと類似し、ii) 最大メモリ ユニットでトランザクションを実行するコストが最大サイズの非スクリプト トランザクションのコストと類似するように設定する必要があります。

EIUP-GEN-02 (x - 「すべき」)トランザクション手数料が調整されるたびに、実行価格も調整する必要があります( txFeeFixed/txFeePerByte )。目標は、トランザクションの種類に関係なく、処理遅延が「フル」トランザクションで同じになるようにすることです。これにより、ブロックの拡散/伝播時間の要件が満たされます。

参照スクリプトのバイトあたりのトランザクション手数料 (minFeeRefScriptCoinsPerByte)

Lovelace で Plutus 参照スクリプトを使用するコストを定義します

ガードレール

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

  • これにより、取引の支払いが確実に行われるようになる。

MFRS-02 (y) minFeeRefScriptCoinsPerByte は 負であってはならない

MFRS-03 (x - 「すべき」) サービス拒否攻撃に対する一貫したレベルの保護を維持するために、Plutus 実行価格が調整されるたびに ( executionUnitPrices[steps/memory] )、およびtxFeeFixed が調整されるたびに、 minFeeRefScriptCoinsPerByteを調整する 必要があります。

MFRS-04 (x - 定量化不可能) minFeeRefScriptCoinsPerByte を変更する場合は、サービス拒否攻撃のコスト削減や最大取引手数料の増加の影響を考慮する必要があります。

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

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

  1. 利用可能なCardanoブロックチェーンレイヤー1ネットワーク容量を、支払い取引、レイヤー1 DApp、サイドチェーン管理、ガバナンスのニーズなど、現在または将来のトラフィック需要に合わせます。
  2. 支払い取引、代替可能/非代替可能トークンのミント、Plutusスクリプト、DeFi開発者、ステークプールオペレーター、投票取引など、さまざまなユーザーグループのトラフィック需要のバランスをとる
変化のきっかけ

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

  1. 2エポック期間（10日間）にわたる交通需要の測定された変化
  2. 予想される交通需要の変化
  3. コミュニティのリクエスト
カウンターインジケーター

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

  • ブロック伝播の遅延が大きすぎる
  • ステークプールがトラフィック量を処理できない
  • スクリプトが実行を完了できない
コアメトリクス

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

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

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

ガードレール

NETWORK-01 (x - “すべき”) 個々のネットワークパラメータは 2エポックごとに1回以上変更されるべきではない

NETWORK-02 (x - “should”) 直接相関しない限り、エポックごとに 1 つのネットワーク パラメータのみを変更する必要があります (例: トランザクションごと、ブロックごとのメモリ ユニット制限)。

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

ブロック サイズ (maxBlockBodySize)

ブロックの最大サイズ（バイト単位）。

ガードレール

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

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

MBBS-03 (x - 「例外的な状況」)セキュリティ、パフォーマンス、または機能に潜在的な問題がある例外的な状況を除き、maxBlockBodySizeを小さくして はいけません。

MBBS-04 (~ - 既存のパラメータ値にアクセスできません) maxBlockBodySize は、少なくとも 1 つのトランザクションを含めるのに十分な大きさである 必要があります (つまり、maxBlockBodySize は 少なくともmaxTxSize である必要があります)

MBBS-05 (x - “すべき”) maxBlockBodySize は、エポック (5 日間) ごとに最大 10,240 バイト (10 KB) まで変更する 必要があります 。できれば、エポックごとに 8,192 バイト (8 KB) 以下に変更してください。

MBBS-06 (x - 「すべき」) ブロック サイズは、追加の伝送制御プロトコル (TCP) ラウンド トリップを誘発してはならない 。これを超える増加は、パフォーマンス分析、シミュレーション、およびベンチマークによって裏付けられる必要がある。

MBBS-07 (x - 「定量化不可能」) maxBlockBodySize の変更の影響は、 詳細なベンチマーク/シミュレーションによって確認する必要があり、以下に説明するように、ブロック拡散/伝播時間予算の要件を超えてはなりません。maxBlockBodySize を増やす場合は、5 秒以内に 95% のブロック伝播を伴う 3 秒の合計ブロック拡散目標に対するPlutus スクリプト実行 ( maxBlockExecutionUnits[steps] ) の将来の要件も考慮する必要があります。最大ブロック サイズの制限は、ベンチマークと監視結果によってサポートされている場合は、将来的に増加する可能性があります。

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

トランザクションの最大サイズ（バイト単位）。

ガードレール

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

MTS-02 (y) maxTxSizeは 負であってはならない

MTS-03 (~ - 既存のパラメータ値にアクセスできない) maxTxSize を 小さくしてはならない

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

MTS-05 (x - 「すべき」) maxTxSize は 、どのエポックでも 2,560 バイト (2.5KB) を超えて増加してはならず 、できればエポックごとに 2,048 バイト (2KB) 以下で増加する必要があります。

MTS-06 (x - “すべき”) maxTxSize は ブロックサイズの 1/4 を超えてはならない

メモリユニットの制限 (maxBlockExecutionUnits[memory]、maxTxExecutionUnits[memory])

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

ガードレール

MTEU-M-01 (y) maxTxExecutionUnits[メモリ]は 40,000,000ユニットを超えてはならない

MTEU-M-02 (y) maxTxExecutionUnits[memory] は負であってはならない

MTEU-M-03 (~ - 既存のパラメータ値にアクセスできない) maxTxExecutionUnits[memory] ​​を減らしてはいけません

MTEU-M-04 (x - 「すべき」) maxTxExecutionUnits[メモリ]は、 どのエポックでも2,500,000ユニットを超えて増加してはならない

MBEU-M-01 (y) maxBlockExecutionUnits[メモリ]は 120,000,000ユニットを超えてはならない

MBEU-M-02 (y) maxBlockExecutionUnits[memory] は負であってはならない

MBEU-M-03 (x - “すべき”) maxBlockExecutionUnits[メモリ]は、 どのエポックでも10,000,000単位以上変更(増加または減少)してはならない

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

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

CPU ユニット制限 (maxBlockExecutionUnits[steps]、maxTxExecutionUnits[steps])

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

ガードレール

MTEU-S-01 (y) maxTxExecutionUnits[ステップ]は 15,000,000,000 (15Bn)単位を超えてはならない

MTEU-S-02 (y) maxTxExecutionUnits[steps] は負であってはならない

MTEU-S-03 (~ - 既存のパラメータ値にアクセスできない) maxTxExecutionUnits[steps] を減らしてはならない

MTEU-S-04 (x - 「すべき」) 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 - 「すべき」) maxBlockExecutionUnits[steps] は、 どのエポック (5 日間) でも 2,000,000,000 (2Bn) 単位を超えて変更 (増加または減少) してはならない

MBEU-S-04 (x - 定量化不可) maxBlockExecutionUnits[steps] の変更の影響は、 詳細なベンチマーク/シミュレーションによって確認する必要があり 、ブロック拡散/伝播時間予算の要件を超えてはなりません。これは、 maxBlockExecutionUnits[memory] ​​によっても影響を受けます。増加は、 5 秒以内に 95% のブロック伝播が行われる 3 秒の合計ブロック拡散目標に対して測定された合計ブロック サイズ ( maxBlockBodySize ) の以前に特定された将来の要件も考慮する必要があります。将来の 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 - “すべき”) maxBlockHeaderSizeは 通常、プロトコルが変更された場合にのみ増加させるべきである。

MBHS-05 (x - 「すべき」) maxBlockHeaderSize は TCP の初期輻輳ウィンドウ (3 または 10 MTU) 内に収まる必要があります。

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

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

  1. 分散化、シビル攻撃および51%攻撃からの保護、サービス拒否攻撃からの保護の観点から、カルダノネットワークのセキュリティを確保します。
  2. Plutus言語の変更を有効にする
変化のきっかけ
  • アクティブなSPO数の変化
  • Plutus言語の変更
  • セキュリティ上の脅威
  • コミュニティのリクエスト
カウンターインジケーター
  • 経済的な懸念、例えばステークプールの数を変更する場合
コアメトリクス
  • ステークプールの数
  • 分散化のレベル

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

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

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

  • ネットワークが均衡状態にあるときのプールの期待数
  • 主にセキュリティパラメータであり、プールの分割/複製による分散化を保証する
  • 安全保障への影響だけでなく経済への影響もあるため、このパラメータを変更する際には経済的なアドバイスも必要となる。
  • このパラメータに大きな変化があると、大量の再委任イベントが発生します。
ガードレール

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

SPTN-02 (y) stakePoolTargetNumは 2,000を超えてはならない

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

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

誓約影響係数 (poolPledgeInfluence)

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

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

  • より高い値は、より多くの誓約をしたプールに報酬を与え、より少ない誓約をしたプールにペナルティを与える。

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

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

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

PPI-02 (y) poolPledgeInfluence は 1.0 を超えてはならない

PPI-03 (y) poolPledgeInfluence は 負であってはならない

PPI-04 (x - 「すべき」) poolPledgeInfluence は 、18 エポック期間 (約 3 か月) で +/- 10% 以上変動してはならない

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

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

ガードレール

PRME-01 (y) poolRetireMaxEpoch は 負であってはならない

PRME-02 (x - “すべき”) poolRetireMaxEpoch は 1 未満であってはなりません

担保率 (collat​​eralPercentage)

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

  • 手数料の支払いに加えて担保も必要となる
  • スクリプトの実行に失敗した場合、担保は失われます
  • スクリプトが正常に実行された場合、担保が失われることはありません

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

ガードレール

CP-01 (y)担保率は 100未満であってはならない

CP-02 (y)担保率は 200を超えてはならない

CP-03 (y)担保率は 負であってはならない

CP-04 (y)担保率は ゼロであってはならない

担保入力の最大数 (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 - 「適切な出力」は解釈の対象となります) maxValueSize は 、 適切な出力 (既存のオンチェーン出力や新しい元帳ルールによって生成される可能性のある予測出力など) を許可するのに十分な大きさである必要があります。

Plutus コスト モデル (costModels)

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

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

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

ガードレール

PCM-01 (x - 定量化不可能)コストモデルの 値は、リファレンスアーキテクチャのベンチマークによって設定する必要があります。

PCM-02 (x - トランザクションでプリミティブと言語バージョンが導入されていない)新しいプリミティブが導入された場合、または新しい Plutus 言語バージョンが追加された場合は、コスト モデルを更新する 必要があります。

PCM-03 (~ - Plutus コスト モデル パラメータにアクセスできません) コスト モデルの 値は負であってはなりません

PCM-04 (~ - Plutus コスト モデル パラメータにアクセスできない)プロトコルがサポートする各 Plutus 言語バージョンごとにコスト モデルを提供する 必要があります。

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 - 「すべき」) 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 - 「すべき」) 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 - 「すべき」) dRepActivity は 人間の期間 (2 か月など) で計算する必要があります。

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

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

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

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

dRepVotingThresholds :代表投票しきい値:

  • dvt委員会不信任
  • dvt委員会通常
  • dvtハードフォーク開始
  • dvtモーション不信
  • dvtPPE経済グループ
  • dvtPPGovグループ
  • dvtPPネットワークグループ
  • dvtPPテクニカルグループ
  • dvt財務省の撤退
  • dvt憲法更新

プール投票しきい値 :

  • 個人委員会不信任
  • pvt委員会通常
  • pvtハードフォーク開始
  • pvtMotionNoConfidence
  • pvtPPセキュリティグループ
ガードレール

VT-GEN-01 (y) すべてのしきい値は50%～100%の範囲になければなりません

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

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

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

VT-CON-01 (y)憲法または提案政策の更新の アクションのしきい値は 65%～90%の範囲でなければなりません。

VT-CC-01 (y)憲法委員会の行動 基準は 65%～90%の範囲でなければならない

VT-NC-01 (y)信頼できない アクションの閾値は51%～75%の範囲でなければならない

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

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

  • 時代全体を通して
ガードレール

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

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

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

GAL-04 (x - 「すべき」) govActionLifetime は 、投票などを行うのに十分な時間を確保するために、人間の時間 (例: 30 日、2 週間) に合わせて調整する必要があります。

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

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

委員の任期の上限

ガードレール

CMTL-01 (y)委員会最大期間制限 はゼロであってはならない

CMTL-02 (y)委員会最大期間制限 は負であってはならない

CMTL-03 (y)委員会のMaxTermLimitは 18エポック（90日、約3か月）未満であってはなりません。

CMTL-04 (y)委員会最大期間制限は 293 エポック (約 4 年) を超えてはなりません

CMTL-05 (x - 「すべき」)委員会の MaxTermLimit は 220 エポック (約 3 年) を超えてはならない

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

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

ガードレール

CMS-01 (y)委員会最小サイズ は負であってはならない

CMS-02 (y)委員会最小サイズ は3未満であってはならない

CMS-03 (y)委員会最小サイズ は10を超えてはならない

2.6 パラメータ変更の監視と元に戻す

すべてのネットワークパラメータの変更は、少なくとも2エポック（10日間）は注意深く監視する必要があります。

  • 6時間のローリングウィンドウ内でブロックの5%以上でブロックの伝播遅延が4.5秒を超える場合は、変更をできるだけ早く元に戻す必要があります。

その他のパラメータの変更はすべて監視する必要がある

  • パフォーマンス、セキュリティ、または機能に対する全体的な影響が許容できない場合は、復元計画を実装する必要があります。

パラメータの変更ごとに、特定の復元/回復計画を作成する必要があります。この計画には次の内容を含める必要があります。

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

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

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

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

3 国庫引出金措置に関するガードレールとガイドライン

財務引き出し アクションは、Cardano 財務からの引き出しの宛先と金額を指定します。

ガードレール

TREASURY-01 (x) DRepsは、一定期間ごとのCardano Treasury残高の純変更制限を定義する必要があります。

TREASURY-02 (x) カルダノ財務の予算は、一定期間あたりのカルダノ財務の残高の純変動限度を超えてはなりません。

TREASURY-03 (x) カルダノ財務省の予算はADA建てでなければなりません 。

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

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

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

  • 正の整数として

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

ガードレール

HARDFORK-01 (~ - 既存のパラメータ値にアクセスできません) メジャー プロトコル バージョンは、この変更の直前に適用されるメジャー バージョンと同じか、それより 1 つ大きい必要があります 。メジャー プロトコル バージョンが 1 つ大きい場合、マイナー プロトコル バージョンは0 である必要があります。

HARDFORK-02 (~ - 既存のパラメータ値にアクセスできません) マイナー プロトコル バージョンは、この変更の直前に施行されるマイナー バージョン以上である必要があります。

HARDFORK-03 (~ - 既存のパラメータ値にアクセスできません) 少なくとも 1 つのプロトコル バージョン (メジャー バージョン、マイナー バージョン、またはその両方)を変更する必要があります 。

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

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

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

HARDFORK-07 (x) 非推奨のプロトコルパラメータは、この付録に記載する必要があります。

HARDFORK-08 (~ - Plutus コスト モデル パラメータにアクセスできません) 新しい Plutus バージョンは、新しい Plutus バージョンで使用可能な各プリミティブをカバーするバージョン固有のPlutus コスト モデルによってサポートされる必要があります。

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

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

ガードレール

UPDATE-CC-01 (x) 憲法委員会の更新および/または閾値 および/または期間 ガバナンスアクションは、ADA保有者がオンチェーンガバナンスアクションを通じて最終憲法を批准するまで批准してはなりません。

6 憲法または提案政策アクションの更新に関するガードレールとガイドライン

構成または提案ポリシーアクションを更新すると、オンチェーン構成のハッシュと関連するガバナンス提案ポリシースクリプトが変更されます。

ガードレール

UPDATE-CONSTITUTION-01 (x)ハードフォークガバナンスアクションを通じて導入される新しいパラメータに必要なガードレールを定義するために、憲法 および/または提案ポリシー ガバナンスアクションの更新を提出する必要があります。

不信任決議に関する7つのガイドラインと指針

不信任 措置は、統治システムに対する不信任の状態を示します。不信任 措置にはガードレールは課されません。

ガードレール
  • なし

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

情報アクションはチェーン上で実行されません。 情報 アクションにはガードレールは課されません。

ガードレール
  • なし

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

中間期間

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

暫定期間の技術展開:

  • Chang ハードフォークにより、3 つの初期 CIP-1694 ガバナンス アクションが有効になり、代表フレームワークを確立できるようになります。これらのアクションは、「情報」 、「ハードフォークの開始」 、および 「プロトコル パラメータの変更」 アクションです。ADA 保有者は、ハードフォーク後すぐに DRep として登録し、委任することができますが、CIP-1694 で説明されているように、「情報」 アクション以外では DRep 投票は利用できません。これにより、ADA 保有者は投票委任を選択するのに十分な時間を確保できます。SPO は、CIP-1694 で説明されているように投票することができます。 「ハードフォークの開始」 および**「プロトコル パラメータの変更」** アクションも、憲法委員会によって承認されます。ADA 保有者は、通常どおりステーキング報酬を引き出すことができます。
  • チャン ハードフォークの直後に憲法委員会と SPO によって承認されるその後のハードフォークでは、残りの 4 つの CIP-1694 ガバナンス アクション、「財務引き出し」 、 「不信任決議」 、 「憲法委員会および/またはしきい値および/または条件の更新」 、 「憲法または提案ポリシーの更新」が 有効になります。この時点で、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保有者は、その他 の提案された 「憲法の更新」 、「憲法委員会 および/または基準および/または条件の更新」 、および 「不信任決議」ガバナンスアクションを批准する前に、付録IIに指定されている****最終憲法を 批准している必要があります。

INTERIM-05 (x) 暫定憲法自体が変更されない限り、暫定憲法と一致する**「提案ポリシーの更新」アクションは暫定期間中に承認される可能性があります。**

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

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

ネットワーク グループは次の要素で構成されます。

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

経済グループは以下のもので構成されています。

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

技術グループは以下のメンバーで構成されています。

  • プール誓約の影響力 ( poolPledgeInfluence )
  • プールの引退最大エポック ( poolRetireMaxEpoch )
  • 希望するプールの数 ( stakePoolTargetNum )
  • Plutus 実行コスト モデル ( costModels )
  • スクリプトに必要な担保の割合 ( collat​​eralPercentage )

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

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

付録 II: 最終憲法の批准

セクション1

最終的な憲法の条項について議論し討論する Ada 保有者向けの一連の世界規模のワークショップが、2024 年後半に開始されます。ワークショップは、Cardano コミュニティの幅広い感情を捉えるために、地理的に分散されます。ワークショップでは、最大 50 人の投票権を持つ代表者と最大 50 人の投票権を持たない代理代表者で構成される、合計 100 人の代表者が選出され、憲法制定会議に参加します。憲法制定会議に参加する各投票権を持つ代表者は、同等の投票権を持ちます。

第2節

憲法制定会議は遅くとも2024年末までに開催される予定。

セクション3

最終憲法は憲法会議で承認され、憲法会議に出席するよう選出された代表者は、適切かつ必要と思われる修正を加えた最終憲法に同意するものとします。憲法会議で承認された最終憲法は、2025 年 1 月 31 日までに CIP-1694 に従って統治措置として提出されるものとします。