合約のデプロイが成功したことを開発完了と見なすと、Dusk では簡単に誤判定してしまいます。@Dusk の DuskVM ドキュメントに沿って下を見ていくと、私は Forge のところで止まります。ここでは、注釈付きの Rust コードから ABI、schema、data driver を生成しますが、後者 2 つは付属ファイルではありません。アプリがチェーン上の状態を読み取るための入口です。この細部により、開発の進捗を再評価することになりました。WASM が実行できるのは、ルールが書き込まれたというだけの意味です。インターフェース記述と読み取りドライバが同じバージョンで提供されていなければ、フロントエンド、スクリプト、インデクサは依然として「状態がどんなものか」を推測するしかありません。
最も問題が起きやすいのはアップグレードです。チームが新しい合約をデプロイしたのに、data driver が旧版のままになっていることがあります。取引は通常どおり成功しますが、ページに表示される残高、フィールド、イベントはすでに遅れている可能性があります。ユーザーは何度もリロードし、エンジニアはまずノードを確認し、CS は「チェーン上は問題ありません」と説明します。しかし本当のズレは、合約の状態と読み取り契約の間で起きます。サービスを再起動してもバージョン不一致は解消できず、通常は再構築・検証を行い、アプリが一致するドライバに切り替わるようにする必要があります。
そのため私は、Forge を「足場（スキャフォールド）を作る時間を省けるツール」にとどめて考えていません。Forge は「合約が動くこと」と「アプリが正しく合約を解釈できること」を、同じデリバリーチェーンの中にまとめてくれます。減らせるのは、ロール間の推測であって、すべての統合コストではありません。$DUSK のエコシステムでは、今後特に注目すべきなのは、サンプルプロジェクトとリリース手順が ABI、schema、data driver のバージョン関係を明確に示しているかどうかです。もしこのステップが任意のオプションだと扱われるなら、開発者が得られるのは「実行できるが、信頼性をもって利用しにくい」合約である可能性が残ります。#dusk 👻👻👻