Cardano Blockchain Ecosystem Constitution - Japanese Version - 20241205 - CARDANO ブロックチェーン エコシステム憲法-日本語版-2024年12月5日時点

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

皆様
いつも大変お世話になっております。
2024年12月5日時点でアルゼンチンとナイロビでの憲法会議で合意されたCARDANO ブロックチェーン エコシステム憲法 を日本語に翻訳しました。
Cardanoのオンチェインガバナンスについて深く学びたい方々は以下のリンクにてご参考ください。
※日本語翻訳の品質を改善していきたいので、修正すべきなところがありましたら教えていただけばありがたいです。 :bowing_woman: :bowing_woman:

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

前文

Cardano は、ブロックチェーン テクノロジー、スマート コントラクト、コミュニティ ガバナンスの分散型エコシステムであり、あらゆる場所のすべての人のために経済、政治、社会システムを改善することに取り組んでいます。この基礎的なインフラストラクチャを提供することで、Cardano は個人とコミュニティがアイデンティティ、価値、ガバナンスを管理できるようにし、分散型アプリケーション、ビジネス、ネットワーク状態の出現を促進します。

不変のデータを公平に処理することを通じて、私たちCardanoコミュニティの参加者は、個人、組織、貢献者、その他の構成員として、デジタル技術を通じてコミュニティの絆を初めて築いた初期のインターネットおよび暗号通貨の先駆者たちの足跡に従うことを選びます。私たちは、共通の原理と原則に導かれながら、分散型の意思決定と説明責任を両立させ、Cardanoブロックチェーンのセキュリティを守ることでセルフガバナンスを実現します。

従来の国家ガバナンスシステムに依存せず、より強固で柔軟なガバナンスフレームワークの必要性を認識し、Cardanoコミュニティによるセルフガバナンスに依拠することを選択します。そして可能かつ有益な場合には、ガバナンスプロセスにおいてブロックチェーン技術を活用します。この目的のもと、私たちはCardanoブロックチェーンエコシステムを統治し、Cardanoブロックチェーンの継続性を確保し、それを利用する者の権利を守るために、このCardano憲法をここに制定します。

これらの目的を念頭に置き、私たちCardano コミュニティは、Cardano ブロックチェーン エコシステムのガバナンスに参加するために、この憲法を遵守する意思を表明します。私たちは、私たちの価値観を共有するすべての人に加わっていただくよう呼びかけますが、別の道を歩むことを望む人の邪魔をすることはありません。

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

第１項

以下の原則は、憲法委員会を含むCardanoコミュニティのすべての参加者を導くものであり、提案されたガバナンスアクションはこれらの原則に従って評価されます。以下の原則の順序は、原則間の優先順位を表すものではありません。

原則１ Cardano ブロックチェーン上のトランザクションは、遅延または検閲されることはなく、意図された目的に沿って適切に処理されるものとします。

原則２ Cardanoブロックチェーン上の取引コストは予測可能であり、不合理なものであってはなりません。

原則３ Cardano ブロックチェーン上でアプリケーションを開発および展開することを望む者は、そのようなアプリケーションを意図どおりに開発および展開することを不当に妨げられないものとします。

原則４ Cardanoブロックチェーン上のCardanoコミュニティによる貢献は、SPOとの報酬共有、DRepおよびCCメンバーへの潜在的な報酬、および適切なトークノミクスを通じて公正に認識され、記録され、評価されるものとします。

原則５ Cardanoブロックチェーンは、所有者の同意なしに、ADA所有者の値やデータをロックインすることはありません。

原則６ Cardano ブロックチェーンは相互運用性を不当に妨げてはなりません。

原則７ Cardano ブロックチェーンは、Cardano ブロックチェーンに保存されているあらゆる値と情報を安全な方法で保存するものとします。

原則８ Cardano ブロックチェーンは不当にリソースを消費してはなりません。

原則９ Cardano ブロックチェーンのすべてのユーザーは、Cardano ブロックチェーンの長期的な持続可能性と実行可能性に沿って、Cardano ブロックチェーン コミュニティの集合的な要望を考慮して、公平かつ公正に扱われるものとします。

原則１０財政の安定性を維持し、ADAの総供給量は45,000,000,000（45,000,000,000,000,000 lovelace）を超えないものとします。

第２項

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

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

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

第１項

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

第２項

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

第３項

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

第４項

Cardanoコミュニティは、本憲法の規定を通じて、Cardanoブロックチェーンのアプリケーションの開発、維持、構築において協力する権利を有し、また推奨されます。さらに、Cardanoブロックチェーンエコシステムを支援するために、Cardanoコミュニティが望ましいまたは適切と判断する一時的または恒久的な組織、協会、その他の団体を結成する権利も有します。

第３条 参加型および分散型ガバナンス

第１項

Cardano ブロックチェーンは、分散型のオンチェーン ガバナンス モデルによって管理され、可能な限り有益な範囲で、スマート コントラクトおよびその他のブロックチェーン ベースのツールを利用して意思決定を促進し、透明性を確保します。ガバナンスアクションに対するオンチェーン投票は、Cardano ブロックチェーン ガードレール付録を含む、本憲法に概説されているプロセスに従うものとします。オンチェーンガバナンスアクションは、Cardano ブロックチェーンガードレールで要求されているように、特定のコンセンサスしきい値要件を伴う集団意思決定プロセスを通じて実行されるものとします。

第２項

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

第３項

すべての ADA 所有者は、本憲法および Cardano ブロックチェーンガードレール 付録に規定されているように、オンチェーン ガバナンスの意思決定プロセスで投票する権利を有します。すべての ADA 所有者は、ガードレールに従って、Cardano ブロックチェーン エコシステムのガバナンス構造の変更を提案する権利を有します。ADA の所有者が第三者の管理者またはその他の指定者を利用して ADA を保管している場合、そのような第三者が自分に代わって投票することを承認したり、承認を保留したりすることができます。

第４項

オンチェーンのガバナンスアクションには特別な形式である「情報」アクションが存在します。この「情報」アクションは、Cardanoコミュニティが将来的なオンチェーンガバナンスアクションの提案を行うことや、Cardanoブロックチェーンに対してオンチェーン上の変更を行うことなく、コミュニティの気持ちを測ることを可能にします。このような「情報」アクションは、Cardanoブロックチェーンに記録されること以外にはオンチェーン上の効果を持ちません。「情報」アクションは、第７条第４項に基づき、Cardanoブロックチェーンエコシステムの予算案およびCardanoブロックチェーントレジャリーの引き出し提案に関連しても使用されるものとします。

第５項

オンチェーン ガバナンスのプロセスの透明性を高めるために、オンチェーンで記録または施行される前に、提案されたすべてのガバナンス アクションは、Cardano ブロックチェーンへのすべての文書化されたオフチェーン コンテンツの URL とハッシュを含む、標準化された判読可能な形式に従うことが求められます。Cardanoブロックチェーンへの変更を要求するには正当な根拠が十分に示されるべきです。根拠には、少なくとも、タイトル、概要、提案の理由、および関連する裏付け資料を含めるものとします。

すべてのオンチェーン ガバナンス アクションの内容は、提案されたアクションの最終的なオフチェーン バージョンと同一である必要があります。

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

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

第６項

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

第４条 CARDANO ブロックチェーン エコシステムの予算

第１項

Cardanoコミュニティのいかなる参加者も、いつでもCardanoブロックチェーンエコシステムの予算を提案することができます。Cardanoコミュニティは、この憲法で規定されている分散型オンチェーンガバナンスプロセスの実施、運営、および維持に関連するその他の費用を賄うため、Cardanoブロックチェーンエコシステムの運用、維持、将来の開発に向けた1つ以上の予算を定期的に提案することが求められます。Cardanoコミュニティは、Cardanoブロックチェーンエコシステムのために1つの総合的な予算または複数の予算を提案することができます。これらの予算は、少なくとも73エポック（約１暦年）をカバーすることが期待されますが、Cardanoコミュニティがより短期間または長期間の予算を提案することを妨げるものではありません。すべてのADA保有者は、オンチェーンの「情報」アクションを通じて、定期的に1つ以上のCardanoブロックチェーンエコシステム予算を承認することが求められます。第４条第３項に規定されているように、必要に応じて、Cardanoブロックチェーントレジャリーから資金を引き出すことで、現在有効なCardanoブロックチェーンエコシステム予算を実行することができます。既存の予算は、本第１項で規定されているのと同じプロセスに従って修正される場合があります。

第２項

Cardanoブロックチェーンエコシステムの予算策定およびその管理には、可能な限りかつ有益な範囲で、スマートコントラクトやその他のブロックチェーンベースのツールを活用し、意思決定を促進し透明性を確保します。Cardanoブロックチェーンの予算には、Cardanoブロックチェーントレジャリーから引き出された資金の使用を監督するためのプロセスが明記され、その監督を担う1人以上の管理者を指定することが含まれるものとします。

第３項

Cardanoブロックチェーントレジャリーからの引き出しが、その時点で適用される純変更制限を超えることとなる場合、引き出しは許可されません。Cardanoブロックチェーントレジャリーからの引き出しは、Cardanoブロックチェーンガードレール付録で要求されているように、その時点で有効なCardanoブロックチェーンの予算に基づき承認されている場合を除き、許可されません。また、その予算が憲法委員会によって違憲であると判断されていないことが条件となります。

第４項

Cardanoブロックチェーントレジャリーからadaを要求するあらゆるガバナンスアクションは、その資金要求の一部として、定期的な独立監査の費用およびそのadaの使用に関する監視指標の実施費用をカバーするためのADAの割り当てを必要とします。Cardanoブロックチェーンエコシステム予算に基づきCardanoブロックチェーントレジャリーから受け取ったADAの使用を管理する契約上の義務には、紛争解決条項が含まれるものとします。

第５項

Cardanoブロックチェーントレジャリーから引き出されたADAについては、そのADAがさらなる分配の前に管理者によって直接または間接的に保持されている間、Cardanoコミュニティによって監査可能な1つ以上の分離されたアカウントに保管されなければなりません。これらのアカウントはSPOに委任してはならず、事前に定義された自動棄権投票オプションに委任されなければなりません。

第５条 委任代表者

第１項

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

第２項

ADAの所有者は誰でも、DRep として登録するオプションを有するものとします。 ADAの所有者は、自身を含む 1 人以上の登録 DRep に投票権を委任することができるものとします。DRepは個人であっても、協調的なグループであっても構いません。第三者の保管者や他の代理人にADAを保有させているADA所有者は、その第三者が登録済みのDRepに投票権を委任することを承認するか、または承認を拒否することができます。DRepはオンチェーンのガバナンスアクションに対して直接投票する権利を有し、投票権を委任したADA所有者を代表します。DRepの投票しきい値はCardanoブロックチェーンガードレール付録に規定されています。

この投票システムは、ADAの所有者がDRepを自由に選択し、DRepとして登録し、いつでも委任を取り消しまたは変更できる液体民主主義モデルを確立するものです。

第３項

委任者の代表である DRep は、DRep としての活動を規定する行動規範を定期的に採用し、適切と思われる場合は更新し、その行動規範を一般に公開することが求められます。DRep は、行動規範に倫理ガイドラインを含めることが推奨されます。

第４項

Cardano コミュニティは、ADA の所有者が DRep 候補者を調査および評価し、DRep の行動規範にアクセスして評価し、関連性があると思われる基準に基づいて DRep を選択できるようにするツールの作成、保守、継続的な管理をサポートすることが期待されています。

第５項

委任者の代表である DRep は、その活動に対して報酬を受け取る場合があります。DRep は、DRep としての活動に関連して受け取った報酬をすべて開示する必要があります。

第６項

DReps は、ADA 所有者またはその被指名人によって DRep に任命されること、または、ADA 所有者またはその被指名人に代わって投票することと引き換えに、ADA 所有者またはその被指名人に報酬を支払ってはなりません。

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

第１項

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

第２項

SPO は、例外的な状況下では、Cardano ブロックチェーン ガードレール付録の第2.1項の「ブロックチェーンの運用に重要なパラメータ」で規定されているセキュリティ上重要なパラメータに影響を与える「不信任案」および「委員会/しきい値および/または任期の更新」ガバナンス アクション、および「パラメータ更新」ガバナンス アクションに個別に投票することにより、憲法委員会の権限をチェックする役割を果たします。

第３項

SPO は、SPO としての活動を管理する行動規範を定期的に採用し、適切と判断した場合に更新し、そのような行動規範を公開することが奨励されます。 SPO は、行動規範に倫理ガイドラインを含めることが奨励されます。

第４項

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

第７条 憲法委員会

第１項

憲法委員会は、Cardanoのオンチェーンガバナンスプロセスの一部として設立され、オンチェーンで実行されるガバナンスアクションがこの憲法に適合していることを保証する役割を担います。憲法委員会は、ADAの所有者から構成され、オンチェーンでの実行前にガバナンスアクションが憲法に適合しているかどうかを集団的に責任を持って確認するものとします。本第７条第４項で別段の規定がある場合を除き、憲法委員会は、オンチェーンで実行されるガバナンスアクションの憲法適合性に関する投票に限定されるものとします。憲法委員会のメンバーは、Cardanoブロックチェーンエコシステムへの過去の貢献や関与を考慮し、求められる責任を果たすための適切な専門知識を有することが期待されます。

第２項

憲法委員会は、ADA 所有者によって随時決定される、Cardano ブロックチェーンの継続的な整合性を保証するのに十分な数のメンバーで構成されるものとします。憲法委員会のメンバー数の最小および最大人数は、Cardanoブロックチェーンガードレール付録に規定された最小および最大人数に一致するものとします。

憲法委員会のメンバーの任期の長さは、Cardanoブロックチェーンガードレール付録に規定された最小および最大任期の範囲内で、ADA所有者によって随時決定されます。憲法委員会の運営の継続性を確保するため、憲法委員会メンバーの任期は交代制とするものとします。

第３項

Cardanoコミュニティは、ガードレールの要件に沿った憲法委員会のメンバーの選出プロセスを確立し、随時公開するものとします。

第４項

「不信任案」または「憲法委員会/しきい値および/または任期の更新」を除き、ガバナンスアクションがオンチェーンで実行されるには、まずガードレールで指定された憲法委員会の必要な割合のメンバーが、その提案がこの憲法に違反していないと判断し、オンチェーンアクションを通じて確認する必要があります。憲法委員会の各メンバーには1票の投票権があります。「情報」アクションはオンチェーンでの効果を持たず、したがって憲法上の合憲性や違憲性に関わらないため、憲法委員会のメンバーは「情報」アクションがオンチェーンで記録されることを妨げることはできません。ただし、憲法委員会のメンバーは、当該「情報」アクションに関する自身の意見を表明するためにオンチェーンで投票を記録することができます。これには、提案された行動方針がオンチェーンのメカニズムによって実施された場合に憲法に違反すると考えられるかどうかを示す意見を含めることができます。Cardanoブロックチェーンエコシステムの予算を提案する「情報」アクションの場合、憲法委員会のメンバーは、提案された予算が「情報」アクションに含まれる形式で実施された場合、この憲法に違反すると考えられるかどうかについての意見をオンチェーンで記録する必要があります。

以前に承認された予算に基づいてCardanoブロックチェーントレジャリーからの引き出しを提案する「情報」アクションの場合、憲法委員会のメンバーは、提案された引き出しが当該「情報」アクションに従って行われた場合、この憲法に違反すると考えられるかどうかについての意見をオンチェーンで記録する必要があります。

第５項

憲法委員会は常に次の 2 つの状態、信任状態または不信任状態のいずれかにあるものとします。不信任状態の場合、現職の憲法委員会メンバーは「委員会/しきい値の更新」ガバナンスアクションを使用して再任または交代される必要があり、それ以外のガバナンスアクション（「情報」アクションを除く）は進行することができません。不信任状態の間は、予算案やトレジャリー引き出し提案に関連する「情報」アクション以外の「情報」アクションはオンチェーンで記録を続けることができます。

憲法委員会のメンバーが、この憲法で要求される責任を果たしていないと判断された場合（SPOおよびDRepがガードレールで規定された必要な割合でそれぞれ投票し、「憲法委員会/しきい値および/または任期の更新」ガバナンスアクションによって決定される）、そのメンバーはガバナンスアクションの実施時に憲法委員会から解任されます。その後、解任されたメンバーの後任を選ぶために、可能な限り早急に選挙が実施されるものとします。

憲法委員会の全メンバーを同時に解任する「不信任案」ガバナンスアクションが、DRepおよびSPOによるガードレールで規定された必要な割合の承認を得た場合、ガバナンスアクションの実施後、全体または一部の現職の憲法委員会メンバーを再任するか、新しい憲法委員会メンバーを選出する選挙が行われるまで、憲法委員会は不信任状態と見なされます。

第６項

憲法委員会のプロセスは透明性を持つものとします。憲法委員会は、各決定を公開しなければなりません。オンチェーンで実行される提案されたガバナンスアクションが違憲であると投票する場合、憲法委員会全体、またはそのような投票を行った各憲法委員会メンバーは、その決定の根拠をこの憲法の特定の記事や、提案と矛盾するCardanoブロックチェーンガードレール付録の規定を参照して示すものとします。ただし、投票前の憲法委員会メンバー間の内部審議を公開することは要求されません。

憲法委員会は、憲法委員会が定期的に採択し公開する行動規範に基づいて運営されるものとします。憲法委員会は、その行動規範に倫理ガイドラインを含めることが推奨されます。また、憲法委員会は、その義務を遂行する上で必要と判断されるポリシーや手続きを定期的に採択し公開するものとします。

第７項

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

第８項

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

第９項

DRep、SPO、またはその両方としても活動している憲法委員会のメンバーは、オンチェーンガバナンスアクションに関する投票に先立って、複数の立場でオンチェーンガバナンスアクションに参加していることを公に開示するものとします。

第８条 改正プロセス

第１項

この憲法は、生きた文書として扱われるべきものです。技術的進歩、Cardanoコミュニティの願望、ニーズ、期待の変化、そして予期せぬ状況の発生により、将来的にこの憲法を改正する必要が生じる可能性があります。Cardanoコミュニティは、この憲法の条項を定期的に見直し、議論し、必要とされる場合には、Cardanoコミュニティが適切と判断するフォーラムで集まり、この憲法の改正を提案することが推奨されます。改正は、本第８条で規定された方法に従って行うことができます。

第２項

Cardano ブロックチェーン ガードレール 付録に別途規定されている場合を除き、Cardano ブロックチェーン ガードレール 付録を含む本憲法の改正は、集団的意思決定プロセスによって承認されなければなりません。このプロセスでは、ADA所有者によるオンチェーンのガバナンスアクションが必要であり、その時点で有効な投票権の少なくとも65%のしきい値を満たすことが求められます。

第３項

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

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

１．はじめに

Cardanoブロックチェーンのオンチェーンガバナンスを実現するためには、Cardanoブロックチェーンが安全かつ持続可能な方法で運用を続けられるようにするための適切なガードレールを確立する必要があります。

この付録では、プロトコルパラメータの変更やトレジャリー引き出しの制限を含む、Cardanoブロックチェーンのオンチェーンガバナンスアクションに適用されるべきガードレールを定めています。これらのガードレールは、設定に関する重要かつ本質的な制限や、経験、測定、ガバナンス目標に基づいた推奨事項を網羅しています。

これらのガードレールは、Cardanoブロックチェーンの運用における予期せぬ問題を回避するために設計されています。また、適切なパラメータ設定の選択を導き、安全性、性能、機能性、長期的な持続可能性に関する潜在的な問題を防ぐことを目的としています。以下に説明するように、これらのガードレールの一部は自動化が可能であり、オンチェーン ガードレール スクリプトまたは組み込みのledgerルールを介して適用されます。

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

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

この付録のガードレールは現時点での技術的洞察の最新の状態を反映していますが、この付録は「生きた文書」として扱うべきものです。Cardanoブロックチェーンの実装改善、新しいシミュレーション、またはパフォーマンス評価の結果により、ガードレールに含まれる制限の一部はやがて緩和できる場合があります（または、状況によっては強化が必要になる場合もあります）。

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

ガードレールの改正、追加、または廃止

この付録に記載されているガードレールは、付録に規定された適用可能な投票しきい値を満たすオンチェーンガバナンスアクションに従って、随時改正されることがあります。いかなるガードレールの改正も、新しいガードレールを含めて、この憲法自体の改正とみなされ、改正が必要とされます。各ガードレールには固有のラベルが付与されています。ガードレールの文言が改正される場合、既存のガードレールは廃止され、新しいラベルがこの付録に使用されます。同様に、ガードレールが完全に廃止される場合、そのラベルは将来再利用されることはありません。いずれの場合でも、ガバナンスアクションに適用されるガードレールは、ガバナンスアクションがオンチェーンに提出された時点で有効なものとします。その後の改正に関係なく、提出時点のガードレールが適用されます。

用語とガイダンス

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

記号と説明

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

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

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

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

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

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

曖昧さを避けるために、この付録では、他の規則ではなく、プロトコル パラメータ更新ガバナンス アクションで使用されるパラメータ名を使用していることに注意してください。

ガードレール

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

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

２．1. 重要なプロトコルパラメータ

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

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

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

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

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

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

  • 委任キー lovelaceデポジット (stakeAddressDeposit)
  • プール登録 lovelaceデポジット (stakePoolDeposit)
  • プールの最低固定報酬カット (minPoolCost)
  • DRep デポジット額 (dRepDeposit)
  • 憲法委員会の最小規模 (committeeMinSize)
  • 憲法委員会のメンバーの最長任期（エポック単位） (committeeMaxTermLength)
ガードレール

PARAM-05a (y) DRep は、全有効投票権の 50% 以上の集団的支持を得て「Yes」に投票をしなければなりません。これは、DRep 投票しきい値のガードレールによって強制されます。

PARAM-06a (x) ガバナンス システムにとって重要なパラメーターを変更するオフチェーン提案が公表されてから、対応するオンチェーンガバナンスアクションが提出されるまで、通常少なくとも3カ月は経過すべきです。このガードレールは、重大度1または重大度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）未満であってはなりません。これにより、低コストのサービス拒否攻撃から保護されます。

TFPB-02(y) xFeePerByteは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（10ADA）を超えてはなりません。これにより、トランザクションの支払いが確実に行われます。

TFF-03(y) txFeeFixedは マイナスであってはなりません。

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

TFGEN-02 (x - unquantifiable) txFeeFixed または txFeeFixed を変更する場合は、サービス拒否攻撃のコスト削減の影響や、トランザクションの構築が不可能になるような最大トランザクション手数料の増加を考慮しなければなりません。

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

UTxO に保持されるストレージのバイトごとに請求されるデポジット (lovelace単位) を定義します。このデポジットは、UTxO がアクティブでなくなったときに返されます。

  • 単一の UTxO 内に保持される ADA の最小しきい値を設定します
  • UTxO ストレージに対する低コストのサービス拒否攻撃に対する保護を提供します。 DoS 保護は、空きノード メモリに応じて減少します (UTxO の増加に比例します)。
  • 不要になった UTxO を返却したり、UTxO をマージしたりするインセンティブを提供することで、ノード ユーザーの長期ストレージ コストを削減するのに役立ちます。
ガードレール

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-05a (x - “should”) 変更は以下を考慮すべきです。

  1. 許容可能な攻撃コスト
  2. 攻撃の許容時間
  3. フルノードユーザーが許容できるメモリ構成
  4. UTxO のサイズ
  5. 現在のノードメモリ使用量の合計

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

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

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

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

ガードレール

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

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

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 (~ - no access to change history) treasuryCut は、36 エポック期間 (約 6 か月) 内に 2 回以上変更してはなりません。

通貨拡大率 (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 エポック期間 (約 6 か月) 内で 2 回以上変更すべきではありません。

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”) 実行価格は、以下のように設定されなければなりません。

  1. 最大 CPU ステップでトランザクションを実行するコストは、最大サイズの非スクリプト トランザクションのコストと同程度です。
  2. 最大メモリユニットでトランザクションを実行するコストは、最大サイズの非スクリプトトランザクションのコストと同程度です。

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”) サービス拒否攻撃に対する一貫したレベルの保護を維持するために、Plutus実行価格（executionUnitPrices[steps/memory]）およびtxFeeFixedが調整されるたびにminFeeRefScriptCoinsPerByteは調整されるべきです。

MFRS-04 (x - unquantifiable) minFeeRefScriptCoinsPerByte を変更する場合は、サービス拒否攻撃のコスト削減や最大トランザクション手数料の増加の影響を考慮しなければなりません。

２．3. ネットワークパラメータ

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

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

変化のきっかけ

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

  1. 2エポック期間（10日間）におけるトラフィック需要の測定された変化
  2. 予測されるトラフィック需要の変化
  3. Cardano コミュニティからのリクエスト

カウンタインジケーター

次の場合には、変更を元に戻す必要がある場合や、変更を実施すべきではない場合があります:

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

コア指標

パラメータ変更に関するすべての決定は、次の情報に基づいて行われるべきです:

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

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

ガードレール

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

NETWORK-02 (x - “should”) ネットワークパラメータは、トランザクション単位とブロック単位のメモリユニット制限など、直接相関がない限り、1エポックにつき1つだけ変更されるべきです。

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

ブロック サイズ (maxBlockBodySize)

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

ガードレール

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

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

MBBS-03a (x - “exceptional circumstances”) セキュリティ、パフォーマンス、機能性、長期的な持続可能性に潜在的な問題がある例外的な状況を除き、maxBlockBodySize を小さくしてはいけません。

MBBS-04 (~ - no access to existing parameter values) maxBlockBodySize は、少なくとも 1 つのトランザクションを含めるのに十分な大きさでなければなりません(つまり、maxBlockBodySize は少なくとも maxTxSize でなければなりません)。

MBBS-05 (x - “should”) maxBlockBodySizeは、エポック（5日間）ごとに最大10,240Byte（10KB）、できれば8,192Byte（8KB）以下で変更されるべきです。

MBBS-06 (x - “should”) ブロックサイズは、追加の伝送制御プロトコル (TCP) ラウンドトリップを引き起こすべきではありません。これを超える増加は、パフォーマンス分析、シミュレーション、ベンチマークによって裏付けられなければなりません。

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

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

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

ガードレール

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

MTS-02(y) maxTxSize は マイナスであってはなりません。

MTS-03 (~ - no access to existing parameter values) maxTxSize を小さくしてはいけません。

MTS-04 (~ - no access to existing parameter values) maxTxSize は maxBlockBodySize を超えてはなりません。

MTS-05 (x - “should”) maxTxSize は、どのエポックでも 2,560 バイト (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 (~ - no access to existing parameter values) 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-04a (x - unquantifiable) maxBlockExecutionUnits[memory] ​​への変更の影響は、詳細なベンチマーク/シミュレーションによって確認されなければならず、maxBlockExecutionUnits[steps] および maxBlockBodySize によっても影響を受けるブロック拡散/伝播時間予算の要件を超えてはなりません。いかなる増加も、事前に合意された将来の総ブロックサイズ要件（maxBlockBodySize）を考慮しなければならず、これは総ブロック拡散目標3秒、および95%のブロックが5秒以内に伝播することを基準とします。

MEU-M-01 (~ - no access to existing parameter values) 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 (~ - no access to existing parameter values) 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-04a (x - unquantifiable) maxBlockExecutionUnits[steps] の変更の影響は、詳細なベンチマーク/シミュレーションによって確認されなければならず、maxBlockExecutionUnits[memory] ​​と maxBlockBodySize によっても影響を受けるブロック拡散/伝播時間予算の要件を超えてはなりません。いかなる増加も、事前に特定された将来の総ブロックサイズ要件（maxBlockBodySize）を考慮しなければならず、これは総ブロック拡散目標3秒、および95%のブロックが5秒以内に伝播することを基準とします。将来的にPlutusのパフォーマンスが改善されると、ブロックごとのステップ制限が増加する可能性がありますが、前の文で指定された全体的な拡散制限と将来の要件とのバランスをとらなければなりません。

MEU-S-01 (~ - no access to existing parameter values) maxBlockExecutionUnits[steps]はmaxTxExecutionUnits[steps] 以下であってはなりません。

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

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

ガードレール

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

MBHS-02(y) maxBlockHeaderSize は マイナスであってはなりません。

MBHS-03 (x - “largest valid header” is subject to change) maxBlockHeaderSizeは、有効な最大ヘッダーに対応できる大きさでなければなりません。

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

MBHS-05 (x - “should”) maxBlockHeaderSize は TCP の初期輻輳ウィンドウ (3 または 10 MTU) 内に収まるべきです。

２．4. 技術/セキュリティパラメータ

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

  1. 分散化と敵対的な行為からの保護の観点から、Cardano ブロックチェーン ネットワークのセキュリティを確保します
  2. Plutus 言語への変更を有効にします

変化のきっかけ

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

カウンタインジケーター

  • 経済的な懸念、例:ステークプールの数を変更する場合

コア指標

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

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

ステークプールの目標数 (stakePoolTargetNum)

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

  • ネットワークが均衡状態にあるときのステークプールの予想数
  • 主にセキュリティパラメータであり、ステークプールの分割/レプリケーションによる分散化を保証します
  • セキュリティ効果だけでなく経済効果もあります。このパラメータを変更する場合は経済的なアドバイスも必要です
  • このパラメータに大きな変化があると、大量の再委任イベントが発生する可能性があります
ガードレール

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

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

SPTN-03 (y) stakePoolTargetNum は マイナスであってはなりません。

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

誓約影響係数 (poolPledgeInfluence)

誓約保護メカニズムを有効にします

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

  • 値が大きいほど、より多くの誓約を持つプールに報酬が与えられ、誓約が少ないプールにはペナルティが課されます。

技術的効果だけでなく経済的効果もあります。 - 経済的アドバイスも必要です。

ガードレール

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 未満であってはなりません。

担保割合 (colteriorPercentage)

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

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

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

ガードレール

CP-01 (y) collateralPercentage は 100 未満であってはなりません。

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

CP-03 (y) collateralPercentage は マイナスであってはなりません。

CP-04 (y) collateralPercentage は ゼロであってはなりません。

担保入力の最大数 (maxColternateInputs)

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

ガードレール

MCI-01 (y) maxCollateralInputs は 1 未満であってはなりません。

最大値サイズ (maxValueSize)

各アウトプットの値のシリアル化されたサイズの制限。

ガードレール

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

MVS-02(y) maxValueSize は マイナスであってはなりません。

MVS-03 (~ - no access to existing parameter values) maxValueSize は maxTxSize より小さくなければなりません。

MVS-04 (~ - no access to existing parameter values) maxValueSize を 減らしてはいけません。

MMVS-05 (x - “sensible output” is subject to interpretation) maxValueSize は 適切なアウトプット（既存のオンチェーンアウトプットや新しいledgerルールによって生成される可能性のある予測アウトプットなど）を可能にするのに十分な大きさでなければなりません。

Plutus コスト モデル (costModels)

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

Plutus のバージョンごとに異なるコスト モデルが必要です。各コスト モデルは、多くの異なるコスト モデル値で構成されます。コスト モデルは、Plutus の言語バージョンごとに定義されます。新しい言語バージョンでは、追加のコスト モデル値が導入されたり、既存のコスト モデル値が削除されたりすることがあります。

ガードレール

PCM-01 (x - unquantifiable) コストモデルの値は、リファレンスアーキテクチャをベンチマークして設定されなければなりません。

PCM-02 (x - primitives and language versions aren’t introduced in transactions) 新しいプリミティブが導入されたり、新しいPlutus言語バージョンが追加されたりした場合は、コストモデルは更新されなければなりません。

PCM-03a (~ - no access to Plutus cost model parameters) コストモデルの値は、通常、マイナスの値であるべきではありません。マイナスの値は、関連するプリミティブの基礎となるコストモデルに照らして正当化されなければなりません。

PCM-04 (~ - no access to Plutus cost model parameters) プロトコルがサポートするPlutus言語バージョンごとにコストモデルを提供しなければなりません。

２．5. ガバナンスパラメータ

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

  1. ガバナンスの安定性を確保する
  2. ガバナンスの代表的なフォームを維持する

変化のきっかけ

ガバナンスパラメータの変更は、次の要因によって引き起こされる可能性があります。

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

カウンタインジケーター

次の場合には、変更を元に戻す必要がある場合や、変更を実行すべきではない場合があります。

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

コア指標

パラメータ変更に関するすべての決定は、次の情報に基づいて行われるべきです:

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

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

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

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

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

GD-01 (y) govDeposit は マイナスであってはなりません。

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

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

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

DRep のデポジット (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がいかなる提案にも投票権を行使しない場合、そのDRepが非活動的とみなされる期間（整数エポック）。

ガードレール

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

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

DRA-03 (y) dRepActivity は マイナスであってはなりません。

DRA-04 (~ - no access to existing parameter values) dRepActivity は govActionLifetime より大きくなければなりません。

DRA-05 (x - “should”) dRepActivity は人間の基準（2 か月など）で計算すべきです。

DRep と SPO ガバナンス アクションのしきい値

(dRepVotingThresholds[…]、poolVotingThresholds[…])

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

  • アクションの正当性を保証します

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

dRep投票しきい値:

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

プール投票しきい値:

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

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

VT-GEN-02a (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) 憲法委員会の更新アクションのしきい値は 51% ～ 90% の範囲内でなければなりません。

VT-NC-01 (y) 不信任案アクションのしきい値は 51% ～ 75% の範囲内でなければなりません。

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

ガバナンスアクションが制定されなかった場合にそのアクションが期限切れになるまでの期間 (整数エポック)

ガードレール

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

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

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

GAL-04 (x - “should”) govActionLifetime は、投票などを行うのに十分な時間を確保するために、人間の基準（例：30 日、2 週間）で調整するべきです。

GAL-05 (~ - no access to existing parameter values) govActionLifetime は dRepActivity より小さくなければなりません。

憲法委員会の最長任期 (committeeMaxTermLength)

委員会のメンバーが務めることができる最長任期の制限

ガードレール

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

CMTL-02a (y) committeeMaxTermLength は マイナスであってはなりません。

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

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

CMTL-05a (x - “should”) committeeMaxTermLength は 220 エポック (約 3 年) を超えるべきではありません。

憲法委員会の最小サイズ (committeeMinSize)

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

ガードレール

CMS-01 (y) committeeMinSize は マイナスであってはなりません。

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

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

２．6. パラメータ変更の監視と復元

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

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

他のすべてのパラメータ変更も監視するべきです。

  • パフォーマンス、セキュリティ、機能性、または長期的な持続可能性に対する全体的な影響が許容できない場合は、復元計画を実施するべきです。

パラメータ変更ごとに、特定の復元/回復計画を作成しなければなりません。この計画には、次の内容を含めなければなりません:

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

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

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

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

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

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

ガードレール

TREASURY-01a (x) 一定期間ごとのCardanoトレジャリー残高の純変動限度は、アクティブな投票ステークの50%を超えるしきい値でオンチェーンガバナンスアクションを介してDRepsによって合意されなければなりません。

TREASURY-02a (x) 承認されたCardanoブロックチェーンエコシステム予算に従って行われたCardanoブロックチェーントレジャリーからの引き出しは、一定期間のCardanoトレジャリー残高の純変動限度を超えてはなりません。

TREASURY-03a (x) Cardano ブロックチェーントレジャリーからの引き出しは、ADA 建てでなければなりません。

TREASURY-04a (x) Cardano ブロックチェーントレジャリーからの引き出しは、Cardano コミュニティが Cardano ブロックチェーンのエコシステム予算を承認するまで、承認してはなりません。その場合、有効投票権の 50% を超えるしきい値で DRep によって合意された以前のオンチェーン ガバナンス アクションに従って有効になります。

４．ハードフォーク開始アクションのガードレールとガイドライン

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

  • それらは正の整数として指定されます

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

ガードレール

HARDFORK-01 (~ - no access to existing parameter values) プロトコルのメジャー バージョンは、この変更の直前に制定されるメジャー バージョンと同じか 1 大きくなければなりません。メジャー プロトコル バージョンが 1 大きい場合、マイナー プロトコル バージョンは 0 でなければなりません。

HARDFORK-02a (~ - no access to existing parameter values) メジャー プロトコル バージョンも変更されない限り、マイナー プロトコル バージョンは、この変更の直前に制定されるマイナー バージョンよりも大きくなければなりません。

HARDFORK-03 (~ - no access to existing parameter values) 少なくとも 1 つのプロトコル バージョン (メジャー、マイナー、またはその両方) を変更しなければなりません。

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

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

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

HARDFORK-07 (x) 廃止されたプロトコルパラメータは、この付録に明記されなければなりません。

HARDFORK-08 (~ - no access to Plutus cost model parameters) 新しい Plutus バージョンは、新しい Plutus バージョンで利用可能な各プリミティブをカバーするバージョン固有の Plutus コスト モデルによってサポートされなければなりません。

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

憲法委員会またはしきい値ガバナンスアクションを更新すると、憲法委員会の規模、構成、または必要な投票しきい値が変更される可能性があります。

ガードレール

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

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

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

ガードレール

NEW-CONSTITUTION-01a (x) ハードフォークガバナンスアクションによって導入される新しいパラメータに必要なガードレールを定義するには、新しい憲法またはガードレールスクリプトガバナンスアクションを送信しなければなりません。

NEW-CONSTITUTION-02 (x) 指定されている場合、新しいガードレールスクリプトはこの憲法と一致していなければなりません。

７．不信任案アクションに関するガードレールとガイドライン

不信任アクションは、ガバナンスシステムに対する不信任の状態を示します。不信任アクションにはガードレールはありません。

ガードレール
  • なし

８．情報アクションに関するガードレールとガイドライン

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

ガードレール
  • なし

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

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

ネットワーク パラメータ グループは次のもので構成されます。

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

経済パラメータ グループは次のもので構成されます。

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

技術/セキュリティ パラメータ グループは次のもので構成されます。

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

ガバナンス パラメータ グループは次のもので構成されます。

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

付録２: サポートに関するガイダンス

この付録２は、憲法を解釈する際の指針を提供することを目的としており、憲法委員会は憲法上の義務を遂行する上で関連性があり有用であると判断した場合には、この付録 II を考慮するものとします。

１．枠組みについての注記

Cardanoブロックチェーンは2017年に設立されました。2020年7月には独立したブロックバリデーターが導入され、2024年9月にはオンチェーンガバナンスシステムが導入されました。この憲法は、Cardanoブロックチェーンのガバナンストークンであるadaの所有者を代表する、分散型システム内のガバナンス主体の権利と責任を概説しています。現在、Cardanoブロックチェーンは、ブロックチェーン技術、スマートコントラクト、コミュニティガバナンスから成る分散型エコシステムです。

この憲法に取り組むにあたり、Cardanoコミュニティは、これは単なるブロックチェーンのための憲法ではなく、ブロックチェーンエコシステム全体のための憲法であることを認識しなければなりません。これは、はるかに野心的な試みです。そのため、ガバナンスアクションがどのように承認されるかという点は非常に重要であるものの、この憲法の唯一の焦点ではありません。むしろ、この憲法は、Cardanoコミュニティのすべての参加者が集まり、自らを統治し、人間の相互作用や協力のための全く新しいアプローチを形成できる基盤と基本的な枠組みを提供します。

必要に応じて、この憲法は憲法委員会の役割を認め、その権限を付与し、Cardanoコミュニティが協力のために集団的な組織に参加する権利を確認し、オンチェーンガバナンスを実現し、DRepに対してオンチェーン投票でada所有者の声を代表する権限を与えます。

また、本憲法では、Cardano ブロックチェーンガードレール を本憲法に盛り込むことにより、Cardano ブロックチェーン トレジャリーへのアクセスと使用を保護する必要性も認めています。

２．その他のご案内

憲法の起草者は、カルダノ コミュニティの他の参加者とともに、憲法の解釈に関するガイダンスを公開しており、今後も公開する可能性があります。これには、憲法のオンチェーン承認と同時にリリースされた定義ブックレットが含まれますが、これに限定されません。公開されたガイダンスが「情報」アクションに従って Cardano ブロックチェーンにハッシュされている限り、憲法委員会は、適切と判断されるガイダンスを検討し、利用することを妨げられません。

英語版（原本）：

英語版（コメント可能）

日本語翻訳版（コメント可能）