DuskはウォレットとSDKをついにローンチした。でも、市場が一般的にやっているやり方と違うのはなぜなのか——その点こそが読みどころだ

このキャンペーンで僕がDuskについて書いてきたことの多くは、プロトコルの話に巡っていました。ネイティブ発行、プライバシーの仕組み、機関投資家向けのパートナー。けれど、どのプロトコルが本当に実ビルダーに使われるかを決める「ある1つのこと」だけは、僕はずっと飛ばしてきました。それがデベロッパー体験です。

2026年4月、DuskはDusk WalletとDusk Connect SDKのベータ版を出荷しました。ChromeとFirefoxの拡張機能で、コードベースは1つ。さらに、同じインターフェース上で公開アカウントとシールド（保護）アカウントの両方をサポートしています。

プロバイダーAPIは、ほとんどのWeb3開発者にとって馴染みのあるMetaMaskが使っているEIP-1193をモデルにしています。DuskはEVMではないので、メソッドはdusk_*のプレフィックスを使い、発見（ディスカバリー）プロトコルはイベントベースです。そのため、複数の互換ウォレットを同じページに置いても競合しません。

そして、より際立っているのがドライバーのアーキテクチャです。開発者はスマートコントラクトを「ドライバー」と一緒にデプロイし、ユーザーはそれをウォレットにインストールして、開発者が意図した通りの方法で操作できるようにします。これは本当に解決すべき課題への回答です。ZK証明は当初、200MBを超えるほど重いプローバーキーが必要でした。チームは回路ディスクリプタ技術を使って、それを数KBまで圧縮しました。

また、Duskが2026年に支配的になった「組み込みウォレット」トレンドに従わなかった理由もこれで説明できます。そこでは、ユーザーがメールやGoogleでサインインするとSDKの裏側でウォレットが静かに作られます。しかしそのモデルでは、ZK証明の生成をサードパーティのサーバーに委ねることになります。Duskでは、証明はクライアントサイドで実行しなければなりません。そうしないと、プライバシーモデルを維持できません。

僕が考え続けている問いはこうです——実際に「本物のビルダー」がdAppsをどれだけの割合でデプロイするか。そのレートは、どんなプロトコルのベンチマークよりも正直な指標になるはずだ。
@Dusk $DUSK #dusk $BTC $BNB

#dusk @Dusk