EIP-2612: ERC-20がいかにしてガスレス承認を可能にするか

ガス料金はDeFiにおける最大の摩擦要因です。ERC-20トークンをスワップ、貸付、ステーキングする前に、dAppがトークンを移動できるようにするために、「承認（approve）」トランザクションを送信し、ガスを支払う必要があることがよくあります。EIP-2612はそれを変えます。これは、承認をオフチェーンに移し、スマートコントラクトやリレイヤーがオンチェーンでガスを負担できるようにする、署名ベースの承認フローである「パーミット（permit）」を導入します。その結果、正しく実装されれば、よりスムーズなUX、トランザクション数の削減、そしてより安全な承認が実現します。

この記事では、EIP-2612の仕組み、2025年においてなぜ重要なのか、そしてユーザーと開発者が注意すべき点について説明します。

EIP-2612とは何か

EIP-2612は、ERC-20トークン標準に新しい関数permitを追加して拡張します。オンチェーンでapprove(spender, amount)を呼び出す代わりに、ユーザーは承認パラメータと期日を含むタイプ化されたメッセージをオフチェーンで署名します。その後、スマートコントラクトは、その署名を使用してオンチェーンでpermitを送信し、ユーザーがガスを支払うことなく承認を設定します。

• ERC-20の基本: 承認と転送は、ERC-20仕様で定義された標準に従います。
• EIP-2612仕様: 署名フォーマット、ナンス（nonce）、permit関数は、EIP-2612提案で正式化されています。
• タイプ化データ: 署名は、EIP-712に従って構造化されたデータを使用し、署名する内容を人間が読める形式で、かつドメインにバインドします。

要するに、EIP-2612は「ガスレス承認」を可能にします。なぜなら、ユーザーはオフチェーンで署名するだけで、dApp、リレイヤー、またはコントラクトがpermitをオンチェーンにリレーするためのガスを支払うからです。

2025年においてなぜ重要なのか

• クリック数とトランザクション数の削減: 1つの署名で承認を設定し、単一のオンチェーン呼び出しでアクション（スワップ、デポジット、ステーキング）を即座に実行できます。
• L2ファーストUX: L2が隆盛する中、多くのプロトコルはユーザーオンボーディングのためにガスを負担しています。EIP-2612の承認は、それらのパターンにうまく適合します。コストダイナミクスを理解するために、ガスとアカウントモデルに関するEthereumの概要を参照してください。
• アカウント抽象化とペイマスター: ERC-4337によって強化されたウォレットフローは、サービスがガスを負担したり、トークンで手数料を受け取ったりすることを容易にします。EIP-2612はこれらのUX改善を補完します。署名によって承認し、トランザクションは負担される可能性があります。
• 将来を見据えたプロトコルの変更: EIP-3074やEIP-7702のようなウォレットネイティブな認証に関する議論は、署名駆動型オペレーションへのより広範なトレンドを浮き彫りにしています。それらが進化するとしても、EIP-2612は今日、承認のための実用的で広く展開されているツールであり続けます。

ガスレス承認の仕組み（ステップ・バイ・ステップ）

1. dAppでアクション（例：トークンのスワップ）を開始します。
2. dAppは、オーナー、名宛人（spender）、値（value）、ナンス（nonce）、期日（deadline）、トークンのドメインセパレーター（名前、バージョン、chainId、コントラクトアドレス）のフィールドを含むEIP-712タイプ化メッセージを準備します。
3. ウォレットでメッセージに署名し、正確なパラメータを承認します。
4. dAppまたはリレイヤーは、オンチェーンでpermit(owner, spender, value, deadline, v, r, s)を送信し、同じトランザクションで、承認を利用するdAppアクションを呼び出します。
5. トークンコントラクトは署名を検証し、ナンスと期日を確認してから、承認を設定します。

中心的な考え方：承認のためにガスを支払う必要はありません。署名するだけです。

ネイティブPermitとPermit2の違い

すべてのトークンがEIP-2612を実装しているわけではありません。インターフェースの断片化を解消し、安全性を向上させるために、UniswapはPermit2を導入しました。これは、トークン全体で署名承認と承認管理を標準化する汎用的な承認システムです。

• Permit2の概要と参照実装：Uniswap Permit2

トークンがネイティブなpermitをサポートしている場合、dAppはそれを直接使用できます。サポートしていない場合、Permit2は一貫したインターフェースを提供しつつ、Permit2コントラクトへの承認を制限し、多くの場合、制御と取り消しのUXを向上させます。

気を付けるべきセキュリティ上の考慮事項

ガスレスだからといってリスクレスではありません。署名は強力です。トランザクションのように扱ってください。

• 名宛人（Spender）の検証: どのコントラクトが承認を取得するかを常に確認してください。EIP-712タイプ化データには、名宛人のアドレスが明確に表示されるはずです。タイプ化データがどのように機能するかについては、EIP-712を参照してください。
• 金額の制限と適切な期日の設定: プロトコルを深く信頼していない限り、無制限の承認は避けてください。期日を設定することで、攻撃のウィンドウを減らすことができます。
• chainIdとドメインの確認: 署名は、ドメインセパレーターを介して、意図されたネットワークとトークンコントラクトに対してのみ有効です。クロスチェーンリプレイ攻撃やフィッシングに注意してください。
• ナンス（Nonce）の管理: EIP-2612は、リプレイを防ぐためにナンスを使用します。信頼できるトークン実装、理想的には監査済みで、OpenZeppelinのERC20Permitのようなよくテストされたライブラリを使用するものに依存してください。
• 承認の取り消し: ウォレットインターフェースで、またはトークンコントラクトを介して、使用していない承認を定期的に確認し、取り消してください。
• メタトランザクションの信頼: リレイヤーがあなたのpermitを送信する場合、dAppのバックエンドを信頼していることを確認してください。メタトランザクションパターンについては、EIP-2771（Trusted Forwarder）を参照してください。

優れた実装は問題の軽減に役立ちますが、ユーザーの注意深さが不可欠です。一般的なベストプラクティスについては、OpenZeppelinのドキュメントが確実な出発点となります。OpenZeppelin Contracts。

開発者向けノート：Permitの実装と使用

• 実績のある実装を使用する: OpenZeppelinのERC20Permitとdraft-EIP712は、ミスを減らし、仕様に沿った状態を維持します。参照：ERC20Permit。
• 実行をバンドルする: 1クリックUXのために、dAppをpermit署名を受け入れ、同じトランザクションでアクションを実行するように設計してください。
• 両方のフローをサポートする:ネイティブなpermitが利用可能な場合はそれを優先し、トークンにそれが欠けている場合はPermit2にフォールバックしてください。参照：Uniswap Permit2。
• 期日とナンスを堅牢に処理する: 無効な署名を拒否し、オンチェーンに送信する前に期待されるナンスを確認してください。
• スポンサーシップを検討する: EIP-2612とERC-4337のペイマスターを組み合わせて、真にシームレスでスポンサー付きのフローを作成してください。参照：ERC-4337。

よくある質問

• これは「無料」ですか？ ユーザーは承認のためにガスを支払いません。そのガスは誰か他の人が支払います。dAppはスマートコントラクトロジックを通じて手数料を請求する場合があります。
• トークンがEIP-2612をサポートしていない場合はどうなりますか？ Permit2を使用するか、明確なUXプロンプトを備えた標準のapproveフローにフォールバックしてください。
• Permitはチェーン間で機能しますか？ いいえ。署名はEIP-712によってドメイン（トークンコントラクト+chainId）にスコープされます。特定のネットワークに対して署名する必要があります。
• ハードウェアウォレットは互換性がありますか？ EIP-712タイプ化データをサポートするウォレットであれば、Permitメッセージを表示できます。優れたウォレットは、名宛人、金額、期日を明確に表示します。

最終的な考察

EIP-2612は、DeFiを瞬時に感じさせる、小さくも極めて重要な改善の1つです。承認を署名に変換することで、一般的なUXのハードルを取り除き、L2やアカウント抽象化における最新のフローと自然に連携します。

Permitベースのワークフローに依存している場合は、EIP-712メッセージを透過的に表示し、キーをオフラインに保つウォレットを選択してください。OneKeyハードウェアウォレットは、明確なオンデバイスEIP-712プレビュー（名宛人、金額、期日、チェーン）、オープンソースファームウェア、そして広範なEVM/L2サポートに重点を置いています。これは、署名の安全性に妥協することなく、ガスレス承認の利便性を求めている場合に役立ちます。