$TRUMP +36%、MAGMA +29%、$ZEC +23%… 😂

過去6か月、ポリゴンのキャンペーン報酬を握りしめていて、あの一発の良いポンプを待っていました。😭

もともと、ウォレットをdAppに接続することって基本的に「許可が1つ増えるだけ」だと思っていました。

ユーザーが接続すると、アプリはアカウントを認識し、その後のあらゆる操作がその関係を通じて流れていく。

でも、新しい@Dusk Walletを調べるほど、「接続すること＝許可モデルの始まりにすぎない」ように見えてきました。

$DUSK Connect経由で、dAppはプロフィールの閲覧アクセス、署名、トランザクション、コントラクト呼び出し、あるいはシールド受信アドレスを要求できます。

ただし、アクションを要求することは、アプリにユーザーの鍵を渡すことではありません。

鍵はローカルに保たれます。Duskは拡張（extension）ビルドではPBKDF2とAES-GCMで保護し、ネイティブビルドではArgon2のStrongholdを使います。さらにウォレットには自動ロック、失敗したアンロックのバックオフ、そして要求元（origin）ごとにスコープされた権限があります。#dusk

それでdAppへのアクセスの考え方が変わりました。
接続されたサイトは、実行する権限をこっそり得ることなく、アクション要求を許可されることがあります。

ウォレットは承認の境界（approval boundary）として残ります。
私の注目点は、ローカルでの鍵保管だけではありません。

今どれだけのセキュリティが、承認画面で何が伝えられるかに依存しているかです。
秘密鍵は保護されたまま、ユーザーが誤解を招くコントラクト呼び出し、読めないメッセージ、想定外のアカウント要求に対しても「承認してしまう」可能性があります。originごとの権限は、どのサイトにアクセスが渡るかを制限しますが、そのサイトからのすべての要求が安全だと証明はできません。

ウォレットのリポジトリは、トランザクションの承認、読み取り可能/不透明なメッセージ、認証署名、コントラクト呼び出し、シールドアドレスの承認を分けています。

しかしDusk Connectと新しいWalletは開発者向けプレビューとして導入されたばかりなので、この許可体験は、実際のdAppsや実際のユーザー行動の中でまだ「機能している」と証明していく必要があります。

鍵をローカルに保持し、権限をoriginごとに分けることで適切なセキュリティ境界が生まれるのでしょうか？それとも、その下にある接続の標準よりも、各承認画面の分かりやすさのほうが重要になるのでしょうか？？