Permit関数（EIP-2612）

Permit関数（EIP-2612）とは？

EIP-2612で定義されるPermit関数は、ERC-20トークンの拡張機能です。トークン保有者は、別途オンチェーンで承認トランザクションを送信する代わりに、オフチェーンメッセージに署名することで、使用者（spender）にトークン使用を許可できます。暗号資産の分野で重要なのは、トークン承認をよりスムーズかつ低コストにし、他のスマートコントラクト操作と簡単に組み合わせられる点です。

公式のEIP-2612仕様では、この規格によりERC-20に

という新しい関数が追加されると説明されています。この関数は、を介さず、署名付きメッセージによってallowanceマッピングを変更します。

簡単に言えば、EIP-2612を使うと、ユーザーはウォレットでメッセージに署名して「このスマートコントラクトに、私のトークンをこの数量まで使用することを許可します」と伝えられます。その後、別のアカウントやコントラクトが、その承認署名をオンチェーンに送信できます。つまり、トークン保有者自身が承認トランザクションを送信する必要はありません。また、ERC-20トークンの使用を承認するだけなら、トークン保有者がチェーンのネイティブガストークンを保有する必要がない場合もあります。Permit関数自体はトークンを送金しません。

allowanceを設定するだけであり、その後、

や承認済みallowanceを使用する別のコントラクト処理によって利用できます。

この違いは非常に重要です。使用者への承認は、その使用者にトークンを送ることと同じではありません。permitは、署名が送信された後にオンチェーン上のERC-20 allowance状態を更新する、署名付きの承認として理解するのが適切です。

Permit関数の主なポイント

• EIP-2612はERC-20トークンに
  permit
  、
  nonces
  、
  DOMAIN_SEPARATOR
  を追加します。
• Permit関数を使うと、オフチェーン署名でERC-20の使用を承認できます。
• 署名付きメッセージは、EIP-712の型付き構造化データのルールに従います。
• permitはallowanceを変更しますが、それ自体でトークンを送金することはありません。
• nonceにより、同じpermit署名の再利用を防ぎます。
• 有効期限により、署名付きpermitが有効な期間を制限します。
• Permitはユーザー体験を改善しますが、承認に伴うリスクや署名フィッシングのリスクをなくすものではありません。

EIP-2612が作られた理由

ERC-20トークンでは、あるアドレスが別のアドレスに対し、自分に代わってトークンを使用することを許可できる承認モデルが採用されています。

元となるERC-20規格では、

、、などの関数が定義されています。

この承認モデルによって、ウォレット、スマートコントラクト、決済システム、取引インターフェース、レンディングプロトコル、ステーキングコントラクトなど、さまざまな分散型アプリケーションでトークンを利用できるようになりました。ただし、通常のERC-20承認フローでは、オンチェーントランザクションが2回必要になることがよくあります。

1回目は

トランザクションです。

2回目は、承認済みトークンを使用する実際のスマートコントラクト操作です。そのため、ユーザーはガス代を2回支払い、2回の承認を待ち、ウォレットに表示される2つの異なる確認画面を理解する必要があり、手間がかかります。ERC-20トークンは保有していても、承認トランザクションの送信に必要なネイティブガストークンを持っていないユーザーにとっても問題となります。EIP-2612は、署名付きメッセージによる承認を可能にし、この問題を解決します。トークン保有者がオフチェーンでpermitに署名し、別の当事者がそれをオンチェーンに送信できます。これにより、スマートコントラクトの処理で承認と操作をより効率的に組み合わせられます。たとえば、ユーザーがpermitに署名し、コントラクトがそのpermitを使用してトークンを移動させるまでを、1回のトランザクションフローにまとめられます。ただし、ネットワーク上のトランザクションが無料になるわけではありません。permitをオンチェーンに送信するためのガス代は、引き続き誰かが支払う必要があります。メリットは、ガス代を支払う人がトークン保有者でなくてもよいことです。

Permit関数の仕組み

EIP-2612の中核となる関数の形式は次のとおりです。

。

は承認に署名するトークン保有者です。

はallowanceを受け取るアドレスです。

は使用を承認するトークン数量です。

はpermitを使用できる最終時刻です。

、、は暗号署名を構成する値です。

permitが送信されると、トークンコントラクトは署名が有効かどうかを確認します。また、有効期限を過ぎていないかも確認します。署名付きメッセージで使用されたnonceが、ownerの現在のnonceと一致するかも確認します。

必要な確認がすべて通ると、コントラクトは

に承認済みの値を設定します。

その後、同じ署名を再利用できないよう、コントラクトはownerのnonceを増加させます。

さらに、ERC-20の承認に関する想定動作に沿うよう、

イベントを発行します。

この処理により、ウォレット署名がオンチェーンのallowance更新に変わります。

EIP-2612の3つの主な関数

EIP-2612に準拠するトークンは、ERC-20に加えて3つの関数を実装する必要があります。

1つ目は

です。

関数は署名付き承認を検証し、allowanceを更新します。

2つ目は

です。

関数は、ownerアドレスの現在のnonceを返します。

3つ目は

です。

関数は、署名を特定のトークンコントラクトと署名ドメインに結び付けるために使われるEIP-712のドメインセパレーターを返します。

この3つの関数は連携して動作します。permit署名が承認内容を定義します。nonceがリプレイを防ぎます。ドメインセパレーターが、署名を正しいコントラクトとチェーンのコンテキストに結び付けます。これらの要素がなければ、permit署名は誤用や不適切な環境でのリプレイが容易になります。

Allowanceとは？

allowanceとは、ownerがspenderに使用を許可したERC-20トークンの数量です。たとえば、Aliceがスマートコントラクトに100トークンの使用を許可すると、Aliceからそのスマートコントラクトへのallowanceは100トークンになります。

その後、トークンコントラクトやアプリケーションの処理に応じて、spenderは

を呼び出し、承認された数量を上限にトークンを移動できます。

Permit関数はallowanceの仕組みをなくすものではありません。allowanceの設定方法を変えるものです。

トークン保有者が直接

を呼び出す代わりに、EIP-2612ではallowanceの更新を許可するメッセージに署名できます。

これにより、使い勝手を改善しながら、従来のERC-20 allowanceモデルとの互換性を保てます。承認されたspenderは許可された数量の範囲でトークンを移動できる場合があるため、ユーザーは引き続きallowanceを慎重に扱う必要があります。無制限のpermit承認は便利な場合がありますが、spenderのコントラクトが悪意あるもの、侵害されたもの、または誤解されたものであれば、大きな損失につながる可能性があります。

Permit関数とApprove関数の違い

従来の

関数は、トークン保有者がオンチェーントランザクションで直接呼び出します。

Permit関数では、トークン保有者がオフチェーンで署名して承認し、その後、別の当事者がオンチェーンに送信します。

では、承認トランザクションのガス代をトークン保有者が支払う必要があります。

では、トークン保有者はメッセージに署名し、リレイヤー、アプリケーション、またはspenderが送信時のガス代を支払えます。

では、承認操作は直ちにに結び付きます。

では、承認操作はownerの検証済み署名に結び付きます。

allowanceの更新結果は同じでも、ユーザー体験は異なります。この違いから、EIP-2612は「ガスレス承認」を可能にすると説明されることがよくあります。より正確には、トークン保有者自身が承認トランザクションを送信せずに承認できる仕組みです。ブロックチェーン上の状態を更新するには、引き続きトランザクションとガス代が必要です。

PermitにおけるEIP-712の重要性

EIP-2612は、EIP-712に基づく型付き構造化データを使用します。

EIP-712は、内容が不透明なバイト列ではなく、構造化データをハッシュ化して署名するための規格です。これは、ウォレットのユーザーが署名内容を理解する必要があるため重要です。生の16進数による署名要求は、分かりにくく危険な場合があります。型付き署名なら、owner、spender、value、nonce、deadlineなどの項目をより明確に表示できます。EIP-712ではドメインセパレーターも使用します。ドメインセパレーターは、ある署名コンテキストを別のコンテキストから区別するのに役立ちます。EIP-2612では通常、トークン名、バージョン、チェーンID、検証対象コントラクトのアドレスなどが含まれます。この設計により、あるトークンやチェーン向けの署名が別のコンテキストで有効になるリスクを抑えます。EIP-712自体には、リプレイ保護が含まれていないと明記されています。EIP-2612は、ownerごとのnonceによってリプレイ保護を追加します。

Nonceとリプレイ保護

nonceとは、一度だけ使用される数値です。EIP-2612では、トークンコントラクトがownerアドレスごとにnonceを管理します。ユーザーがpermitに署名すると、署名データにownerの現在のnonceが含まれます。permitが正常に使用されると、トークンコントラクトはそのnonceを増加させます。同じpermitを再度送信しようとしても、nonceが一致しなくなります。そのため、再利用された署名は失敗します。署名はコピーできるため、nonceによる保護は不可欠です。nonce保護がなければ、spenderや攻撃者が同じ署名付きpermitを何度も再利用する可能性があります。適切なpermit実装ではnonceを署名付きメッセージの一部として扱い、permitが成功した場合にのみ更新する必要があります。ユーザーにとっての実際の意味はシンプルです。有効なpermit署名は一度だけ使用できるべきであり、永久に使えるものではありません。

有効期限と署名の失効

パラメーターは、permit署名を使用できる期間を制限します。

現在のブロックタイムスタンプがdeadlineを過ぎていれば、permitは失敗する必要があります。これにより、本来の使用予定時期を大幅に過ぎてから古い署名が送信されるのを防げます。有効期限が短ければ、送信可能な時間を制限できるため、リスクを抑えられる場合があります。有効期限が長ければ、署名をより長く利用できるため利便性が高まります。無期限または極端に長い有効期限は、署名付き承認が長期間有効なままになる可能性があるため危険です。署名が使用、無効化、またはnonceの仕組みによって置き換えられない限り、有効性が続く場合があります。ウォレットに型付きpermitデータが表示されたら、ユーザーは有効期限に注意する必要があります。明確な理由がない限り、開発者は過度に長い有効期限を設定しないようにしてください。アプリケーションは、有効期限の意味をユーザーが理解できる形で説明する必要があります。

ドメインセパレーターとチェーンのコンテキスト

ドメインセパレーターは、EIP-712署名の重要な要素です。EIP-2612では、permitを特定のトークンコントラクトとドメインに結び付けるのに役立ちます。一般的なドメインには、トークン名、トークンのバージョン、チェーンID、検証対象コントラクトのアドレスが含まれます。これにより、あるコントラクト向けのpermitが別のコントラクトでリプレイされるリスクを抑えます。また、あるチェーンで署名されたpermitが別のチェーンで再利用されるリスクも低減します。ただし、ドメインセパレーターの安全性は、正しく実装されていることが前提です。トークンコントラクトで不完全なドメインセパレーターが使われていると、リプレイのリスクが高まる可能性があります。チェーンIDが変更された場合や、複数のネットワークにコントラクトをデプロイする場合、開発者は署名をどのように分離するか慎重に検討する必要があります。ユーザーの画面では、通常ドメインセパレーターは表示されません。開発者にとっては、安全なpermit実装における最重要項目の一つです。

ガスレス承認の仕組み

「ガスレス承認」という表現は誤解を招く場合があります。EIP-2612によってEthereumやEVM上のトランザクションが無料になるわけではありません。トークン保有者がトランザクションを送信する代わりに、メッセージに署名して使用を承認できる仕組みです。その後、リレイヤー、アプリケーション、スマートコントラクト、またはspenderが署名付きpermitをオンチェーンに送信し、ガス代を支払えます。この仕組みは、ERC-20トークンを保有していても、承認に必要なネイティブガストークンが不足しているユーザーに役立つ可能性があります。アプリケーションが、よりスムーズな1ステップの体験を提供するのにも役立ちます。たとえば、ユーザーはpermitに署名した後、別途承認トランザクションを手動で送信することなく、入金、決済、またはトークン操作を完了できる場合があります。ユーザー体験は簡単になりますが、状態変更は引き続きオンチェーントランザクションによってブロックチェーンに記録されます。署名付きメッセージにも影響があることをユーザーが誤解しないよう、開発者はこの点を明確に説明する必要があります。permit署名は、誰かが送信すると実際にオンチェーン上の結果をもたらす可能性があります。

EIP-2612の一般的な暗号資産関連ユースケース

EIP-2612は、分散型金融やトークンを利用するアプリケーションでよく使われます。レンディングプロトコルでは、permitを使ってユーザーが担保を承認し、1つのフローで預け入れられるようにする場合があります。ステーキングコントラクトでは、別個の承認トランザクションを送信せずに、ユーザーがステーキングトークンの使用を承認できる場合があります。決済アプリケーションでは、よりスムーズなチェックアウト処理でトークンの移動を許可するためにpermitを利用できます。ウォレットでは、一般的なERC-20操作のトランザクション手順を減らすためにpermitを使う場合があります。リレイヤーサービスは、ユーザーに代わってガス代を支払い、別の方法で費用を回収するためにpermitを利用する場合があります。

スマートコントラクトはpermitを

と組み合わせ、同じトランザクションフローで承認とトークン移動を行えます。

この方式では、主要な操作の前に承認を別途マイニングする必要がないため、ユーザーの操作が途中で失敗する可能性を減らせます。また、アプリケーションが1つの統合された手順でユーザーを案内できるため、混乱を減らせる場合があります。主なメリットは、ガス代の節約だけではありません。トークン承認に伴う手間を減らせることも大きなメリットです。

Permit関数とアカウント抽象化

Permit関数とアカウント抽象化は、どちらもウォレットのユーザー体験を改善するため、関連付けて説明されることがあります。Permitは署名を通じて、ERC-20トークン保有者がallowanceの変更を承認できるようにします。アカウント抽象化は、暗号資産アカウントをよりプログラム可能で柔軟にすることを目指しています。両者は異なる仕組みですが、目標には共通点があります。どちらもブロックチェーン操作の手間を減らそうとするものです。Permitはトークン承認に焦点を当てています。アカウント抽象化は、より広い範囲でアカウントが操作を承認し、手数料を支払う仕組みに焦点を当てています。暗号資産アプリケーションでは、両方の仕組みを同じ製品設計で利用できます。たとえば、ウォレットやスマートアカウントシステムが、トランザクションのスポンサー機能とpermit対応のトークン承認の両方をサポートする場合があります。ユーザーがすべての技術レイヤーを理解する必要はありませんが、開発者は各レイヤーを正しく実装する必要があります。

Permit関数のセキュリティリスク

ユーザーにとって最大のリスクは、署名フィッシングです。悪意あるウェブサイトが、危険なspenderへの承認を許可するpermitへの署名をユーザーに求める可能性があります。permit署名は通常のトークン送金ではないため、一部のユーザーは無害だと思うかもしれません。これは危険な思い込みです。permitによって、spenderは後からトークンを移動する権限を得られる場合があります。署名する前に、spenderのアドレス、トークン数量、トークン名、有効期限を確認してください。内容が不明瞭、予期しない、または見知らぬウェブサイトから求められた署名は拒否してください。もう一つのリスクは、無制限承認です。非常に大きなvalueを指定したpermitに署名すると、spenderにそのトークンのallowanceを広範に使用する権限を与える可能性があります。3つ目のリスクは、不適切な実装です。トークンコントラクトがnonce、ドメイン分離、署名の復元、有効期限を正しく処理しない場合、署名がリプレイされたり、本来失敗すべき署名が受け入れられたりする可能性があります。4つ目のリスクは、ユーザーインターフェースの分かりにくさです。ウォレットが型付きデータを明確に表示しないと、ユーザーは理解していない承認に署名する可能性があります。Permitによって使いやすさは向上しますが、署名に関する理解を促すこともより重要になります。

Permitでも承認リスクはなくならない

EIP-2612は承認の方法を変えますが、spenderを承認することに伴う基本的なリスクは変わりません。spenderが悪意あるもの、侵害されたもの、または過剰なallowanceを与えられた場合、ユーザーは引き続きトークンを失う可能性があります。

permit承認は、通常の

トランザクションと同等の権限を持つ場合があります。

違いは、トークン保有者からのトランザクションではなく、署名から承認が始まることです。そのため、ユーザーはpermit署名も承認トランザクションと同じように慎重に扱う必要があります。spenderを完全に信頼し、リスクを理解しているのでなければ、無制限permitへの署名は避けてください。不要になったallowanceは取り消してください。リスクの高いdAppとのやり取りには別のウォレットを使い、長期保有資産とは分けて管理してください。価値の高いトークンへのアクセスを承認する前に、信頼できる情報源を通じてコントラクトアドレスを確認してください。

Permitとフロントランニング

permit署名を持つ人は誰でも、その署名を送信できます。そのため、フロントランニングに関する特有の注意点があります。ユーザーがpermitに署名してアプリケーションに送信すると、その署名を見た別の当事者が先にpermitを送信する可能性があります。多くの場合、permitが消費され、ユーザーが意図したものと同じallowanceが設定されるだけです。ただし、アプリケーションがpermitの実行と別の操作を同時に行う想定の場合、別の当事者がpermitを先に実行するとnonceがすでに変わっているため、後続の統合トランザクションが失敗する可能性があります。開発者は、このケースを適切に処理できるフローを設計する必要があります。スマートコントラクトでは、期待されるallowanceがすでに利用可能かを確認し、不必要な失敗を避けて処理を続行できる場合があります。ユーザーインターフェースでも、permitフローが失敗した際に理由を明確に説明する必要があります。ユーザーにとって重要なのは、署名付きpermitは使用されるか期限切れになるまで、他者に送信できる状態にあるということです。信頼できるフローでない限り、署名済みpermitデータを共有しないでください。

開発者向けの実装上の注意点

開発者はEIP-2612仕様に厳密に従う必要があります。permitの型ハッシュは、想定される署名構造と一致していなければなりません。ダイジェストはドメインセパレーターとpermit構造体のハッシュを使ったEIP-712エンコーディングに従う必要があります。コントラクトは期限切れのpermitを拒否する必要があります。無効な署名を拒否する必要があります。復元された署名者がownerでないpermitを拒否する必要があります。不適切なゼロアドレスのownerを拒否する必要があります。permitの実行成功後にownerのnonceを増加させる必要があります。

allowanceの変更後、標準の

イベントを発行する必要があります。

可能な場合は、十分にレビューされたライブラリを使用してください。

OpenZeppelinのERC20Permitドキュメントでは、Solidityプロジェクトで広く使われる実装パターンが紹介されています。

OpenZeppelinは、Stylus向けERC-20 Permitなど、他の環境でのERC-20 Permitの利用方法も説明しています。

ライブラリを使う場合でも、開発者は対象トークンの動作を慎重にテストする必要があります。

Permit関数とメタトランザクション

メタトランザクションとは、ユーザーがメッセージに署名し、別の当事者がユーザーに代わってトランザクションを送信する、より広範な仕組みです。EIP-2612は、承認に特化した署名方式と捉えることができます。すべてのトークン操作を署名付き操作に一般化するものではありません。ERC-20 allowanceの署名付き承認を標準化するものです。この対象範囲を限定した設計は意図的なものです。最小限の規格は、ウォレット、コントラクト、アプリケーションで採用しやすく、統合もしやすくなります。署名付き送金、操作の一括実行、独自のガス代スポンサー機能を実現したい開発者は、追加のコントラクトや規格が必要になる場合があります。Permitは、ERC-20の仕組み全体を変えずに一般的な問題を解決するため、有用です。すべてのメタトランザクションシステムに取って代わるのではなく、それらを補完します。

Permit関数とトークン送金の違い

permitは送金ではありません。送金は、あるアドレスから別のアドレスへトークンを移動します。permitは、あるアドレスが別のアドレスに与えるallowanceを更新します。つまり、ユーザーがpermitに署名しても、spenderがallowanceを使用するまではトークンを同じウォレットに保有できます。

実際のトークン移動は、通常

によって行われます。

この違いはウォレットの安全性に関わります。permitに署名した直後でも、ウォレットのトークン残高が変わらない場合があります。だからといって、署名が無害とは限りません。spenderは後からトークンを移動する権限を持っている場合があります。dAppを利用した後は、有効なallowanceを確認し、不要になった承認を取り消してください。

Permit関数とPermit2の違い

EIP-2612はトークンレベルの規格です。トークンがEIP-2612をサポートするには、トークンコントラクト自体にpermit関数が実装されている必要があります。他の承認システムでは、外部コントラクトを通じてpermitに似た機能を提供する場合があります。こうしたシステムは、ネイティブなEIP-2612サポートと同じではありません。ウォレットの確認画面、spenderのアドレス、nonceの仕組み、承認範囲、取り消し方法が異なる場合があるため、この違いは重要です。permitに似た承認に署名するときは、どのコントラクトに権限を与えるのかを確認してください。開発者がpermitを統合する際は、対象トークンがEIP-2612を直接サポートしているのか、別の承認方法が必要なのかを確認してください。署名付き承認をすべて「EIP-2612」と呼ぶと、混乱を招く可能性があります。EIP-2612には、固有のインターフェースと署名構造があります。

ユーザーがpermit署名の確認画面で確認すべきこと

まずトークン名を確認してください。次に、spenderのアドレス、または権限を求めているアプリケーションを確認してください。承認する数量を確認してください。数量が制限されているのか、実質的に無制限なのかを確認してください。有効期限を確認してください。意図した操作を行った後に表示された要求かどうか確認してください。予期せず表示された場合は、要求を拒否してください。ウェブサイトが連続して多数の署名を求める場合は、特に慎重になってください。ダイレクトメッセージ、偽のサポートチャット、不審な広告、見知らぬトークンページのリンクから署名を求められた場合は、署名を避けてください。permitへの署名によって、別のアドレスにトークンを使用する権限を与える可能性があることを覚えておいてください。安全なウォレットの確認画面では、これらの項目が読みやすく表示されるべきですが、ユーザーはインターフェースの設計だけに頼るべきではありません。

Permitがユーザー体験を改善する理由

Permitは、必要なオンチェーントランザクションの回数を減らし、ユーザー体験を改善します。多くのdAppフローで、独立した承認手順を省けます。単独の承認に必要なネイティブガストークンを十分に保有していないユーザーでも、ERC-20トークンを利用できるようにする場合があります。アプリケーションによるガス代のスポンサーや、承認と別の操作の一括実行にも役立ちます。トークンを承認した後、2回目のトランザクションを忘れることによって操作が完了しないケースを減らせる場合があります。オンチェーンアプリケーションに慣れていないユーザーのオンボーディングを円滑にすることもできます。ERC-20の承認は暗号資産でよくある手間の一つであるため、これらのメリットは特に重要です。ただし、承認がスムーズになっても、それだけで承認の安全性が高まるわけではありません。優れたユーザー体験には、分かりやすい署名画面、慎重なspender設計、簡単なallowance管理が必要です。

EIP-2612でよくある誤解

よくある誤解の一つは、permitによってトークンがすぐに送金されると思うことです。permitが更新するのはallowanceだけです。もう一つの誤解は、ガスレス承認なら誰もガス代を支払わないと思うことです。コントラクトの状態を更新するには、permitにもオンチェーントランザクションが必要です。3つ目は、spenderのリスクを理解せずに無制限承認へ署名することです。4つ目は、deadline項目を確認しないことです。5つ目は、通常のトランザクションに見えないという理由だけで署名要求を信頼することです。6つ目は、すべてのERC-20トークンがEIP-2612をサポートしていると思い込むことです。7つ目は、デプロイ先ごとのチェーンID、ドメインセパレーター、nonceの動作をテストせずにpermitを統合することです。8つ目は、permitに似た仕組みをすべてEIP-2612と同じものとして扱うことです。9つ目は、コントラクトで複数の処理を組み合わせる際、permitのフロントラン送信に対応しないことです。10個目は、ユーザーが理解できない形でpermitの確認画面を表示することです。

ユーザー向けのベストプラクティス

信頼できるウェブサイトやアプリでのみpermitメッセージに署名してください。署名する前に、トークン、spender、数量、有効期限を確認してください。十分な理由がない限り、無制限承認は避けてください。可能であれば、少額の承認を利用してください。不要になった古いallowanceは取り消してください。無作為なリンク、偽のサポートメッセージ、見知らぬエアドロップページからのpermitメッセージには署名しないでください。実験的なdApp用と長期保有用に、別々のウォレットを使用してください。ウォレットの警告を注意深く確認してください。ガス代が直接表示されないからといって、署名が安全だと思い込まないでください。署名付きpermitは、有効期限が切れる前に別の人が後から送信できることを覚えておいてください。

開発者向けのベストプラクティス

可能であれば、監査済みで適切に保守されているpermit実装を使用してください。EIP-2612対応をうたう場合は、公式のEIP-2612インターフェースに厳密に従ってください。ウォレットに署名情報を明確に表示できるよう、EIP-712の型付きデータを使用してください。ドメイン分離を正しく実装してください。ownerアドレスごとにnonceを管理してください。期限切れの署名を拒否してください。無効な署名者やゼロアドレスのownerを拒否してください。

allowanceの更新が成功した後に

イベントを発行してください。

主要なトランザクションより先にpermitが送信されても処理を継続できるよう、permitを組み合わせたフローを設計してください。spender名、トークン数量、有効期限を分かりやすい言葉でユーザーに表示してください。ユーザーがallowanceを取り消す方法について、分かりやすい説明を用意してください。チェーンID、フォーク、アップグレード、ウォレットプロバイダーをまたいで署名をテストしてください。

Permit関数を一文で説明すると

EIP-2612のPermit関数は、ERC-20トークン保有者がEIP-712署名でspenderに使用を承認し、保有者自身が別途承認トランザクションを送信することなく、オンチェーンでallowanceを更新できるようにします。

よくある質問

EIP-2612のPermit関数とは何ですか？

Permit関数はERC-20の拡張機能で、トークン保有者がオフチェーン署名でspenderに使用を承認し、その署名を後からオンチェーンに送信できる仕組みです。

permitはトークンを送金しますか？

いいえ。permitはallowanceを設定するだけで、それ自体がトークンを送金することはありません。

EIP-2612はなぜ便利なのですか？

EIP-2612は承認の手間を減らし、ガスレス承認の体験を可能にし、アプリケーションが承認を他のスマートコントラクト操作と組み合わせられるため便利です。

permitを使うとトークン保有者がガス代を支払いますか？

トークン保有者は承認トランザクションを送信する必要はありませんが、署名付きpermitをオンチェーンに送信する際のガス代は誰かが支払う必要があります。

approveとpermitの違いは何ですか？

approveはトークン保有者が送信するオンチェーントランザクションで、permitは別の当事者がオンチェーンに送信できるオフチェーン署名です。

EIP-712はpermitとどのような関係がありますか？

EIP-712は型付き構造化データへの署名を可能にします。これにより、ウォレットがpermitの詳細をより明確に表示でき、署名を定義されたドメインに結び付けられます。

EIP-2612のnonceとは何ですか？

nonceはownerごとに管理される値で、同じpermit署名の再利用を防ぎます。

permitのdeadlineとは何ですか？

deadlineはpermit署名が無効になる期限です。

EIP-2612は安全ですか？

EIP-2612は正しく実装・利用すれば安全な場合がありますが、署名フィッシング、無制限承認、悪意あるspender、分かりにくいウォレットの確認画面には引き続き注意が必要です。

すべてのERC-20トークンがpermitに対応していますか？

いいえ。EIP-2612拡張機能を実装したERC-20トークンのみが、標準のPermit関数に対応しています。

permit署名はフロントランされる可能性がありますか？

はい。有効なpermit署名を持つ人は誰でも別のトランザクションより先に送信できるため、開発者はこの可能性に対応できるフローを設計する必要があります。

ユーザーはpermitのリスクをどうすれば抑えられますか？

spenderを確認し、承認数量を制限し、有効期限を短く設定し、不審なウェブサイトを避け、不要なallowanceを取り消すことで、permitのリスクを抑えられます。

まとめ

EIP-2612のPermit関数は、ERC-20の承認体験を改善する特に有用な機能の一つです。別個の承認トランザクションではなく、署名によってトークンallowanceを承認できます。これにより、ガス代に関する手間を減らし、dAppの利用開始を円滑にし、トランザクションのスポンサーに対応し、ERC-20の操作を1つのユーザーフローにまとめやすくなります。この規格では、EIP-712の型付き構造化データ、ドメイン分離、nonce、有効期限を用いて、署名付き承認の安全性と適用範囲を高めています。ただし、permitによってトークンallowanceの基本的なリスクがなくなるわけではありません。署名付きpermitによって、spenderにユーザーのトークンを扱う実際の権限が与えられる場合があります。ユーザーはpermit署名を承認トランザクションと同じように慎重に扱う必要があります。開発者は規格を慎重に実装し、分かりやすい署名情報を表示するとともに、リプレイ保護、期限切れ署名、フロントランされたpermitの送信などの例外ケースに対応する必要があります。EIP-2612を正しく使えば、allowanceに基づくトークン使用という中核的な仕組みを変えずに、ERC-20トークンをより使いやすくできます。小規模ながら重要なこの規格は、より広範なERC-20エコシステムとの互換性を保ちながら、暗号資産アプリケーションの実用性を高めます。