変更履歴でうっかり見落としそうになった点：実行時の依存関係がゼロ。SDKローンチに関する大見出しの下に埋もれていました。

読みやすく言うと、Dusk Connectはウォレット連携を開発者にとって簡単にするだけです。そう、それが売り文句——軽量なSDKを組み込み、終わり。

もう少し腰を据えて見ると、これは「誰が接続レイヤーを握っているか」の話でもあります。Duskはイベントベースのディスカバリーパターン、`dusk:announceProvider`、`dusk:requestProvider`を使い、EthereumのEIP-6963をそのままモデル化しています。1つのウォレットにハードコードするdAppの作り方とは違い、リクエストをブロードキャストして、互換性のあるすべてのウォレットが応答できるようにします。dAppは「どのウォレットが勝つか」を知る必要がありません。

ただ、見過ごされがちな点があります。ディスカバリを標準化しても、信頼が標準化されるわけではないのです。どんな拡張機能でも、そのリクエストイベントを聞いて自分をプロバイダとして名乗れます。EIP-6963はEthereumの古いwindow.ethereumの競合状態を解決しましたが、ウォレットのなりすましは解決しませんでした。負担をユーザーの側に移しただけです——どのプロバイダが正当かを、その都度の接続プロンプトで検証する必要があるのです。

同じトレードオフは伝統的な金融にも見られます。オープンバンキングのAPIは、第三者アプリが口座アクセスを要求する方法を標準化しましたが、標準化されたリクエスト形式が「要求者が安全であること」を保証するわけではありません。銀行はその理由のために、個別の同意画面や検証画面をさらに重ねているのです。

私の最初の直感は、「依存関係ゼロ＝導入が軽くなる」でした。けれどそれだけではありません。依存関係が少ないほど、サプライチェーンの侵害が隠れる場所も減り、万一すり抜けた場合の言い訳も減るのです。

次は、Duskがこの仕組みを採用するウォレットプロバイダを増やす方向に注力すべきでしょうか。それとも、dAppsが「実際に通信しているプロバイダ」がどれかを検証する部分をより堅牢にする方向に注力すべきでしょうか？

@Dusk #dusk $DUSK