私が @Dusk Dusk の W3sper ドキュメントを読んだとき、DuskVM のクエリを普通の JSON インターフェースだと思っていました。Forge でコントラクトをコンパイルすると、data-driver の WASM も同時に生成され、アプリは contract ID で W3sper に登録します。driver は入力を ABI バイトにエンコードし、ノードは戻り値をデコードして返します。
それを私は、空港のグランドスタッフ用の翻訳カウンターみたいなものとして見ていました。旅客が JSON と言えば、滑走路が受け付けるのは決まった搭載形式だけ。翻訳カウンターはスキーマどおりにパッケージして、帰りに出力とイベントを取り出します。HTTP で raw bytes を送ればそのままコントラクトに渡され、JSON を送る場合は driver が利用可能なときだけ自動変換されます。get_version でバージョンが確認できます。
問題は、アップグレードの後に紛れ込みます。古い driver は成功を返すことがあっても、古くなった ABI としてデータを解釈してしまうかもしれません。メタデータの driver_available、driver_signature は、ドライバの身元確認にしか役立ちません。私はファイルハッシュを固定し、testnet で同じ入力を使って、元の bytes とデコード結果を突き合わせます。ページが読めることは翻訳のチェーンが通ったことを示すだけで、資産の状態は別途独立に検証する必要があります。
#dusk $DUSK
それを私は、空港のグランドスタッフ用の翻訳カウンターみたいなものとして見ていました。旅客が JSON と言えば、滑走路が受け付けるのは決まった搭載形式だけ。翻訳カウンターはスキーマどおりにパッケージして、帰りに出力とイベントを取り出します。HTTP で raw bytes を送ればそのままコントラクトに渡され、JSON を送る場合は driver が利用可能なときだけ自動変換されます。get_version でバージョンが確認できます。
問題は、アップグレードの後に紛れ込みます。古い driver は成功を返すことがあっても、古くなった ABI としてデータを解釈してしまうかもしれません。メタデータの driver_available、driver_signature は、ドライバの身元確認にしか役立ちません。私はファイルハッシュを固定し、testnet で同じ入力を使って、元の bytes とデコード結果を突き合わせます。ページが読めることは翻訳のチェーンが通ったことを示すだけで、資産の状態は別途独立に検証する必要があります。
#dusk $DUSK