昨夜、友人がスマホで2つのアプリを見せてくれました。そのどちらもウォレットが必要だったんです。

気になっていたのは、接続できないことではありませんでした。
それぞれのアプリが、ウォレットを理解している仕方が
まるで違って見えたことでした。

だから私はDusk Connectを、より注意深く見直しました。

Dusk Connectは、dAppが互換性のあるウォレット提供者を発見できるようにし、ユーザーがその提供者を選択し、アクセスを要求し、さらにアクティブなウォレット、プロファイル、認可、ネットワークの変更に反応できるようにします。
最初は、これは一般的なウォレット基盤だと思えました。

しかし、もっと面白い結果に気づきました。dAppは、
特定のウォレット実装をアーキテクチャの一部に組み込むことなく、
接続用のインターフェースに依存できるのです。

これは重要です。統合は、依存関係になりがちです。アプリケーションの
ロジックが、特定の提供者の挙動を前提にしてしまうと、その提供者を置き換える際に
接続コード以上を触ることになる場合があります。

Dusk Connectは、その依存を外側に押し出します。

トレードオフは、抽象化してもウォレット状態は消えないことです。

提供者は変わり得ますが、アプリケーション側は
アカウントが変わったとき、認可が取り消されたとき、ネットワークが切り替わったときに
理解しなければなりません。つまり、接続の仕組みは抽象化できますが、
アプリケーションの状態は抽象化できません。

私は、ここにこそ本当のアーキテクチャ上の価値があると思っています。
狙いは単に、DuskのdAppと互換なウォレットを増やすことではありません。

ウォレット実装そのものが、アプリケーションの内部で
隠れた依存関係になるのを防ぐことです。

本当に、これはウォレット基盤の捉え方を変えます。
良い抽象化とは、すべてを隠すことではありません。
変わり得るものを、アプリケーションがそれでも制御しなければならないものを隠さずに
分離することです。

@Dusk で開発する人にとっての問いはこうなります:

どのウォレット前提をアプリケーションの内側に置くべきで、
どれをそのアーキテクチャの外に残すべきでしょうか？ 🧩

#Web3 #Blockchain #DeFi #dusk $DUSK $ETH @Dusk