Braveウォレットで安心して署名をしていただくために

Anirudha Bose寄稿

EVMチェーンのDAppトランザクションへの署名は、セキュリティ的に悪夢のような体験です。ユーザーが署名要求を訳もわからずに承認する一方で、そのトランザクションが裏で何をしようとしているのか全く気づかないことはよくあることです。これは、暗号資産の業界では一般的に「ブラインド・サイン」と呼ばれています（暗号技術のブラインド署名と混同しないようにご注意ください）。

ブラインド・サインは残念ながらクリプトにおいて非常に一般的な攻撃手段であり、ユーザーには正当な取引と悪意のある取引を区別する方法がないため、攻撃者はユーザーを騙してウォレットを奪ってしまう取引にサインさせます。今年初め、OpenSeaのユーザーを対象としたフィッシング攻撃で、攻撃者は被害者を騙して、すべてのNFTを0ETHで売る取引に署名させるだけで、何百ものNFTを盗み出しました。クリプトエコシステムはこの事件を無視することはできません。

Braveウォレットの最新アップデートでは、取引承認時のストレスをなくすため、署名の使用感を再設計しています。そのため、Braveブラウザはバージョン1.45より、BraveスワップのすべてのEVM取引において、スマートに署名できるようになりました。0x APIを利用したあらゆる取引プラットフォーム（Braveウォレット内部スワップを含む）において、その取引がトークン残高にどのような影響を与えるのか、明確でわかりやすい説明が表示されます。

DeFiの危険性

今日においてDeFiアプリの使用は、お店に行って、自分のアカウントから購入に必要な現金を店員に引き出してもらうくらい身近なものです。あなたがやり取りするコントラクトは、ERC20インターフェースのapprove()メソッドを使用すると、あなたのトークン残高の一部または全部を使用する承認を得ることができます。以下のMetamask上の取引承認ポップアップを見てみましょう。これはOptimismネットワーク上のUSDC-ETHのUniswap取引です。

この承認画面ではメーカーとテイカーの資産(assets)、気配値(quate amounts)などのスワップ・パラメーターが見えないため、この取引を安心して承認するための情報が不十分です。これでは意味不明な書類にサインしていることと変わりありませんので、ユーザーにとって使い勝手が悪いだけでなく、安全ではありません。あなたが意識することなく、ほとんど何でも実行できるようになりすますこともできてしまいます。

16進数が表しているものとは?

スマートコントラクトにとってトランザクションは、WebサービスにおけるHTTPリクエストのように頻繁にやりとりされる情報です。DAppsはEVMトランザクションのデータセグメントを使用し(calldataと呼ばれます)、スマートコントラクトでどの関数をどのパラメータで呼び出すかを指示します。しかし、calldataは単なるバイト列であり、次の例のように、Etherscanの「Input Data」セクションでトランザクションのcalldataセグメントを見ることができますが、人間が読めるものではありません。

EVM calldataの解析

calldataは、読み取り専用でバイト単位のアドレス空間であり、トランザクションやコールのパラメータが保持されています。このcalldataはContract Application Binary Interface (ABI)に従ってウォレットとWeb3クライアントによってエンコードされます。ここでは、2つの uint256 型の数値を足すメソッドを持つ単純なコントラクトを見て、このメソッドを実行するためにcalldataがどのように作成されるかを見てみましょう。

calldataの最初の4バイトは呼び出される関数を指定しており、ファンクション・セレクタと呼ばれています。メソッドの引数は 32 バイトにまとめられ、32 バイトより小さな型は必要に応じてゼロパディングされます。uint256, address などの固定サイズの型は、32 バイトの範囲内で表現されます。しかし、byte型や配列のような動的な型は、head-tail エンコーディングに従います。この方式では、データはトランザクションの calldata の最後尾にパッケージされます。引数は、calldataの中において、コンテンツがある場所を指しています。

より理解を深めるために、上記のcalldataの例をエンコーディングの規則に基づいて細かく見てみましょう。

EVMがどのように裏でcalldataを解析しているかを示すために、コメントを大幅に追加して、サンプルのコントラクトロジックをなるべくわかりやすく改善してみます。

複雑なcalldataのパース

より現実的な例として、動的な型を含む0xコントラクト関数 sellTokenForTokenToUniswapV3 の calldata をパースする例を紹介します。動的な型は、固定サイズの型とは異なり、ヘッド-テール・エンコードスキームを使用することに注意してください。この例では、COWからUSDCへのスワップ取引で、オーダーに COW->WETH->USDC を使用しています。

呼び出そうとしている関数はこちらです。

同じcalldataを分解、グループ化して、スワップ取引のデータをどのように解析するかを示したのがこちらです。

calldataを解析するだけでは不十分で、引数 encodedPath に含まれる情報（Uniswap V3オーダーパス）を確認する必要があることに気をつけてください。calldataセグメント全体が理解できるようになったため、16進数のデータが1421.74 COW -> 1000 USDCのスワップトレードを表していると推測することができるようになりました。

プロダクトへの反映

技術的な改善は、ユーザーがその効果を感じ取れるようになることで、はじめて評価されるものです。最終的に必要になることは、ユーザーが確信を持ってスワップを承認するために必要な情報をすべてを提供するUXをデザインし、なおかつ将来的にDEX取引の大部分に適用できるような汎用性を持たせることでした。プロダクト・デザイナーとブレインストーミングを重ね、最終的に出来上がった画面がこちらです。