Anastasia LabsがCardanoのガバナンスをdAppの実行に接続

オープンソース実装により、オプトインしたCardanoのdAppが成立したレイヤー1のガバナンス決定を認識し、あらかじめ定義された変更を実行できるようになった。エンドツーエンドのテストはSanchoNetで完了しており、メインネットへのデプロイは未確認。

By SongMarketCap

Cardano News - Anastasia LabsがCardanoのガバナンスをdAppの実行に接続

Anastasia Labsは、Cardanoのガバナンスと分散型アプリケーション内部での実行との間に直接的な接続があることを実証した。SanchoNetで確認された13件のトランザクションを通じて、サンプルのdAppは成立したプロトコルパラメーター変更に応答し、自身の手数料を1 ADAから2 ADAへ引き上げた。

SanchoNetのテストがガバナンスとdAppの変更を接続

Cardanoのレイヤー1ガバナンスは、プロトコルパラメーターの変更、Treasuryからの引き出し、ハードフォーク、Constitutional Committeeの更新を承認できる。個々のdAppは通常、管理者キー、マルチシグウォレット、またはアプリケーション固有のDAOに依存する別個のガバナンス体制で運用されている。

Anastasia Labsは、dAppが成立したCardanoのガバナンス決定を自らの状態変更の認可として用いることを可能にするオープンソースのデザインパターンを開発した。この実装はPlutus V3向けにAikenで記述され、チームのaiken-design-patternsリポジトリで公開された。

このデモでは、Plutus V3のコストモデルの1項目を変更するガバナンスアクションを用いた。変更がガバナンスプロセスを完了してSanchoNetで有効化された後、dAppは更新されたモデルを認識し、PASSと呼ばれる認可トークンをミントした。最後のトランザクションでそのトークンをバーンし、アプリケーションの手数料を1 ADAから2 ADAへ引き上げた。

Cardanoレジャーがガバナンスのシグナルを提供

この実装は、投票履歴を調べたり、特定のガバナンスアクションの識別情報に依存したりしない。代わりに、パラメーター変更が成立した後にCardanoレジャーによって適用されるアクティブなPlutusのコストモデルを検証する。

これにより、提案が可決されたことを確認する外部オラクルが不要になる。検証には、プロジェクトの管理者キー、マルチシグ承認、バックエンドのインデクサーも必要ない。レジャーが新しいパラメーターを適用し、dAppのバリデーターはアクティブなコストモデルを自らの提案に記録された値と比較する。

13件のトランザクションから成るテストは、参照スクリプトの公開、アプリケーションとガバナンスの各状態の初期化、リンクされたパラメーターアクションの提出、成立後のPASSトークンのミント、そして手数料変更の実行を含んでいた。

Anastasia LabsのPhilip DiSarroは、この結果を、以前は不可能と考えられていた事柄を証明したものだと述べた。Plutusのスマートコントラクトは、専用のフィールドを通じて成立したガバナンスアクションの結果を直接読み取ることはできない。このデザインパターンは代わりに、スクリプト実行時に利用可能なアクティブなコストモデルを認証する。

オプトインしたdAppのみがこのモデルを利用可能

このパターンは、任意のアプリケーションに対するCardanoガバナンスの支配権を与えるものではない。開発者は、必要なバリデーターを意図的に統合し、許可される状態変更を定義し、選択したガバナンスシグナルに実行を結び付ける必要がある。

公開されたテストは、サンプルのアプリケーション手数料の変更のみを実証した。Anastasia Labsは、コントラクトのアップグレード、dAppパラメーターの変更、Treasuryのオペレーション、緊急時のコントロールなどを潜在的な適用先として挙げているが、これらのユースケースは今回のSanchoNetでの実行には含まれていない。

このモデルには未解決の制約もある。シグナルは固有のGovernance Action IDに紐付いておらず、タイミングの設定はマルチシグの構成に依存し、認可にはネットワークのコストモデルに対する実際の変更が必要となる。独立したセキュリティ監査、本番環境への統合、Cardanoメインネットへのデプロイは発表されていない。

今回の成果は新たなCardanoのプロトコル機能ではなく、オープンソースのアプリケーションデザインパターンである。dAppが当初からその権限を受け入れるように構築されていることを前提に、プロジェクトが管理する承認キーを、成立したレイヤー1のガバナンス決定に置き換えるための検証済みのルートを開発者に提供する。