ブロックチェーンの世界では、ユーザーはしばしば、スマートコントラクトが代わりにトークンを使うことを許可する権限（許可）を与える必要があります。たとえば、分散型取引所（DEX）を使用してトークンをスワップする場合、ユーザーは最初に取引契約に自分のウォレットから特定額のトークンを送金する権限を与える必要があります。従来のERC-20標準では、このプロセスには2つの別々のオンチェーン取引が必要です。承認用の1つと実際のトークン転送用のもう1つです。この2段階のプロセスは手間がかかるだけでなく、追加のガス手数料も発生します。ユーザーエクスペリエンスとセキュリティの両方を向上させるために、Ethereumコミュニティは署名ベースの承認メカニズムを導入しました。許可（EIP-2612など）、そして後にPermit2と呼ばれる高度なバージョンが開発されました。これらの新しいメカニズムにより、ユーザーはオフチェーン署名を通じてトークン承認を付与することができ、余分なオンチェーン取引が不要になります。

この記事では、従来のERC-20承認の動作方法とその制限を説明することから基本を始めます。その後、PermitとPermit2の機能、利点、トレードオフについて詳しく説明し、両者の効率性とセキュリティをいかに向上させるかについて掘り下げます。特に、潜在的なセキュリティリスクについても検討します。悪意のある署名を利用したフィッシング攻撃そして安全に留意するためのヒントを提供します。ブロックチェーンについて初心者であるか、または暗号通貨投資の旅を始めたばかりであれ、このガイドはこれら重要な技術革新を理解するのに役立つことを目指しています。

ERC-20認可モデルの基本原則

Permitに入る前に、まずは従来のERC-20トークン認可モデルの動作方法とその制限について見てみましょう。

従来のERC-20承認の仕組み

ERC-20は、Ethereum上のトークンの標準です。承認やtransferFromなどの機能を定義し、これによってトークンの認可が可能となります。ここでの認可とは、トークン保有者（所有者）が、通常はスマートコントラクト（支出者）に自身の代わりに一定量のトークンを転送することを許可することを意味します。基本的なプロセスは次のように機能します:

1. トークン保有者は、トークン契約のapprove(spender、amount)関数を呼び出します。これにより、契約の内部マッピングに承認が記録され、通常はallowance[owner][spender] = amountと表されます。たとえば、ユーザーAがUniswap契約に最大100トークンを支出する権限を付与した場合、契約はallowance[A][Uniswap] = 100を格納します。この手順にはオンチェーン取引とAが支払うガス料金が必要です。
2. DeleGate.iod転送（transferFrom）：後で、Uniswap（または別のdApp）がAの代わりにトークンを使う必要があるとき、トークン契約上でtransferFrom（A、B、amount）を呼び出します。契約は、allowance[A][Uniswap]が十分かどうかをチェックします。十分であれば、契約は指定された金額をAからBに転送し、その金額をallowanceから差し引きます。

承認モデルの制限と課題

上記の2段階モデルにより、ユーザーはプライベートキーを共有することなく契約を承認して資金を管理できます。しかし、この従来のアプローチにはいくつかの実用的な問題も伴います。

2つの取引が必要で、ユーザーエクスペリエンスが悪い
ユーザーがdAppで新しいトークンを使用したい場合、実際に希望のアクション（スワップやステーキングなど）を実行する前に、別個の承認トランザクションを送信する必要があります。つまり、彼らのウォレットは2回確認を促し、追加のガス手数料を請求します。初心者にとって、この追加のステップは混乱を招く可能性があり、不便です。

断片化された承認管理
複数のユーザーが相互作用する場合dApps同じトークンを使用しても（例：Uniswapで取引してから異なるDeFiプロトコルに預け入れる）、各dAppには別々の承認が必要で、同じウォレット内の同じトークンであっても、繰り返し承認が必要で、時間とガスが無駄になります。

また、各dAppは独立して独自の手数料を管理するため、ユーザーはその承認に対してほとんど中央集権的な制御を持っていません。一部のツール、Revoke.cashそしてDeBankユーザーはトークンの許可を表示および管理できますが、多くのユーザーはそれに気付いていません。そして、気付いていても、権限を取り消すにはオンチェーン取引が必要であり、コストがかかります。その結果、多くの古いまたは使用されていない承認は単に忘れられています。

無制限承認のリスク
頻繁な承認トランザクションを回避するために、多くのdAppsは、ユーザーに無制限の承認を付与し、契約がユーザーの全トークン残高を消費できるようにし、有効期限が設定されません。このアプローチは後で努力を省く一方、深刻なセキュリティリスクをもたらします。dAppまたは契約が侵害された場合、攻撃者は承認されたトークンをすべて排出できます。

これらの課題は、開発者がより良い代替案を求めるきっかけとなっています。理想的には、ユーザーは承認とアクションの両方を完了するために1回だけ（可能であればオフチェーンかつガス無料で）サインする必要があります。承認は、潜在的なリスクを最小限に抑えるために範囲と期間が制限されているべきです。これがERC-20 Permitの導入の背景にある動機です。

許可：署名ベースのERC-20認証（EIP-2612）

許可証の概念は初めて導入されましたDAIステーブルコイン契約は後にEIP-2612として標準化されました。要するに、Permitは、オフチェーン署名を使用してトークン転送を承認するユーザーに権限を与え、別個のオンチェーン承認トランザクションを送信する必要がなくなります。どのように機能し、その特徴をより詳しく見てみましょう。

許可のしくみ

許可証はデジタル署名に基づく認証メカニズムです。ERC-20トークン契約においてPermitをサポートする場合、permit()という関数が追加されます。この関数は次のようになります:

function 許可(
アドレスの所有者、アドレスの支出者、
uint256の値、uint256の締め切り、
uint8 v、bytes32 r、bytes32 s
) 外部;

ここでは、オーナー、支出者、および値は、誰が許可を与えるか、誰が許可を受け取るか、許可される金額を指定します。期限切れは、署名の有効期限を示します。パラメータv、r、およびsは、ECDSAデジタル署名。Permitを使用すると、ユーザーは別々のオンチェーン承認をバイパスし、単にメッセージに署名（Gasを支払わずに）し、この署名をトランザクションに含めることで、認証を1ステップで完了させることができます。

許可ワークフロー

従来の承認と比較すると、許可は余分なオンチェーン取引の必要性を取り除き、時間とGas手数料の両方を節約します。また、承認に対する細かい制御を可能にします。たとえば、ユーザーはちょうど50 USDCを使うことを許可する許可をサインし、有効期間が5分だけのものにすることができます。署名が漏洩したとしても、期限切れ後には使用できなくなるため、リスクが軽減されます。今日、分散型取引所や貸出プラットフォームなど、多くのDeFiプロトコルが許可をサポートしています。よく知られた例には、Uniswap V2/V3LPトークン、DAI、およびUSDC, EIP-2612の標準を実装しており、ワンステップ、署名ベースの承認が可能になっています。

ただし、Permitの最大の制限は、トークン契約内で直接実装する必要があるということです。トークンの開発者がpermit()メソッドを追加していない場合、つまりEIP-2612をサポートしていない場合、Permitを使用することはできません。EIP-2612は2020年に導入されたばかりなので、多くの古いトークンには含まれておらず、新しいトークンでも必ずしも採用されているわけではありません。これにより、Permitの適用範囲が制限されます。サポートされていないトークンは引き続き従来の承認フローが必要です。

別の問題は、ウォレットソフトウェアが通常EIP-712を使用してフォーマットされる許可署名を適切に処理および表示する必要があるということです。ほとんどの主要なウォレットは現在これをサポートしていますが、一部のウォレットは人間が読めるメッセージの代わりに生データを表示し続けており、ユーザーが何に署名しているのか理解するのが難しくなっています。EIP-2612の明確なインターフェースがない場合、ウォレットは署名に基づく承認の理解を妨げる可能性があります。さらに、並行して展開されるケース（異なるチェーン上で同一のアドレスを持つ契約など）では、署名が他の環境で再利用される可能性があります。したがって、ユーザーは自分の署名の中のチェーンIDと契約アドレスが現在の環境と一致していることを確認し、Chain Aのトークンに対する許可がChain Bの同じ契約アドレスによって誤用されないようにする必要があります。

要するに、パーミットはERC-20の承認の効率と柔軟性を大幅に向上させ、ガスレスの承認メカニズムにおける重要なマイルストーンを示しています。ただし、これは完璧な解決策ではありません。トークンレベルのサポートが必要であり、新たなリスクをもたらします。次に、UniswapのPermit2がPermitによって築かれた基盤をどのように拡張しているかを見ていきます。

Permit2: ユニバーサル認可管理契約

許可機構が人気を博するにつれて、新たな課題が浮上しました。署名ベースの承認の利便性を許可していないトークンにどのように拡張するか。この問題に対処し、さまざまなシナリオでの承認エクスペリエンスを最適化するために、Uniswapチームは2022年にPermit2を導入しました。トークン固有の機能とは異なり、Permit2は独立した承認管理スマートコントラクトです。それはトークンの承認のための中間業者として機能し、統一された強化された許可機能を提供します。Permit2の原則と機能を分析しましょう。

Permit2の動作原理

Permit2は、承認リレーサービスとして機能します。そのコアコンセプトはシンプルです: ユーザーは、一度だけPermit2契約に承認を与え、その後、さまざまなアプリケーションへのサブ承認を管理します。こうした仕組みです。

1. 1 回限りの Permit2 承認: ユーザーは、従来の approve(Permit2, max_amount) メソッドを使用して、各トークンの Permit2 を承認します。これはマスター承認であるため、大量または無制限の金額をお勧めします。完了すると、Permit2 コントラクトは、そのトークンのユーザーの代わりに transferFrom を呼び出すことができます。これにはオンチェーントランザクションが必要ですが、一度だけ行う必要があります。
2. サブ認可のためのオフチェーン署名：ユーザーがDAppとやり取りしたい場合（たとえば、マルチトークンスワップ用のUniswap Universal Routerを使用する場合）、彼らはPermit2の仕様に従ったオフチェーン認可メッセージに署名します。この署名には、許可されたトークン、金額、ターゲット支出者（特定のDApp契約など）、有効期限などの詳細が含まれています。
3. 署名を使用したDApp転送リクエスト：DAppがユーザーの署名を受け取り、トークンを使用する必要がある場合、トークン契約を直接呼び出す代わりに、Permit2の関数（permitTransferFromのような）を呼び出します。この関数はユーザーの署名データを検証し、操作が付与された権限（トークン、金額、期限）の範囲内であることを確認します。検証後、Permit2はマスター承認を使用してtransferFromを呼び出し、ユーザーから指定された受取人にトークンを移動します。要点：Permit2契約自体が支出者として機能し、トークンを転送するために独自の権限を使用し、追加の署名検証ステップを踏みます。
4. 動作完了：Permit2がtransferFromを正常に実行すると、資金はユーザーからDAppまたは指定されたアドレスにスムーズに移動します。ユーザーの視点からは、彼らは取引で署名のみを提供し、契約がすべての後続のアクションを処理します。

Permit2の認証フローは簡単です: ユーザーはトークンごとにPermit2に一度だけ最大承認を与える必要があります。その後、アプリケーション(Uniswap Universal Routerなど)とやり取りする際には、単にPermit2の署名を取引に含めるだけで、追加のオンチェーン承認なしに認証と転送を完了させることができます。Permit2契約は署名を検証し、そのマスター承認を使用して転送を実行します。(出典: Permit2＆Universal Routerの紹介)

このモデルを通じて、Permit2は、permit()メソッドを実装しているかどうかに関係なく、EIP-2612の署名ベースの認証コンセプトをすべてのERC-20トークンに拡張します。ユーザーが最初にPermit2契約に承認する限り、後続の操作に署名を使用できます。特筆すべきことに、Uniswapは、Ethereumメインネットおよび複数のLayer 2ネットワーク全体で同じアドレスに展開された、オーナー不在で非アップグレード可能な契約としてPermit2を設計しました。つまり、すべてのアプリケーションが実際に同じPermit2インスタンスを使用し、真の「一度承認、どこでも使用」機能を実現しています。

Permit2の主な特長

次世代の認証システムであるPermit2は、すべてのトークンに対する署名に基づいた承認を可能にするだけでなく、セキュリティと使いやすさを向上させるための追加機能も提供しています。以下にその主な特長を示します。

自動期限切れ
すべての Permit2 承認には、有効期限のタイムスタンプを含めることができます。ユーザーは、署名時にサブオーソリの有効期限を指定できます。期限が過ぎると、マスター承認がまだ有効であっても、Permit2 は署名を拒否します。これにより、無期限の承認が未使用のまま残るリスクに効果的に対処できます。

シングルユース署名転送
Permit2では、ユーザーが許可を設定する必要なく、署名のみを使用して特定のトークン転送を受信者に認可できる直接署名転送モードを提供しています。これは一度限りの支払いシナリオに最適です。ユーザーは、100トークンを友人のアドレスに転送することを許可するメッセージに署名し、友人または仲介者がこの署名を使用して転送を実行できます。使用されると、署名は無効になり、残っている権限はありません。

一括承認と転送
Permit2は、複数の承認や転送を一括処理することで効率を重視しています。ユーザーは1つの署名で複数のトークンに異なる金額を承認したり、1つのトランザクションで複数のトークンを転送したりすることができます。これにより、ガスが節約され、上級ユーザーにとってステップが削減されます。

バッチ取り消し
バッチ承認を超えて、ユーザーは1つの取引で複数のトークン/アプリケーションの権限を取り消すことができます。これにより、過去の承認を整理する作業がはるかに便利になります。

追加データ証明
Permit2には、のようなインターフェースが含まれていますpermitWitnessTransferFrom署名に追加の検証データを含めることを許可するもの。これにより、特定の取引の詳細を署名に含めて、異なる文脈での署名再利用を防止するなど、より複雑なシナリオをサポートします。

これらの機能により、Permit2 は Permit のすべての利点を再現するだけでなく、柔軟性とセキュリティ制御も強化します。特に、自動有効期限と1回限りの署名転送により、必要最小限の承認が標準となり、長期的なリスクが軽減されます。

要約すると、Permit2は従来の許可メカニズムの拡張および強化として機能します。これら2つのアプローチの主な違いを調べてみましょう。

Permit2エコシステムの採用と実装

UniswapがPermit2を導入して以来、多くのプロジェクトがこのメカニズムを統合し、業界の標準化を加速しています。最新のデータによると、Dune Analytics2025年4月時点では、310万以上のEthereumメインネットアドレスがPermit2契約に承認を与え、その普及が示されています。

Permit2エコシステムと実装状況。ソース:Dune Analytics

たとえば、Uniswap はパーミット2をそのユニバーサルルーターに統合し、1つの取引で複数トークンと NFT を交換できるようにしました。ユニバーサルルーターを通じて、ユーザーは 1 つの取引で複数の操作を連鎖させることができます。たとえば、3 つのトークンを 2 つの目標トークンと NFT の購入に交換し、すべての認可要件をパーミット2 の署名で処理します。これにより、プロセスが大幅に合理化され、総ガスコストが削減され、ユーザーエクスペリエンスの向上にパーミット2 が直接影響を与えていることが示されています。

さらに、Permit2のオープンソース展開がさまざまなチェーンに広がるにつれ、増え続けるウォレットやDAppツールがそれをサポートし始めました。Revoke.cashなどのセキュリティツールは、ユーザーがPermit2の認可記録を表示および取り消すことを可能にするようにサービスを更新しました。MatchaもPermit2のSignatureTransferモジュールを実装し、"一回限りの認可"メカニズムを実現しました。

このような進歩にもかかわらず、Permit2の普及には課題があります。ERC-20の承認を直接使用する場合と比較して、Permit2の実装には署名ロジックの処理が必要になり、開発のオーバーヘッドが増加します。これは、小規模なチームを思いとどまらせる可能性があります。一方、ユーザー教育は重要で、Permit2を使用する多くのDAppsは、署名の重要性についてユーザーに教える必要があります。現在、Permit2の統一された利点はこれらの摩擦点を上回っているように見えますが、完全な市場浸透にはまだ時間がかかります。

Permit2と新しいソリューションを比較する：セッションキーとERC-4337

過去8年間、ERC-20認証メカニズムは複数の取引からガスレス署名、そしてスマートアカウントへと進化してきました。各進歩はユーザーエクスペリエンス(取引と署名の要件の削減)とガスコストのバランスを最適化することを目指しています。これらのテクノロジーの比較です。

Permit2の他に、注目すべき新興認可ソリューションとしてSession Keysというものがあります。ERC-4337アカウント抽象化, それぞれが問題に異なるアプローチを提供しています。

セッションキーは、厳密な認証モデルではなく、ウォレットまたはアカウントレベルでの一時的なキーメカニズムであるため、特にユニークです。トークンコントラクトを変更する代わりに、ウォレットが特定の操作に対して時間制限と量制限のある一時的な秘密鍵を生成できるようにします。これにより、ゲームアイテムの購入や1回限りのマイクロペイメントに最適です。彼らの焦点は、Permit/Permit2の契約変更アプローチとは異なり、一時的なユーザーインタラクション用に特別に設計された、単一承認のリスクを軽減することです。

ERC-4337は、認証ロジックをスマートアカウントに直接埋め込むことで、ユーザーが認証条件をカスタマイズし、従来の承認手順をスキップできるようにすることで、異なるアプローチを採用しています。柔軟なUserOperationとPaymasterメカニズムにより、セキュリティとユーザーエクスペリエンスの向上を実現します。

今後のトレンドを見ると、これらの異なるソリューションが共存する可能性があります。短期的には、Permit2は新しいDAppsの標準であり続け、1回限りの認証を通じてユーザーエクスペリエンスを向上させると同時に、フィッシングリスクを軽減するためのセキュリティ教育とツールサポートを促進します。中期的には、ERC-4337とアカウントの抽象化がレイヤー2とメインネットで普及するにつれて、ユーザーは従来のERC-20承認の制限から解放され、承認をより正確かつインテリジェントに管理できるようになり、Permit2の必要性が減少する可能性があります。

長期的なビジョンは、ユーザーがボタンをクリックするだけで、必要なすべての承認がバックグラウンドで自動的に行われ、リスクの高い状況でのみ明確なプロンプトが表示される、Web2 と同じくらいシームレスで直感的な承認エクスペリエンスを作成することです。このビジョンを達成するには、基盤となるプロトコル、ウォレット、dApps全体での継続的なコラボレーションとイノベーションが必要です。Permit2は、この過渡期における重要なステップですが、理想的な状態に到達するまでには、まだ長い道のりがあります。その過程で、コミュニティと開発者の両方が実用的なアプローチを維持し、各ソリューションの長所と制限を完全に理解し、より安全でユーザーフレンドリーな承認環境を構築するために協力する必要があります。

全体的に、Permit2はすぐに実装できる実用的な解決策を提供しており、Session KeysやERC-4337などの技術は、認可の取り扱い方法におけるより基本的で長期的な改善を示しています。

署名ベースの承認のセキュリティリスク

新しい技術では、許可と許可2は、新しい効率だけでなく、特に署名ベースの承認攻撃のリスクも導入します。

Permit2やEIP-2612 Permitなどの署名ベースのスキームでは、誤用やリプレイ攻撃に対抗するために、コア契約設計に複数の保護層が組み込まれています:

1. ノンスベースのリプレイ保護

Permit2 は、(所有者、トークン、浪費者の) タプルごとに個別の nonce カウンターを保持します。ユーザーが新しい承認に署名するたびに、対応する nonce がインクリメントされます。攻撃者が古い署名を再利用しようとすると、コントラクトが nonce が既に使用されているかどうかをチェックするため、失敗します。

2. 期限の施行

各署名には期限フィールドを含める必要があります。契約が署名を検証する際、現在のブロック時間が期限よりも遅いか等しいことを確認します。署名が期限切れである場合は、それが有効であっても拒否されます。これにより、長期間有効な認証が後で悪用されるのを防ぎます。

3. 細かい許可制御

Permit2 署名では、最大許容量を指定できます。トークンの転送が行われる前に、コントラクトは要求された金額がこの制限内にあることを確認します。この契約では、承認された金額の全額が自動的に使用されるわけではないため、ユーザーは手当を部分的に使用でき、フルドレインエクスプロイトのリスクが軽減されます。

4. シングルユースおよびバッチモード

持続的な許可ベースの承認に加えて、Permit2はSignatureTransferを介した一度きりの署名もサポートしています。これらの署名は1つの取引にのみ有効であり、実行後すぐに無効になります。これは一度きりの支払いに最適であり、後で署名が再利用されるのを防ぎます。

これらの階層化された保護は、許可スタイルの承認スキームがユーザーエクスペリエンスを向上させ、ガスを節約すると同時に、「リプレイ攻撃」、「過剰承認」、「無期限の署名有効性」などの従来のリスクを最小限に抑えるのに役立ちます。

しかし、セキュアな契約レベルの保護があっても、ソーシャルエンジニアリング（特にフィッシング）は依然として防御が最も難しい脅威です。次のセクションでは、一般的なフィッシングの手法と、攻撃者がユーザーを騙してPermit2を悪用する悪意のある承認に無自覚に署名させる方法について見ていきます。また、安全を確保するためのヒントも提供します。

シグネチャフィッシング攻撃はどのように起こるのか?

シグネチャフィッシングは、攻撃者が被害者を騙して特定のメッセージに署名させ、資産を制御させることで発生します。従来の攻撃では、悪意のある契約や取引の実行が含まれていましたが、Permitの時代には、悪意のある署名の承認が1つあれば資金が枯渇します。これらの攻撃の一般的な展開は次のとおりです。

1. 被害者は、よく知られたDEXウェブサイトの偽バージョン（フィッシングサイト）をクリックします。ユーザーが相互作用しようとすると、サイトは「ログイン確認」などの他のように合法的な目的であると主張してウォレット署名リクエストを促します。しかし、このリクエストは実際にはPermit2認可署名であり、攻撃者の契約に被害者のUSDCを引き出すための無制限の許可を与えるもので、有効期限が延長されています。
2. 被害者は警戒心を欠いて、直接リクエストにサインします。この時点ではガス料金は発生せず、オンチェーン上のアクティビティも発生せず、怪しい痕跡も残りません。
3. 攻撃者は署名を取得すると、すぐに Permit2 コントラクトの permit() 関数を呼び出して署名を送信します。Permit2 コントラクトは、署名を検証した後、攻撃者のコントラクトの承認を被害者のアドレスに記録します (被害者が承認を実行するのと同じですが、攻撃者によって完了されます)。この操作は、被害者のウォレットには支出が表示されず、トークン許容量のマッピングのみがブロックチェーン上で更新されるため、被害者に気付かれない可能性があります。
4. その後、攻撃者はすぐに自分のアドレスからtransferFrom(victim, attacker_address, amount)トランザクションを開始し、最近のPermit2認可を使用して被害者のUSDCを成功裏に転送します。被害者は盗難に気付いたのは手遅れになってからです。

これらの攻撃では、ユーザーは明らかな「送金」や「承認」取引を実行することはありませんが、資産は不思議なことに消えてしまいます。鍵となるのは、署名自体が承認になることにあります。攻撃者は、署名要求を慎重に偽装して通常の操作に見せかけ、ユーザーの警戒心を弱めます。しかし、いったん署名すると、資産の鍵を渡すようなものです。

さらに悪いことに、一部の攻撃者はステルスを高めるために技術的手法を利用しています。たとえば、彼らはイーサリアムのCREATE2メカニズムを使用して、各被害者ごとに固有の悪意のある契約アドレスを生成します。これにより、各攻撃が異なるアドレスを使用するため、従来のブラックリストは無効になります。

最近の暗号通貨詐欺事件のほとんどは署名認証に関係しています。たとえば、Scam Sniffer’s統計学2024年初頭からのデータによると、わずか1か月で署名フィッシングを通じて5,500万ドル以上の資産が盗まれました。Permit2の有効化以降、攻撃者はユーザーにPermit/Permit2の承認に署名させることに積極的になり、短期間で多くの被害者を出しています。署名承認が悪用されると、甚大な被害をもたらし、検出が困難になります。

なぜ署名ベースのフィッシングリスクは従来の方法よりも高いのですか？

従来の悪意のある承認は、ユーザーにオンチェーン取引を実行するよう求め、ウォレットは通常、「XXXがあなたのトークンを使用することを許可しています」という明確な警告を表示し、ガス手数料が必要です。経験豊富なユーザーはこれについてより慎重です。しかし、ウォレットインターフェースでの署名リクエストは、しばしば単に「データ署名リクエスト」として説明され、金融取引ではないことが原因で、ユーザーは警戒心を弱めます。さらに、署名にガスがかからないため、攻撃者は経費を気にすることなく大規模なフィッシング試みを行うことができます。成功した試みがわずかでも、彼らは利益を得ます。

さらに、さまざまなウォレットがさまざまな方法でEIP-712メッセージを表示します。いくつかの最新の財布(最新のメタマスク）フィールドを解析して表示し、 「X量のトークンを使用するために契約を承認します」というようなメッセージを明確に表示します。 しかし、多くのウォレットは16進データや単純な説明のみを表示するため、平均ユーザーが信頼性を検証するのが難しい状況です。 攻撃者は、メッセージに欺瞞的な説明を埋め込むことでこれを悪用し（NFTミント署名であるかのように偽装するなど）、ユーザーを署名させるように誘導します。

署名承認が資産に直ちに影響を与えないため、被害者はすぐに脅威に気づかない可能性があります。 攻撃者は戦略的に攻撃のタイミングを計画することができます。 即座に実行するのではなく、被害者のウォレットがより多くの資産を含むか、または特定の時点まで待つかもしれません。これにより、追跡の努力が複雑化します。 有効期間の長い署名を持つことで、攻撃者は価格の変動を利用して利益を最大化することができ、実質的に無料の取引オプションを与えられます。 このリスクから、許可署名は通常、短い締め切りを強制します。

Permit2の1つの署名で複数のトークンを認可する能力は、ユーザーがその影響を十分に理解するのが特に難しいです。例えば、フィッシングサイトが1つまたは2つのトークンの権限を強調しながら、実際には同じ署名内に追加のトークンの広範な認可を秘密裏に埋め込む可能性があります。ウォレットが全ての詳細を明確に表示しない場合、ユーザーはこれらの隠れた権限を見落とすことが容易です。さらに、攻撃者はしばしば「WalletGuard」のような欺瞞的な契約名を使用し、トークンの権限を盗むために設計された悪意のある契約を隠匿します。

シグネチャ攻撃からユーザーを守るには?

署名は同意を意味することを覚えておくこと—ガス料金の不在があなたを不注意にさせることは決してありません。ウォレットが署名を要求するとき、メッセージの詳細を熟読してください。署名を要求しているウェブサイトやDAppが正当であり、メッセージの内容が意図した行動に合致していることを確認してください。たとえば、ウェブサイトに単にログインする場合、署名には可読性のあるログインテキスト（ほとんどのDAppが使用）が含まれているべきであり、トークンアドレスや数字の列ではありません。

ウォレットソフトウェアがEIP-712データ表示をサポートしていることを確認してください。MetaMaskなどの主要なウォレットTrustWallet、そしてLedger Liveシグネチャーコンテンツの表示エクスペリエンスを改善しています。たとえば、MetaMaskは一般的な権限メッセージを平易な言語に解析できるようになりました。ウォレットの署名時に長い16進数データしか表示されない場合は、切り替えまたは更新を検討してください。また、ハードウェアウォレットのユーザーは、新しいフォーマットをサポートするためにファームウェアを最新の状態に保つ必要があり、そうしないと、画面に情報が正しく表示されない可能性があります。

Permit signatures と Permit2 のどちらを使用する場合でも、通常は認証パラメータを調整できます。どうしても必要でない限り、無制限の金額 (値 = 2^256-1) に署名しないでください - 代わりに、必要な金額と小さなバッファーのみを承認します。また、期限を先に設定しすぎないようにしましょう。これにより、署名が悪意のある人の手に渡った場合でも、潜在的な損失は制限され、署名は最終的に期限切れになります。

Revoke.cash、Etherscan Token Approval、ウォレットの組み込み機能などのツールを使用して、アドレスの認証ステータスを定期的に確認する習慣を身に付けましょう。これには、従来の承認と Permit2 の手当の両方が含まれます。不審な権限や不要な権限を見つけた場合は、すぐに取り消してください。Permit2 の場合、失効の 2 つのレベルに注意してください: まず、マスター承認 (Permit2 コントラクト自体に対する承認で、使用しないときは 0 に設定することができます)。第二に、サブオーソリゼーション(Permit2が様々なDAppsに与えるもので、通常は自動的に期限切れになりますが、有効期間が長い場合は早期に終了することができます)。不審な許可証に署名した疑いがある場合、最も安全なアクションは、ナンスをすぐに調整することです:同じ送信者に新しい許可証に署名して(許容量が0であっても)、攻撃者が所有している古い署名を無効にします。

見慣れないウェブサイトを訪れるか、アプリケーションをダウンロードする際は常に注意してください。特に、ソーシャルメディア広告やプライベートメッセージを通じて共有される「プロモーションオファー」や「ミントイベント」などの未知のリンクをクリックしないでください。多くのフィッシング試行は、詐欺アクティビティリンクを投稿する偽の公式アカウントを通じて行われ、署名リクエストにつながります。偽のウェブサイトに気づかないようにするために、公式DAppのURLを直接入力する習慣を身につけるか、ブックマークを使用してください。

結論として、便利さとセキュリティのバランスを保つことが重要です。許可技術は便利ですが、ユーザーはリスク予防に注意を払い続ける必要があります。エコシステムが成熟するにつれて、ウォレット製品やブラウザプラグインは、大きな金額を含む署名に関する警告など、署名フィッシングに対する保護を開発しています。我々は将来、技術的および教育的な強化を通じてこのような攻撃を緩和することを目指しています。

結論

従来のERC-20認証モデルの限界からPermitの誕生、そしてUniswapの革新的なPermit2まで、イーサリアムエコシステムのユーザーエクスペリエンスとセキュリティを向上させるための取り組みを目の当たりにしてきました。Permit2は、オフチェーン署名によるトークン認証プロセスを大幅に簡素化し、承認の繰り返しや無制限の権限のリスクを軽減すると同時に、有効期限メカニズムやバッチ操作などの便利な機能を導入します。しかし、これらの新しいメカニズムには新たな責任が伴い、ユーザーはセキュリティ意識を高める必要があり、ウォレットとDAppsは連携してユーザーを署名攻撃から保護する必要があります。今後、アカウントの抽象化などのさらなる技術開発により、トークン認証管理はよりシームレスで安全なものになると予想されます。