MidgardがCardanoのeUTXOネイティブLayer 2を進展させDeFiのスケーリングを推進

MidgardはCardanoのLayer 2スケーリングアーキテクチャを設計段階から運用テスト環境へと移行している。ネットワークの拡張UTXOモデルを中心に構築されており、このプロトコルはアプリケーションに別個のガス資産やスマートコントラクト言語、決済ネットワークを採用させることなく、トランザクション処理能力を高めることを目的としている。

同プロジェクトは現在、迅速なソフト確定、ADAで支払われる手数料、CardanoのLayer 1で検証されるターゲット型の不正証明を設計の主要要素として挙げている。Midgardはまた、ベースレイヤーの処理容量に対して最大300倍の処理向上の可能性を示しているが、これはプロジェクトの推定値であり本番のベンチマークではない。

MidgardがCardanoの実行をLayer 2へ移す

Midgardはオプティミスティックロールアップであり、Cardanoのベースレイヤー外でトランザクションを処理し、その後ブロック情報をLayer 1にコミットする。

ユーザーはCardano資産をデポジットし、Midgard上で稼働するアプリケーションとやり取りし、その後メインネットワークへ資産を引き出す想定だ。トランザクションは引き続きCardanoのeUTXO検証ルールに従い、プロトコル手数料は別のLayer 2トークンではなくADAで支払われる。

ローテーションするオペレーターがトランザクションを検証し、それらをブロックに並べ、署名済みブロックヘッダーをオンチェーンのステートキューへ公開する。オペレーターは無効な状態を提出した場合に減額され得る保証金もロックする。

トランザクションは最終決済に至る前にLayer 2で迅速なソフト確定を受ける。Midgardはブロックが約1秒間隔で組み立てられると説明しており、現在プロジェクトのウェブサイトに表示されているアクティビティはローンチ前のシミュレートされたデータであると明記されている。

この構造により、アプリケーションの応答性と最終決済が切り分けられる。ユーザーは各トランザクションがCardano上で個別に処理されるのを待たずにLayer 2の状態と対話でき、一方でベースレイヤーは紛争解決と最終結果の確定を担い続ける。

MidgardはAnastasia LabsとInput Outputのパートナーシップを通じて開発されている。プロジェクトによれば、Cardano開発者は既存のバリデータロジックとeUTXOツーリングを維持でき、統合は主にトランザクションの送信先エンドポイントの変更に焦点が当てられるという。

不正証明が争われた状態をCardanoへ戻す

Midgardのセキュリティモデルは、オペレーター、独立したウォッチャー、オンチェーンのチャレンジプロセスを組み合わせている。

ブロックがコミットされた後、そのトランザクションデータは現在3日から7日とされるチャレンジ期間中は参照可能なまま保持される。ウォッチャーはトランザクションを再実行し、Cardanoに保存されたブロックヘッダーと結果を照合できる。

ウォッチャーが無効な状態遷移を特定した場合、Layer 1に不正証明を提出できる。チャレンジが成功すると、争われたブロックは巻き戻され、オペレーターには罰則が科される。期間が終了するまでに有効なチャレンジが提出されなければ、そのブロックはMidgardの確定状態に追加される。

このプロセスの中核にはCardanoのeUTXOアーキテクチャがある。トランザクションは特定の未使用出力を消費し、資産、スクリプト、アプリケーションデータを含む新たな出力を生成する。検証は共有のグローバルなアカウント状態にわたる連続的な変化ではなく、トランザクションとそれが消費しようとするインプットに依存する。

これにより、必要なインプットが引き続き利用可能である限り、送信前にトランザクションの妥当性と実行コストを評価できる。

Midgardはこのローカルなトランザクション構造を用いて、対象を絞った不正証明を作成する。無関係な複数のコントラクトの状態を再構築する代わりに、検証は争点となるトランザクション、その参照インプット、およびそれを処理したバリデータに焦点を当てられる。

検証範囲を狭めることで、Layer 1で必要となるデータ量と計算量を抑えつつ、Cardanoを決済と紛争解決のレイヤーとして維持することを意図している。

Midgardは実行モデルを置き換えることなくCardanoを拡張する

Midgardは、同じ流動性とユーザーを巡って競合する別個のブロックチェーンではなく、Cardanoの既存アプリケーション環境の拡張として位置付けられている。

選択した実行をMidgardへ移すアプリケーションは、アカウントベース環境を採用するのではなく、引き続きeUTXOモデルを利用できる。開発者は異なるコントラクト言語向けにアプリケーションを書き直したり、無関係な実行システムに合わせて再設計したりする必要がない。

これはCardanoのネイティブ資産にも当てはまる。トークンはUTXO内で直接保有および転送でき、標準的な資産移転は各トークンごとに個別のスマートコントラクトを必要とせず、台帳が処理する。

これにより、追加のガス資産や独立したバリデータセット、異なるスマートコントラクトアーキテクチャを基盤とするLayer 2システムとMidgardは差別化される。その設計は実行能力を拡張しつつ、争われた状態と最終決済をCardanoへ戻す。

このプロトコルは、分散型取引所、レンディングプラットフォーム、決済、その他オンチェーンでの頻繁なインタラクションを生み出すアプリケーションに、追加の稼働余地を提供し得る。単体で流動性や需要を生み出すわけではないが、高いアクティビティを支えようとするアプリケーションが直面するインフラ制約の一部を取り除くことはできる。

Midgardの次の運用マイルストーンには、初期のLace統合を超えた拡張、Cardanoアプリケーションのオンボーディング、オペレーターやウォッチャー、デポジット、引き出し、不正証明を継続的な利用下で検証することが含まれる。

これらのマイルストーンを達成すれば、CardanoのdAppsはeUTXOを放棄したり手数料用の別資産を導入したりすることなく、より高い処理能力の実行環境を得られる。そうなればMidgardは、推定スループットではなく、ロールアップ上で稼働するアプリケーションやCardanoへ正常に決済された状態によって評価されるようになる。