承認メカニズム

承認メカニズムとは？

承認メカニズムとは、ユーザーがスマートコントラクト、ウォレット、プロトコル、オペレーターに対し、ユーザーに代わって特定の操作を行う権限を付与できる暗号資産の権限管理システムです。

暗号資産に関する一般的な会話では、承認メカニズムは通常、スマートコントラクト型ブロックチェーンにおけるトークン承認を指します。

トークン承認を行うと、別のアドレス（多くの場合はスマートコントラクト）が、トークン規格で定められたルールの範囲内でユーザーのトークンを使用・管理できるようになります。

最も一般的な例はERC-20の承認システムです。トークン保有者はapprove()を呼び出し、spenderに対して、transferFrom()を通じて一定量のトークンを移動する権限を付与します。

公式のERC-20トークン規格では、トークンを承認し、オンチェーン上の第三者が使用できるようにする仕組みが定められています。

多くの暗号資産アプリケーションでは、ユーザーがアクセスを承認した後にのみトークンを移動する必要があるため、この仕組みが広く利用されています。

たとえば、レンディングアプリがユーザーのステーブルコインをプールに預け入れるには、事前の承認が必要な場合があります。

取引アプリがユーザーのトークンをスワップする場合も、事前に承認が必要になることがあります。

NFTマーケットプレイスでは、販売成立後にNFTを移転するための承認が必要になる場合があります。

ステーキングコントラクトでは、ステーキング対象のトークンをコントラクトに移す前に承認が必要になることがあります。

承認メカニズムの利点は、権限付与と実際の移転を分けられることです。

ユーザーは先に承認し、次の操作を完了した際に、アプリケーションが後から移転関数や管理関数を呼び出せます。

この設計は柔軟性を高めますが、暗号資産における最も重要なウォレットセキュリティリスクの一つにもつながります。

暗号資産で承認メカニズムが重要な理由

暗号資産のユーザーはスマートコントラクトと直接やり取りするため、承認メカニズムが重要です。

ユーザーがウォレットをアプリケーションに接続しても、通常、ユーザーがトランザクションに署名するか権限を付与しない限り、アプリケーションが独自にトークンを移動することはできません。

承認は、権限を付与する主な方法の一つです。

そのため、承認はDeFi、NFT、ゲーム、ステーキング、トークンスワップ、トークンブリッジ、決済など、多くのオンチェーン活動の中核を担っています。

承認メカニズムがなければ、多くの操作でユーザーがトークンを手動で送る必要があり、スマートコントラクトを使った処理は遅く、柔軟性も低くなります。

承認メカニズムを使えば、ユーザーは定められたAllowance（使用可能額）やオペレーター権限の範囲内でコントラクトに操作を許可できます。

利点は利便性です。

リスクは、悪意のあるspenderや侵害されたspenderが権限を悪用する可能性があることです。

ユーザーが悪意のあるコントラクトに無制限の承認を与えると、そのコントラクトが同種の承認済みトークンをすべて引き出せる可能性があります。

コレクション内のすべてのNFTを悪意のあるオペレーターに承認すると、そのオペレーターがNFTを移転できる可能性があります。

暗号資産ユーザーにとって、承認を理解することが最も重要なセキュリティスキルの一つであるのはこのためです。

承認メカニズムは、ウォレットのポップアップに隠れた技術的な詳細にとどまりません。

誰が資産を移動できるか、どれだけ移動できるか、コントラクトや秘密鍵が侵害された場合に何が起こり得るかを決めるものです。

ERC-20の承認の仕組み

ERC-20の承認は、3者の関係に基づいています。

1者目はトークンの所有者です。

2者目はspenderです。

3者目はERC-20トークンコントラクトです。

トークン所有者は、ウォレットアドレスにトークンを保有しています。

spenderとは、所有者がトークンの使用を許可したスマートコントラクトまたはアドレスです。

トークンコントラクトは、内部ストレージにAllowanceを記録します。

所有者がapprove(spender, amount)を呼び出すと、トークンコントラクトはspenderが所有者の残高から移動できるトークン数を更新します。

その後spenderがtransferFrom(owner, receiver, amount)を呼び出すと、トークンコントラクトはspenderに十分なAllowanceがあるかを確認します。

Allowanceが十分で、所有者の残高も足りていれば、移転が実行されます。

Allowanceが不足している場合、トランザクションは失敗するはずです。

OpenZeppelinのERC-20ドキュメントでは、Allowance関連の関数や、最新のトークン実装で使われるpermit拡張について説明されています。

この承認システムにより、ユーザーが権限を付与した後に限ってスマートコントラクトがトークンを移動できるため、強力な仕組みとなっています。

一方、古い承認は変更または取り消されるまで有効なままであることをユーザーが忘れやすく、リスクにもなります。

Allowance（使用可能額）

Allowanceとは、spenderが所有者のウォレットから移動できるトークンの数量です。

ERC-20トークンでは、Allowanceは通常、トークンコントラクト内のマッピングとして保存されます。

Allowanceを設定しても、所有者がトークンを送るわけではありません。

将来の移転に対する権限を付与するだけです。

この違いは重要です。ユーザーは、トークンがすぐに移動しない場合でも、大きなAllowanceを承認できます。

危険なのは、ユーザーがアプリケーションから離れた後も承認が有効なまま残る可能性があることです。

spenderコントラクトが後に悪用されたり、悪意を持ってアップグレードされたり、攻撃者に支配されたりした場合、残っているAllowanceが危険になる可能性があります。

Allowanceを少額にすれば、spenderが移動できる量を制限できます。

無制限のAllowanceを設定すると、トークンコントラクトで扱える最大の整数など、非常に大きな数量を移動する権限をspenderに与えることになります。

無制限のAllowanceは、承認トランザクションを繰り返す必要がなくなり、ユーザーの手間を省けるため、よく使われています。

ただし、現在の残高だけでなく将来のトークン残高も危険にさらす可能性があるため、無制限のAllowanceはリスクを高めます。

ウォレット上では単純なリクエストに見えても、そのセキュリティ上の意味は非常に大きい場合があります。

承認と移転の違い

承認は移転と同じではありません。

移転は、あるアドレスから別のアドレスへトークンを移動させます。

承認は、トークンコントラクト内の権限を変更します。

ユーザーがspenderを承認した時点では、通常、トークンはユーザーのウォレットに残っています。

トークン規格とコントラクトのロジックが許す場合、spenderは後から承認を利用してトークンを移動できます。

承認詐欺が分かりにくいのはこのためです。

ユーザーが承認に署名しても、その場ではトークンが移動しないことがあります。

その後、攻撃者がtransferFrom()を呼び出し、既存の承認を利用してトークンを移動する可能性があります。

盗難が後で発生したとしても、危険な操作は承認だったのです。

そのため、ユーザーは移転と同じ慎重さで承認を確認する必要があります。

ウォレットに「承認」と表示されている場合、将来の支出権限を付与している可能性があります。

最も安全な方法は、署名する前にspenderのアドレス、トークンのシンボル、Allowanceの数量、アプリケーションの利用状況を確認することです。

無制限の承認

無制限の承認とは、spenderに対してトークンの非常に大きな数量、または実質的に無制限の数量を移動する権限を与えることです。

承認を繰り返す必要がなくなるため、この設計は一般的です。

たとえば、同じアプリを頻繁に使うユーザーは、トランザクションごとに承認する代わりに、1回の無制限承認を選ぶ場合があります。

利便性が高まる一方で、長期間にわたるリスクにもつながります。

spenderに無制限の承認を与えると、ユーザーのウォレットにあるそのトークンの現在および将来の残高をすべて移動できる可能性があります。

ERC-20の無制限承認リスクに関する学術研究では、無制限承認が広く利用され、Ethereumエコシステムのユーザーに相応のリスクをもたらしていることが示されました。

主な問題は、無制限承認が常に損失を引き起こすことではありません。

ユーザーが承認を与えたことを忘れた後も、広範な権限が長期間残り続けることが問題です。

ユーザーは、コントラクトの内容、承認の理由、リスクを理解していない限り、無制限承認を避けるべきです。

信頼できるアプリケーションを利用する場合でも、必要な数量に承認を制限すれば、後で問題が発生した際の被害を抑えられる可能性があります。

限定承認

限定承認とは、特定の数量のトークンに限って権限を付与することです。

たとえば、次の操作に100トークンが必要な場合、ユーザーは100トークンを承認できます。

spenderは承認額を超えて移動できないため、リスクを軽減できます。

一般に、限定承認は無制限承認より安全です。

その代わり、次回以降の取引で再び承認が必要になる場合があります。

これにより、ガス代やウォレットでの追加確認が発生する可能性があります。

多くのユーザーにとって、セキュリティ向上のためなら追加の手順を踏む価値があります。

限定承認は、新規、未監査、実験段階、または使い慣れていないスマートコントラクトとやり取りする場合に特に有効です。

価値の高い資産を保有するウォレットを使う場合にも有効です。

一般的なベストプラクティスは、現在の操作に必要な数量だけを承認することです。

操作が完了した後、残っているAllowanceを取り消すこともできます。

承認の取り消し

承認の取り消しとは、spenderの権限をゼロに変更するか、オペレーターアクセスを削除することです。

これは暗号資産のセキュリティにおいて、特に重要な習慣の一つです。

Ethereum.orgのトークンアクセス取り消しガイドでは、無制限のトークンアクセスを避け、定期的にAllowanceへのアクセスを取り消すことが推奨されています。

取り消しによって通常、トークンが移動することはありません。

後からspenderがトークンを移動できるかどうかが変更されます。

ERC-20トークンの場合、取り消しは通常、Allowanceをゼロに設定する承認トランザクションを送信することで行います。

NFTの場合、特定のトークンへの承認を削除するか、コレクション全体に対するオペレーター承認を削除します。

承認の取り消しはオンチェーントランザクションであるため、ガス代がかかる場合があります。

ただし、危険な権限を残したままにすることで生じ得る損失と比べれば、そのコストは小さい可能性があります。

新しいアプリケーションを使った後、不審なトランザクションに署名した後、トークン配布に参加した後、または不慣れなウェブサイトに接続した後は、古い承認を確認してください。

取り消しは完全な防御策ではありませんが、攻撃者が利用できる未解除の権限を減らせます。

承認メカニズムとERC-2612 Permit

ERC-2612ではpermit()関数が追加され、ユーザーは直接オンチェーンでapprove()トランザクションを送らずに、署名メッセージでERC-20のAllowanceを変更できます。

公式のERC-2612 permit規格では、署名メッセージを使ってAllowanceのマッピングを変更できる仕組みが説明されています。

承認のためだけにネットワークのガストークンを保有する必要がなくなる場合があり、ユーザー体験の向上につながります。

別の当事者が署名済みpermitを送信し、ガス代を支払って承認手続きを完了することもできます。

手順を減らせるため、permit方式の承認は最新のDeFiで広く利用されています。

ただし、ユーザーが内容を十分に理解せず権限に署名する可能性があるため、ウォレットの設計には慎重さが求められます。

spenderに権限を与える署名は、トランザクションと同じくらい強力な場合があります。

オンチェーンでの移転がすぐに表示されないからといって、メッセージへの署名が無害だと考えてはいけません。

ウォレットに表示されるトークン、spender、数量、期限、チェーン、ドメインを確認してください。

悪意のあるpermit署名は、有効期限が切れる前にオンチェーンで送信されると、危険な承認を作成する可能性があります。

承認メカニズムとNFT

NFTの承認メカニズムは、ERC-20のAllowanceとは異なる仕組みです。

ERC-721では、特定のNFT 1点を移転するために、ユーザーが1つのアドレスを承認できます。

また、setApprovalForAll()を使って、コレクション内のすべてのNFTを管理するオペレーターを承認することもできます。

後者は強力な機能ですが、ユーザーが保有するコレクション内のすべてのNFTが対象となる可能性があるため、リスクも高くなります。

ERC-1155トークンでは、setApprovalForAll()によって、同じコントラクトに属するユーザーのすべてのトークンをオペレーターが管理できる場合があります。

公式のERC-1155マルチトークン規格では、setApprovalForAllによってオペレーターが承認者に代わって保有トークン一式を管理できることが説明されています。

NFTユーザーは、コレクション全体への承認に特に注意する必要があります。

悪意のあるオペレーターを承認すると、アイテムごとの確認なしに、攻撃者が価値の高いNFTを移転できる可能性があります。

そのため、NFTの承認に関するウォレットの警告は真剣に受け止める必要があります。

不要になったNFTのオペレーター承認は取り消してください。

承認メカニズムとスマートコントラクトの権限

トークン承認は、スマートコントラクトの権限の一種にすぎません。

多くの暗号資産システムには、管理者承認、ロール承認、バリデーター承認、ガバナンス承認、アカウント単位の認証があります。

提案の実行前に承認を必要とするスマートコントラクトもあります。

マルチシグウォレットでは、トランザクションの送信前に複数の承認が必要になる場合があります。

ブリッジでは、バリデーターやガーディアンがクロスチェーンメッセージを承認する場合があります。

DAOでは、トークン保有者が投票を通じてガバナンス提案を承認する必要がある場合があります。

ウォレットでは、セッションキー、支出上限、アカウント委任の承認をユーザーに求める場合があります。

こうした承認メカニズムには、共通する基本的な考え方があります。

人またはシステムに、定められたルールのもとで操作する権限を付与することです。

セキュリティ上の重要な問いは常に同じです。

誰を承認するのか、その相手は何ができるのか、権限はいつまで有効なのか、どうすれば取り消せるのか。

承認メカニズムとEIP-7702

EIP-7702は、EthereumのPectraアップグレード計画の一環として、外部所有アカウント向けの新しいアカウント認証モデルを導入しました。

Ethereum.orgのPectra 7702ドキュメントでは、コードによる動作を追加し、外部所有アカウントに短期的な機能拡張を与える仕組みがEIP-7702で定義されていると説明されています。

これは通常のERC-20トークン承認とは異なります。

アカウント単位の認証メカニズムであり、特定の操作においてウォレットをスマートアカウントに近い形で動作させることができます。

これにより、トランザクションの一括処理、ガス代補助、より使いやすいウォレット操作などの機能を実現できる可能性があります。

一方、悪意のある委任ロジックを承認した場合、アカウント単位の認証によって新たなフィッシングリスクが生じる可能性もあります。

アカウント認証はウォレット自体の動作に影響する場合があるため、高リスクの権限として扱う必要があります。

承認について考える範囲は、単一トークンのAllowanceを超えるものになります。

アカウントがウォレットを通じて実行することを許可するコードは何か、という問題に変わります。

ウォレット技術が進化するにつれて、承認メカニズムはより柔軟で強力になります。

そのため、ウォレットのインターフェースも、より明確で安全なものにする必要があります。

承認メカニズムとウォレットのポップアップ

多くのユーザーが承認メカニズムに初めて触れるのは、ウォレットのポップアップです。

ウォレットでは、トークン使用の承認、permitへの署名、NFTアクセスの承認、トランザクションの確認、アカウント動作の認証などを求められる場合があります。

問題は、多くのウォレットのポップアップがユーザーにとって分かりにくいことです。

コントラクトアドレス、16進数データ、技術的な関数名、曖昧な権限ラベルが表示される場合があります。

安全なウォレットインターフェースでは、対象となる資産、権限を受け取る相手、移動可能な数量、承認が無制限かどうかを説明する必要があります。

アプリケーションに見覚えがあるからといって、承認画面を急いで進めてはいけません。

フィッシングサイトは本物のアプリケーションを模倣し、悪意のあるspenderの承認を求めることがあります。

ユーザーは報酬を請求しているつもりでも、ウォレットでは実際にはトークン承認を求められている場合があります。

承認内容を読むことは、防げる損失を避ける最も簡単な方法の一つです。

ウォレットの警告が分かりにくい場合は、すぐに署名せず、一度立ち止まってください。

承認メカニズムとDeFi

DeFiアプリケーションは、承認メカニズムに大きく依存しています。

スワップコントラクトが入力トークンを移動する前に、スワップでトークン承認が必要になる場合があります。

レンディングコントラクトが担保をプロトコルに取り込む前に、レンディングへの入金で承認が必要になることがあります。

ステーキングコントラクトがトークンを受け取る前に、ステーキング操作で承認が必要になることがあります。

流動性ポジションを作成する前に、対象となる1つ以上の資産の承認が必要になる場合があります。

ユーザーの許可に基づいてスマートコントラクトがトークンと連携できるため、こうした承認によってDeFiのコンポーザビリティが実現します。

しかし、DeFiでは時間の経過とともに多数のコントラクトを利用する可能性があり、承認リスクも高まります。

数十のアプリを利用したウォレットには、忘れられたAllowanceが多数残っている場合があります。

アプリを使わなくなっても、一部の承認が解除されずに残っている可能性があります。

DeFiユーザーは、定期的なセキュリティ習慣の一環として承認を確認してください。

多額の残高や長期保有資産を管理するウォレットでは、特に重要です。

承認メカニズムとブリッジ

ブリッジがトークンを別のチェーンに移動する前に、承認が必要になる場合があります。

ユーザーがトークンをブリッジに預け入れる前に、ブリッジコントラクトがトークンの承認を求めることがあります。

その後、ブリッジは設計に従って資産をロック、バーン、または移転します。

ブリッジは価値の高い攻撃対象となるため、ブリッジに対する承認には注意が必要です。

ブリッジコントラクトや承認経路が侵害された場合、未解除のAllowanceが危険になる可能性があります。

特に新しいブリッジや不慣れなネットワークを利用する場合は、ブリッジコントラクトを承認する際に注意してください。

信頼できる情報源を通じて、公式ブリッジのアドレスを確認してください。

リスクを理解し、コントラクトを信頼できると判断できない限り、無制限の数量を承認しないでください。

移転が完了した後、使わなくなったブリッジ承認は取り消してください。

ブリッジ承認は、ウェブサイト上の通常のクリックではなく、価値を移動する権限として扱う必要があります。

承認メカニズムとアカウント抽象化

アカウント抽象化によって、ウォレットが操作を承認する方法が変わります。

すべての操作を単純な外部所有アカウントのトランザクションとして実行する代わりに、スマートアカウントでは独自のルールを利用できます。

ルールには、支出上限、セッションキー、操作の一括処理、ソーシャルリカバリー、ガス代補助、ポリシーに基づく権限などが含まれる場合があります。

この環境では、承認メカニズムがより柔軟になります。

たとえば、ユーザーがゲームのセッションを承認し、1時間に限って少額のゲーム内操作を許可することがあります。

サブスクリプション型アプリに対して、支払い上限を承認する場合もあります。

信頼できるデバイスには低リスクの操作への署名を許可し、高額な送金は許可しない設定も考えられます。

これによりユーザー体験が向上し、ウォレットでの確認を繰り返す必要が減る可能性があります。

一方、新たな権限管理の課題も生じます。

ユーザーには、有効なセッション、支出上限、委任されたキー、有効期限、取り消し方法を表示する明確なダッシュボードが必要です。

アカウント抽象化が普及するにつれ、承認は単純なトークンAllowanceというより、デジタルアクセス制御システムに近づいていきます。

承認メカニズムとガバナンス

ガバナンス承認はトークン使用の承認とは異なりますが、同じ権限付与の考え方に基づいています。

DAOの提案では、プロトコルのパラメーター変更やトレジャリー資金の支出の前に、トークン保有者の承認が必要になる場合があります。

マルチシグのトレジャリーでは、トランザクションの実行前に複数の署名者による承認が必要になることがあります。

プロトコルのアップグレードでは、新しいコードを有効にする前にガバナンス承認を求める場合があります。

こうした承認は、共有システムが一者の判断だけで動かされるのを防ぎます。

ただし、投票権が集中している場合や署名者が侵害された場合、ガバナンス承認にもリスクが伴います。

不適切なガバナンス承認によって、手数料の変更、コントラクトのアップグレード、資金の移転、リスク設定の変更が行われる可能性があります。

承認はウォレットだけの問題ではないことを理解する必要があります。

プロトコルやコミュニティのレベルでも重要です。

安全な暗号資産システムには、個々の資産移動と集団的な意思決定の両方に、安全な承認が必要です。

承認メカニズムのセキュリティリスク

最初の大きなリスクは無制限承認です。

無制限承認によって、トークンの現在および将来の残高がすべて承認先のspenderにさらされる可能性があります。

2つ目のリスクは、悪意のあるspenderアドレスです。

フィッシングサイトが、攻撃者の管理するコントラクトを承認するよう求める場合があります。

3つ目のリスクは、コントラクトの侵害です。

以前は安全だったコントラクトも、アップグレード、悪用、または侵害された管理者キーによる支配によって危険になる可能性があります。

4つ目のリスクは、ウォレットの表示が不十分なことです。

ウォレットが承認内容を明確に説明しなければ、ユーザーは権限を理解せずに署名する可能性があります。

5つ目のリスクは、承認の競合状態です。

古いERC-20承認方式では、Allowanceを0以外の値から別の0以外の値へ変更する際に問題が起きる場合があります。

6つ目のリスクは、署名の悪用です。

permit署名やアカウント認証は、トランザクションがすぐにブロードキャストされなくても危険な場合があります。

7つ目のリスクは、承認を忘れてしまうことです。

ユーザーがアプリケーションの利用をやめた後も、古い権限が有効なまま残る場合があります。

承認の競合状態

ERC-20の承認に関する競合状態は、Allowanceをある値から別の値に変更する際に知られている問題です。

spenderに100トークンのAllowanceがある状態で、ユーザーが50に変更しようとすると、新しい50が確定する前に、悪意のあるspenderが古い100を使おうとする可能性があります。

タイミングがユーザーに不利に働けば、spenderがユーザーの意図を超える数量を使用できる場合があります。

ERC-20の複数回引き出し問題に関するセキュリティ研究では、この承認関連リスクと緩和策が検討されました。

よく使われる、より安全な方法は、まずAllowanceをゼロに設定し、その後に希望する新しいAllowanceを設定することです。

一部のトークン実装やライブラリには、Allowanceを安全に減らすための補助関数が用意されています。

開発者は、危険なAllowance変更を避けられるよう、トークンやアプリの処理フローを設計する必要があります。

ユーザーが技術的な詳細をすべて把握する必要はありませんが、承認には例外的なケースがあることを理解しておくべきです。

ウォレットやアプリケーションは、こうした問題をユーザーが自動的に回避できるよう支援する必要があります。

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

可能な限り、必要な数量だけを承認してください。

不慣れなコントラクトや高リスクのコントラクトに対する無制限承認は避けてください。

承認に署名する前にspenderのアドレスを確認してください。

承認の対象が1つのトークンなのか、コレクション内のすべてのトークンなのか、アカウント全体の動作なのかを確認してください。

アプリケーションの利用を終えた後、古い承認を取り消してください。

permitや認証を作成する署名には注意してください。

価値の高い資産の保管用と、アプリケーションを積極的に利用する用途で、ウォレットを分けてください。

長期保有資産は、未解除の承認が最小限のウォレットで管理してください。

承認する前に、信頼できる情報源から公式コントラクトアドレスを確認してください。

予期しない操作中にウォレットが承認を求めた場合は、すぐに進めず一度立ち止まってください。

ウェブサイトからウォレットの接続を解除しても、承認が有効なまま残る場合があることを忘れないでください。

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

開発者は、ユーザーの操作に必要な最小限の数量を承認対象とすべきです。

無制限承認だけを唯一の選択肢にすることは避けてください。

アプリケーションのインターフェースでは、承認数量を分かりやすい言葉で説明してください。

権限を受け取るspenderコントラクトを明確に示してください。

ユーザーが署名内容を理解できる場合に限り、permit方式のフローをサポートしてください。

高リスクの操作後には、承認の取り消し方法を案内してください。

NFTやマルチトークンコントラクトに対する不要なオペレーター承認は避けてください。

権限の範囲が限定され、監査可能で、簡単に取り消せるようコントラクトを設計してください。

十分にレビューされたトークンライブラリを使い、最新のセキュリティ慣行に従ってください。

承認時のユーザー体験は、コンバージョン率だけでなくセキュリティ機能として扱ってください。

承認メカニズムとウォレット接続の違い

ウォレット接続は承認と同じではありません。

ウォレットを接続すると、通常、ウェブサイトはウォレットアドレスを確認し、操作をリクエストできるようになります。

通常、それだけでウェブサイトにトークンを移動する権限が付与されるわけではありません。

承認は、トークンコントラクトやスマートアカウントシステム内でspenderに権限を付与するため、より強いものです。

この2つの操作を混同するユーザーは少なくありません。

ウォレットの接続を解除すると、ウェブサイトが新たな署名を簡単に要求できなくなる場合がありますが、既存のトークン承認が自動的に取り消されるわけではありません。

安全のためにウォレットの接続解除だけに頼るべきではありません。

spenderを承認した場合、オンチェーンで変更されるまでAllowanceが残る可能性があります。

権限を削除するには、通常、承認を取り消すか更新する必要があります。

この違いを理解すれば、誤った安心感を避けられます。

承認メカニズムと署名の違い

署名も必ずしも承認と同じではありませんが、承認を作成する署名もあります。

通常のメッセージ署名は、ウォレットの所有権を証明したり、アプリにログインしたりするために使われる場合があります。

permit署名は、トークンのAllowanceを承認する場合があります。

アカウント委任の署名は、ウォレットのコードやポリシーによる動作を認証する場合があります。

そのため、署名が無害だと決めつけてはいけません。

悪意のあるウェブサイトは、トランザクションより手数料が安く見える署名を求めながら、重大な権限を作成する可能性があります。

メッセージの種類、ドメイン、チェーン、spender、トークン、数量、期限、要求される操作を確認してください。

ウォレットは、危険な署名と低リスクのログインメッセージを視覚的に区別すべきです。

開発者は、ユーザーが内容を見ずにクリックする習慣を生む曖昧な署名リクエストを避けてください。

最新の暗号資産では、トランザクションと署名メッセージの両方を通じて承認が行われる場合があります。

承認メカニズムとトークン規格

トークン規格によって、承認メカニズムは異なります。

ERC-20は、代替可能なトークンにAllowanceベースの承認を使用します。

ERC-721は、個々のNFTに対する承認と、コレクション単位のオペレーター承認を使用します。

ERC-1155は、1つのコントラクト内の複数のトークンIDを対象にできるオペレーター承認を使用します。

ERC-2612は、ERC-20型トークンに署名ベースのpermit承認を追加します。

新しいウォレット規格やアカウント規格では、セッション権限、実行の委任、アカウント単位の認証が追加される場合があります。

このように多様な仕組みがあるため、すべての承認ポップアップを同じものとして扱うべきではありません。

1つのステーブルコインの承認と、コレクション内のすべてのNFTに対する承認は異なります。

permit署名は、直接のapproveトランザクションとは異なります。

アカウント委任は、トークンAllowanceとは異なります。

最も重要なのは、承認によって具体的にどのような権限が付与されるかを確認することです。

承認メカニズムに関するよくある誤解

よくある誤解の一つは、承認によってトークンがすぐに移動するというものです。

承認は通常、権限を付与するものであり、トークンを移動するのは後の移転操作です。

もう一つの誤解は、ウォレットの接続を解除すれば承認も取り消されるというものです。

ウォレットの接続解除によって、トークンコントラクト内のAllowanceが変更されることは通常ありません。

3つ目の誤解は、無制限承認が現在の残高だけに影響するというものです。

後から同じトークンを受け取った場合、無制限承認によって将来の残高も危険にさらされる可能性があります。

4つ目の誤解は、メッセージへの署名は常に安全だというものです。

実際に資産リスクを伴うpermitやアカウント認証を作成する署名もあります。

5つ目の誤解は、信頼できるアプリなら承認を取り消す必要はないというものです。

信頼できるアプリであっても、バグ、アップグレード、キーの侵害、リスク状況の変化が起こる可能性があります。

6つ目の誤解は、代替可能なトークンを伴わないためNFTの承認は低リスクだというものです。

NFTのオペレーター承認によって、価値の高いコレクティブルやゲーム内資産を広範に管理される可能性があります。

関連する暗号資産用語

Allowanceとは、spenderが所有者のウォレットから移動できるERC-20トークンの数量です。

approve()はspenderのAllowanceを設定するERC-20関数です。

transferFrom()は、Allowanceを受け取ったspenderがトークンを移動するために使うERC-20関数です。

Permitとは、所有者が直接approveトランザクションを送信せずにAllowanceを変更できる、署名ベースの承認方式です。

setApprovalForAll()は、NFTやマルチトークン規格で、より広範な資産を管理するオペレーターを承認する関数です。

承認の取り消しとは、承認を削除または縮小する手続きです。

spenderとは、承認を通じてトークンを移動できるアドレスまたはコントラクトです。

operatorとは、所有者に代わってNFTやマルチトークン資産を管理する権限を与えられたアドレスです。

アカウント抽象化とは、より柔軟なアカウントルールや権限システムを実現するウォレット設計の手法です。

スマートコントラクトとは、呼び出されるとルールを自動的に実行するブロックチェーン上のコードです。

よくある質問

暗号資産における承認メカニズムとは？

承認メカニズムとは、ユーザーがコントラクト、アドレス、ウォレット、オペレーターに対し、ユーザーに代わって定められた操作を行う権限を付与するシステムです。

トークン承認とは？

トークン承認とは、トークン規格のルールに従ってspenderがトークンを移動または管理できるようにする、オンチェーン上の権限です。

ERC-20承認とは？

ERC-20承認とは、トークン所有者がspenderに対し、transferFrom()を通じて一定数量までのトークンを移転する権限を与えるAllowanceシステムです。

Allowanceとは？

Allowanceとは、spenderが所有者のウォレットから移動できるトークンの数量です。

承認は移転と同じですか？

いいえ。承認は権限を付与するもので、移転は実際にトークンを移動させます。

無制限承認が危険なのはなぜですか？

承認されたトークンの現在および将来の残高をすべて、spenderが移動できる可能性があるためです。

トークン承認を取り消すには？

Allowanceをゼロに設定するか、オペレーター権限を削除するオンチェーントランザクションを送信します。

ウォレットの接続を解除すると承認も取り消されますか？

いいえ。ウェブサイトからウォレットの接続を解除しても、オンチェーンに保存されたトークン承認は通常取り消されません。

Permit承認とは？

Permit承認は、トークン所有者がapproveトランザクションを直接送信せずに、署名メッセージでERC-20のAllowanceを認証する方式です。

NFTの承認は危険ですか？

価値の高いNFTやコレクション全体の管理をオペレーターに承認する場合、NFTの承認は危険になる可能性があります。

承認前に確認すべきことは何ですか？

spender、トークン、数量、ネットワーク、期限、ウェブサイト、承認が限定的か無制限かを確認してください。

最も安全な承認方法は？

必要な数量だけを承認し、知らないspenderを避け、不要になった権限を取り消すことです。

まとめ

承認メカニズムは、暗号資産で最も重要な権限管理システムの一つです。

ユーザーはスマートコントラクト、オペレーター、ウォレット、プロトコル、ガバナンスシステムに対し、定められた範囲内で操作する権限を付与できます。

最も一般的なのはERC-20トークン承認で、ユーザーがspenderにAllowanceを付与します。

承認メカニズムによって、DeFi、NFT、ブリッジ、ステーキング、決済、ゲームなど、多くのスマートコントラクトを使った処理が可能になります。

一方、悪意のあるコントラクトの承認、無制限の権限付与、古いAllowanceの放置、内容が不明瞭な認証メッセージへの署名は、重大なセキュリティリスクにつながります。

最も重要な教訓は、承認が無害なバックグラウンド処理ではないということです。

別のアドレスが価値ある資産を移動できるかどうかを左右する権限です。

必要なものだけを承認し、ウォレットの確認画面を注意深く読み、可能な場合は無制限承認を避け、使わなくなった権限を定期的に取り消してください。

開発者は、明確で、範囲が限定され、簡単に取り消せる承認フローを設計すべきです。

ウォレットは、ユーザーが署名内容を理解できるよう、承認を分かりやすく説明する必要があります。

permit署名、アカウント抽象化、セッションキー、EIP-7702型のアカウント認証によって暗号資産ウォレットが進化するにつれ、承認メカニズムはより強力で複雑になります。

そのため、権限管理は暗号資産のセキュリティの中核となります。

承認を理解しているユーザーは、フィッシングを避け、スマートコントラクトのリスクを軽減し、長期保有資産を守るための備えを強化できます。

より安全な承認を設計するプロトコルは、ユーザーの信頼を得やすくなります。

したがって、承認メカニズムは単なる技術的な機能ではありません。

ユーザー、トークン、スマートコントラクト、そしてより広範なオンチェーン経済の間で安全にやり取りするための基盤です。