#dusk $DUSK @Dusk 私は当初、Data Driverは契約の持ち主の署名さえ付いていれば、安全性は十分だと思っていました。Duskのソースコードを読み進めて、この確かさは半分しかないことが分かりました。署名は「誰がアップロードしたファイルか」は証明できますが、「どのバージョンの契約に適合するか」は証明できないのです。

Duskでは、Data Driverは独立したWASMファイルです。ウォレット、取引所、そしてロボットがこれを使って、契約から出てきた機械バイトを金額、権限、イベントとして読み取り、さらにユーザー操作を契約が実行できるデータへと符号化します。アップロード時、契約の持ち主がDriverファイルのハッシュに署名し、ノードはそれを契約IDに紐づけて保存します。

問題が主にクライアント側にあることに気づきました。W3sperも現状、同じように契約IDでDriverを登録・キャッシュしています。公式リポジトリの公開Issueでは、ここに「Driverが契約のバージョンやハッシュと強く結び付いていない」点が欠けていると指摘されています。

その結果、非常にDuskらしいミスマッチが起こり得ます。古い端末はキャッシュされた古いDriverを使い続ける一方、新しい端末は新しいDriverをダウンロードします。どちらのファイルも正規の経路から来ている可能性があり、両者ともエラーは出ません。同じブロック高であっても、金額やイベント、さらには取引パラメータが別の意味として読み取られることがあります。

私は取引の中でこの種の故障が最も怖いです。取引が失敗すればアラームが鳴ります。しかしデータが静かに誤って読み取られてしまった場合、ウォレットの残高、ロボットのポジション、データ・プラットフォームの記録などがそれぞれ別々に計算されたまま進み、資金が合わなくなって初めて露呈します。

今後、$DUSK の評価指標として導入します。契約数は簡単に積み上げられますが、Driverハッシュの一致率のほうが価値があります。主要なウォレット、取引所、インデクサがどのDriverバージョンを使っているのか、どのブロック高から有効か、旧版がいつ無効になるのかは、確認可能であるべきです。

Duskは「契約を実行すること」と「契約を解釈すること」を二層に分け、柔軟性を得ました。しかし同時に、固有の責任をもう一層引き受けることにもなりました。正規のファイルであっても、自分が期限切れではないことを証明しなければならないのです。そうして初めて、皆が安心して取引できるようになります。

$BTC