Cardanoの分散化の検証はノード数だけでは測れない
Cheeky CryptoのホストNick Reganは、複数の独立したCardanoクライアントが分散化を強化するのは、プロトコルの解釈が一貫している場合に限られる理由を説明する。CPS-0034は、現行および過去のプロトコルバージョンにわたるPlutus Coreのより広範なテストを提案している。
By SongMarketCap
Cheeky Cryptoの共同創業者でホストのNick Reganは、Cardanoの分散化に潜む見えにくいリスク、すなわちネットワークの規則について見解が食い違う可能性のある独立開発ソフトウェアに関する24分の分析を公開した。Cheeky Cryptoは、NickとChris Reganが2020年に設立した暗号資産の分析と教育のプラットフォームである。
Reganは、自身の分析をCPS-0034と結び付けた。これは、代替的なCardanoノード実装で用いられるPlutus Core evaluatorに対する適合性テストの拡充を提案する公開のCardano Problem Statementである。この議論は、ステークプールの分布、ガバナンス参加、ネットワークに接続されたマシンの台数といった論点を超えている。
複数のクライアントが自動的に安全性を高めるわけではない
Reganは、ネットワークの物理的な分散とソフトウェアの分散を区別する。Cardanoは複数の国にまたがり多数の主体が運用する数千のノードを持ち得るが、その多くのインフラが依然として同一のコアノード実装に依存している可能性がある。
共通の実装にコンセンサスに関わる重大な欠陥が含まれていれば、地理的に分散した多数のノードが同時に同じ問題に直面し得る。代替クライアントは、異なるチームが異なるプログラミング言語、アーキテクチャ、設計判断を用いることを可能にすることで、その集中を緩和する。
別のリスクは、それらの実装がプロトコルを異なる解釈で扱う場合に現れる。
あるクライアントが受け入れるトランザクションを別のクライアントが拒否することがあり得る。二つのPlutus evaluatorが同一のスクリプトを処理しても、異なる結果を返したり、異なる実行コストを算出したりする可能性がある。ブロックの有効性がそれらの結果に依存し得るため、ノード間の不一致はレジリエンス向上ではなくチェーンの分岐を招くかもしれない。
UPLCはUntyped Plutus Coreの略で、Plutusスマートコントラクトがコンパイルされる実行言語である。代替のevaluatorは、Cardanoで確立されたHaskell実装の構造を再現する必要はないが、プロトコルが期待するコンセンサス関連の振る舞いは再現しなければならない。
Reganはこの要件を、独立した合意の必要性と表現する。
別個のコードベースが実効的な冗長性をもたらすのは、正当な入力、エッジケース、過去のプロトコルバージョンに対して一貫して同じ答えに到達する場合に限られる。
Reganは、保有者の多くが目にする分散化の議論とこのソフトウェア層のリスクを区別するために「ADA Has a Decentralisation Problem」というタイトルを用いている。彼の分析は、既存のメインネットでのインシデントではなく、予防的なインフラ作業に焦点を当てる。
CPS-0034はPlutus Coreの適合テストを拡張する
Plutus Coreチームは8月12日にこの提案を一般公開のレビューに付した。続いてCIP編集者が初期レビュー後に番号CPS-0034を割り当て、技術提案は現在もフィードバックを受け付けている。
CPS-0034の提案によれば、Cardanoは現在、外部開発者に約千件の事前定義されたgolden fileテストを提供している。これにより、独立したevaluatorが提供されたスクリプトを実行し、その出力を期待結果と比較できる。
既存のスイートは初期的な互換性チェックを提供するが、二つの制約が指摘されている。Plutusチームが内部で用いているプロパティベーステストが公開されておらず、またプロトコルバージョン、レジャー言語バージョン、コストモデルの最新の組み合わせにしか対応していない。
プロパティベーステストは、手作業で用意した少数の例を超える。ジェネレータが数百から数千の多様な入力を生成し、それらからPlutusスクリプトを構築して、定義された振る舞いの性質が維持されるかを検証できる。
この手法は、通常の活動ではほとんど現れない異例の組み合わせ、境界値、条件にまでカバレッジを広げる。そうした場面こそ、独立に開発された実装がプロトコルの振る舞いに関する異なる前提を露呈しやすい。
CPS-0034は、生成されたテストケースを可搬な形式で配布し、外部の実装が最小限の統合作業で利用できるようにすることを提案している。各テストには、プログラム、その入力、期待される結果、該当する場合は期待される実行バジェットが含まれ得る。
歴史的なカバレッジも含まれる。Cardanoは複数のレジャーの時代、ハードフォーク、Plutus言語のバージョン、コストモデルの変更を経てきた。チェーンを再生して過去のブロックを検証することが求められるなら、代替ノードはその歴史を正しく解釈しなければならない。
この提案はPlutus Core evaluatorの適合性に特化している。Cardanoノード内部のネットワーキング、レジャー、コンセンサスの全てのコンポーネントに対する完全なテストフレームワークを定義するものではない。ノードの安全性との関わりは、スクリプトの評価結果が異なればトランザクションやブロックの有効性が変わり得るという事実に基づく。
独立したコードは一貫した振る舞いを証明しなければならない
CPS-0034には依然として複数の未解決の技術的課題が含まれている。生成されたテストをどのように配布するか、期待結果と実際の結果の差異をどのように報告するか、ケースをプロトコルバージョンでどのようにフィルタするか、数千件のテストをどのように効率的に実行するかが議論されている。
Amaruに関わる開発者もすでに公開の議論に参加している。AmaruはRustで書かれたオープンソースのCardanoノードクライアントで、確立されたHaskellのcardano-nodeとは別に開発された実装を運用者に提供する。
Amaruのコントリビューターは、同プロジェクトが既存のsemanticおよびflatの適合スイートをすでに取り込んでいると報告した。このフィードバックは、より広範なプロパティおよびバージョンのテストを支持しつつ、現実的なオンチェーンのシナリオ、クライアントに中立なデータ形式、第三者が追加のケースを寄稿しやすい経路を求めた。
提案されたアプローチには、構造化されたテストフィクスチャや、扱うプロトコルおよび言語のバージョンに応じたケースのタグ付けが含まれていた。ジェネレータをHaskellのみで実装することについては、他言語で作業するチームに追加の障壁となり得るため、懸念も示された。
共有のテスト標準は同一のソースコードを求めない。各チームはそれぞれのアーキテクチャ、プログラミング言語、開発手法を維持でき、その上で結果としての実行時の振る舞いはCardanoの規則と互換であり続ける。
ADA保有者にとって、この問題は短期的な市場パフォーマンスではなくインフラのレジリエンスに関わる。取引所、ウォレット、分散型アプリケーション、機関システムは、異なるノードがトランザクション、スクリプト、ブロックについて決定論的な結論に到達することに依存している。
もしCPS-0034が可搬でバージョン対応の適合スイートを生み出せば、代替のCardanoクライアントは、単に別個のコードベースとして存在するだけでは互換性を示せなくなる。Cardanoのプロトコルの歴史を通じて、独立に書かれたソフトウェアが同じ結果と実行コストに到達することを再現可能な証拠として提供し、不一致を本番のブロックに到達する前にテスト中に顕在化させられるようになる。