ERC20における利便性とセキュリティのトレードオフ:無制限承認

ERC20における利便性とセキュリティのトレードオフ:無制限承認

要旨

イーサリアムでは、ERC20トークンは企業やユーザーによって分散型アプリケーション(DApps)を構築するために広く利用されています。多くのERC20トークンは大きな価値を持ち、仮想通貨市場で流通しています。さらに、DeFiエコシステムの活発な発展に伴い、ERC20トークンの取引はますます頻繁になっています。ERC20の標準に基づき、DAppsや他のユーザーにトークンを引き出す許可を与えるために approve() メソッドが呼び出されます。実際には、多くのDAppsはユーザーからの無制限の承認を必要としており、この設計は深刻な問題を引き起こしています。一連のインシデントが発生し、ユーザーとDApps自身の両方に多大な損失をもたらしました。

0xffffff. 前書き

長らく議論されてきたテーマである「無制限承認」は、DeFiの活発な発展といくつかのセキュリティインシデント以来、浮上してきました。多くのセキュリティインシデントから着想を得て、私たちは「無制限承認」について、さまざまな側面から包括的な調査を改めて行います。同時に、第29回ブロックチェーンビレッジカンファレンスに招待され、この問題について講演することになりました。

おすすめの読み物:

  • イーサリアム初心者の方は、ブログ全体を読むことを強くお勧めします。
  • イーサリアムの専門家で、無制限承認の経験がある方は、セクション0x2から読み始めてください。

0x0. 背景

「無制限承認とは何か」についての議論に入る前に、「ERC20トークンにおける承認とは何か」についておさらいします。

ERC20トークン

イーサリアムでは、イーサ以外にもさまざまなトークンが仮想通貨市場で大きな価値を持って流通しています。ERC20は最も人気のあるトークン標準です。私たちの未完了の統計によると、CoinGecko(トークンの価格を集約するウェブサイト)とUniswap(現在最も有名な分散型取引所の一つ)では、5,600以上、44,000以上のERC20トークンが記録されています。

承認メカニズム

承認プロセスは、主に3つのエンティティ(送信者受取人トークンコントラクト)、2つの関数(approvetransferFrom)、およびERC20標準の2つの変数(balanceOfallowance)に関連しています(下の図を参照)。

承認プロセスを理解するために、以下の図を示し、approve関数とtransferFrom関数がトークンコントラクトの状態をどのように変更するかを説明します。

  1. (ステップ1)初期状態として、送信者はコントラクトに100トークンを保有しており、受取人送信者から承認されたallowanceを一切持っていません。
  2. (ステップ2)送信者approve関数を呼び出して、受取人に100トークンの許可を付与します。したがって、allowance[sender][spender]は0から100に増加し、送信者のbalanceOfには変更はありません。
  3. (ステップ3)最後に、受取人transferFromを呼び出して、送信者から自身へ80トークンを移動させます。その結果、送信者受取人balanceOfは更新され(つまり、20と80)、受取人のallowanceは20に減少します。

現実世界の3種類の承認

現実世界では、承認額に基づいてすべての承認を3種類に分類できます。

  • ゼロ承認: 承認額がゼロです。これは基本的に、ユーザー/送信者が特定のプラットフォーム/受取人からのallowanceを取り消そうとしていることを意味します。
  • 無制限承認: 承認額がuint256の最大値(0xffff...ffff)またはトークンの総供給量に等しくなります。このタイプの承認は、多くのDeFiプラットフォーム(取引所、貸付プラットフォームなど)で頻繁に使用されます。
  • その他の承認: これは残りの部分をカバーします。ユーザーは通常、プラットフォームやウォレットがサポートする変更機能に基づいてこの承認を起動します。

0x1. 現実世界のインシデント

前述の承認問題に関連する現実世界のインシデントもいくつかあります。講演では、これらの話のうち2つ(UniCat、Bancor Finance)を詳細に検討しました。これらのインシデントについてさらに詳しく知りたい場合は、以下のリンクをたどってください。

0x2. いくつかの測定

このセクションでは、オフチェーンとオンチェーンの両方の側面から詳細な調査結果を提示します。「無制限承認」の現状をよりよく理解するために、私たちはフロントエンドユーザーの役割を担って測定を実施しました。

現実世界の承認プロセス

上記の図は、フロントエンドユーザーが承認トランザクションを完了するために6つのステップを踏む可能性があることを示しています。4つの主要なエンティティ(フロントエンドユーザー、ウォレット、プラットフォーム、トークンコントラクト)があります。それでは、フローをステップごとに見ていきましょう。

ステップ1、2: まず、ほとんどのフロントエンド(モバイル、ウェブサイト)ユーザーは、ウォレットを希望のプラットフォームに接続し、サービスリクエストを送信します。

ステップ3: 次に、プラットフォームからユーザーのウォレットへ、プラットフォームは必要なデータ(最も重要なのは承認額)を含む承認トランザクションを構築し、確認のためにユーザーのウォレットに送信します。

ステップ4、5: 承認トランザクションを受信した後、ウォレットはユーザーに対応する情報を表示し、ユーザーの確認を待ちます。

ステップ6: ユーザーがトランザクションを確認すると、ウォレットはトランザクションをネットワークに送信して検証します。さらに、検証されたトランザクションはトークンコントラクトの状態(Allowance[User][Platform])を変更します。

(次のセクションでは、各タイプの測定(オフチェーンおよびオンチェーン)の動機を最初に紹介します。次に、さまざまな側面から測定結果と発見を提示します。)

オフチェーン調査

動機

現実世界の承認プロセスでは、フロントエンドユーザーがウォレットとプラットフォームのユーザーインターフェースと直接やり取りしていることが容易にわかります。したがって、私たちは15の有名なウォレットと24のDeFi(分散型金融)プラットフォームを選択し、オフチェーン調査を実施しました。

(調査結果は以下の2つの図にまとめられています。)

さらに、主に説明と柔軟性について考慮しました。

  • 説明
  • ウォレット:1)ウォレットが承認トランザクションの健全な情報(ユーザー、受取人、トークン、承認額を含む)を表示するかどうか;2)ウォレットが「無制限承認」について特別な警告を発したり、ユーザーに通知したりするかどうか
  • プラットフォーム:(基準1)プラットフォームがWeb UIで承認トランザクションの健全な説明を提供するかどうか;(基準2)プラットフォームが承認トランザクションの存在をユーザーに通知するかどうか;(基準3)プラットフォームが2つのトランザクションが逐次実行されることをユーザーに通知するかどうか
  • 柔軟性:ウォレットまたはプラットフォームのいずれにおいても、UIが承認額の変更機能を提供するかどうか

(次のセクションでは、上記の2つの側面がウォレットとプラットフォームの両方でどのように実行されるかの結果を示します。ウォレットとプラットフォームのそれぞれについて2つのケースを選択します。)

0x222. ウォレット:Metamask & Coinbase

CoinbaseウォレットとMetamask(Chrome拡張機能)ウォレットについて調査結果を提示します。Google Playストアの情報(下の図を参照)によると、CoinbaseとMetamaskはどちらも100万回以上のインストールがあります。どういうわけか、Coinbaseはクライアントからのレビューが多く、スコアも高くなっています。

2つのウォレットの調査では、Compoundプラットフォームでスワップ機能のテストに使用しました。Compoundプラットフォームはデフォルトでユーザーに無制限承認を設定することに注意してください。

ウォレット1:Metamask

下の図に示すように、ユーザーがCompoundによって構築された承認トランザクションを確認している間、受取人のアドレス、承認署名、承認額(ステップ2)を含む完了した情報を基本的に確認できます。さらに、Metamaskは「編集」ボタン(ステップ2、3、4)でユーザーが承認額を変更できるようにさえしています。

ウォレット2:Coinbase

Metamaskウォレットと比較して、Coinbaseウォレットはまったく重要な情報を提供しません。ユーザーは、承認トランザクションを確認した後(下の図)にのみ、詳細を確認できます。ステップ2、3、4は、承認トランザクションが保留中または完了モードである最中またはにのみ表示されることに注意してください。したがって、Coinbaseウォレットは承認トランザクションの必要な情報を隠しており、承認額の変更機能を提供していません。

0x223. プラットフォーム:Bancor & Curve Finance

このセクションでは、BancorとCurve Financeを比較します。下の図に示すように、defipulseの最新の統計(2021年8月7日現在)によると、Curve FinanceとBancorは、総ロックバリューの点でそれぞれ1位と5位のDEX(分散型取引所)です。

両プラットフォームでの調査設定では、Metamaskウォレットを使用して、両プラットフォームが提供するスワップ機能のテストを行います。

プラットフォーム1:Bancor

Bancorでスワップ機能のテストを行っている間、承認トランザクションの必要性を説明し(下の図)、ユーザーに2つのオプション(無制限/限定承認)を提供しています。無制限承認とは別に、Bancorの限定承認では、スワップに使用しようとしているallowanceの正確な金額のみが必要です。

プラットフォーム2:Curve Finance

しかし、Curve Financeでは「興味深い」ことが起こります。下の図に示すように、スワップをリクエストすると、Curve FinanceのUIは「10 USDTを交換のために承認してください」と表示されますが、Metamaskは無制限承認トランザクションを受け取ります。これは明らかにユーザーを誤解させる情報です。

その後、Curve Financeでこの問題を確認しようとしたところ、彼らは私たちの懸念を認め、「ユーザーが毎回承認するのを嫌がったからだ」と述べました(下の図)。

Curve Financeと同様に、Yearn Finance(https://yearn.fi/)のUIも同様の問題を抱えています。(私たちの講演でも言及し、証拠を示しています)

0x23. オンチェーン調査

0x231. 動機

チェーン上での「無制限承認」の状況をさらに理解するために、私たちはすべてのトランザクション(2021年4月30日まで)を収集して調査を続けました。下の図に示すように、「無制限承認」の数は近年急速に増加しています。私たちの調査では、UniswapV2の導入が「無制限承認」の成長を刺激する主な要因であると判明しました。そして、測定結果に基づいてこの点についてさらに説明します。

同時に、トークンとプラットフォームの両方を代表して「無制限承認」を調査するために(それらはユーザー自身よりも最も関連性の高い用語であるため)、私たちは2つの側面から調査を行います。

  • 「無制限承認」の分布
  • リスク分析

0x232. 「無制限承認」の分布

以下のグラフを理解しやすくするために、まず図に記載されている各用語を説明します。

  • Y軸(最大承認率):値が大きいほど、「無制限承認」の割合がすべての承認トランザクションの中で高くなります。
  • X軸(Liveness):値が大きいほど、プラットフォームまたはトークンがよりアクティブになります。Livenessの値は、承認トランザクションの数と、最初の承認トランザクションと最後の承認トランザクションの間の時間差によって決まります。
  • ドットサイズ:サイズが大きいほど、トークンまたはプラットフォームが関与する承認トランザクションが多くなります。

(以下の2つの図は、承認トランザクションに最も頻繁に関与する上位1000のトークン/プラットフォームのみを示しています。)

(プラットフォーム)

(トークン)

プラットフォーム: プラットフォームのグラフを見ると、UniswapV2は明らかに他のすべてのプラットフォームを3つの用語すべてで支配しています。これが、私たちが「UniswapV2の導入が『無制限承認』の成長を刺激する主な要因である」と宣言する理由です。

トークン: 分布に関しては、USDC、USDT、DAIが最高のパフォーマンスを示しています。これらはすべてステーブルコインであり、ステーブルコインは通常、仮想通貨市場での取引に使用されるため理にかなっています。他の注目すべきトークン(上位10トークン)については、最大承認率は非常に似ています。

0x233. リスク分析

以前の結果に基づいて、USDC、USDT、DAI(上位3トークン)と2つのプラットフォーム(Bancor、UniCat)を選択してリスク分析を実施します。同時に、承認されたトークンのリスクを明確にするために、2つの用語(下の図に示す)を定義します。

リスク額

  • トークンの場合、リスク額はtransferFrom関数を呼び出すことで転送できるトークンの総額に等しくなります。
  • プラットフォームの場合、リスク額はtransferFrom関数を呼び出すことで転送できる単一トークンの総額に等しくなります。

リスク率

  • 固定トークンに対して、リスク率は、この固定トークンの総供給量に対するリスク額の割合を表します。

トークン: 下の図に示すように、USDCとUSDTは非常に安定しています(リスク率は約10%)。DAIは年の途中で劇的な下落を経験し、最終的に安定しました(これも約10%ですが、より多くの変動があります)。この現象は、特定のイベントまたはDAIの動作メカニズムを示している可能性があります。したがって、原因を調査するためにはまだ作業が必要です。

プラットフォーム: プラットフォームのリスク分析について、Bancor(BNTトークンを使用)とUniCat(UNIトークンを使用)の両方でのリスク額のトレンドグラフ(下の図)を提示します。

Bancorのトレンドプロットは、急激な増加と減少を示しています。これは実際、チームが脆弱なコントラクトから安全な場所へ悪用可能なトークンをどれだけ迅速に移動させたかを完璧に説明しています。

UniCatのトレンドプロットについては、明らかな減少はUniCatのバックドア攻撃によるものであることを確認しました。

0x3. 既存のソリューション

前述のように、「無制限承認」はエコシステムに長らく存在するテーマです。さまざまな議論を通じて、承認プロセスを改善するためにいくつかのソリューションが提案されています。

  • ERC777
  • EIP2612

ソリューションに入る前に、「無制限承認」の根本的な動機をもう一度思い出していただきたいと思います。

  • approve/transferFromの両方で2つのトランザクションが必要
  • カスタマイズされた承認は、取引または入金前に毎回承認を求めることをユーザーに強制します(つまり、より多くのトランザクション手数料を支払うことになります)。
  • プラットフォームは、一度無制限承認を求めることでユーザーエクスペリエンスを最大化したいと考えています。

0x31. ERC777

2017年に提案されたトークン標準であるERC777は、ERC20トークンの承認プロセスを改善するために使用される以下の点があります。

  • ユーザーは、希望する金額でトークンを転送するためにオペレーター(取引所など)を「承認」できます。
  • ユーザーは、承認のためのトランザクションを繰り返し送信する必要はありません。
  • ユーザーは、「無制限承認」のリスクを心配する必要はありません。

結論として、ERC777を使用すると、ユーザーは任意の承認されたオペレーターとアトミックな購入を達成できます。

しかし、ERC777の欠点も明らかです。

標準で適用されるフックによる高いトランザクション手数料(詳細はこちら:https://eips.ethereum.org/EIPS/eip-777)。 ユーザーは信頼できるオペレーターを選択する必要があります(これは再びユーザーに問題を投げかけます)。

0x32. EIP2612

EIP2612について、この提案では、著者は署名付きメッセージを使用してトランザクション検証を行うことができると述べており、これによりユーザーはallowanceを変更するためにトランザクション手数料を支払う必要がなくなります。より直接的には、EIP2612により承認トランザクションは無料になります。さらに、この提案は現在、UniswapV3で貸付プロバイダーのトークンに使用されています。

0x4. 結論

結論として、「無制限承認」は複数の承認トランザクションの実行コストを確かに低下させます。しかし、私たちの調査を通じて、一部のプラットフォームとウォレットは、利便性とセキュリティの戦いで無害を装っています。さらに悪いことに、一部のプラットフォームやウォレットは、誤った情報を表示してユーザーを誤解させようとしています。したがって、「無制限承認」を使用する代わりに、プラットフォームとウォレットは、最初からユーザーを保護するためのより安全なUIまたはプロトコルを開発することを真剣に検討すべきだと提案します。DeFiのユーザーとして、セキュリティ意識を構築することは、エクスプロイトの結果ではなく、最初から意識を持つべきことです。イーサリアムで安全で繁栄した環境を構築することは、コミュニティだけでなく、私たち一人ひとりの責任であると信じています。

私たちについて

https://www.blocksecteam.com

[email protected]

Twitter:https://twitter.com/BlockSecTeam

Medium:https://blocksecteam.medium.com/

Sign up for the latest updates
Weekly Web3 Security Incident Roundup | Feb 9 – Feb 15, 2026

Weekly Web3 Security Incident Roundup | Feb 9 – Feb 15, 2026

During the week of February 9 to February 15, 2026, three blockchain security incidents were reported with total losses of ~$657K. All incidents occurred on the BNB Smart Chain and involved flawed business logic in DeFi token contracts. The primary causes included an unchecked balance withdrawal from an intermediary contract that allowed donation-based inflation of a liquidity addition targeted by a sandwich attack, a post-swap deflationary clawback that returned sold tokens to the caller while draining pool reserves to create a repeatable price-manipulation primitive, and a token transfer override that burned tokens directly from a Uniswap V2 pair's balance and force-synced reserves within the same transaction to artificially inflate the token price.

Top 10 "Awesome" Security Incidents in 2025

Top 10 "Awesome" Security Incidents in 2025

To help the community learn from what happened, BlockSec selected ten incidents that stood out most this year. These cases were chosen not only for the scale of loss, but also for the distinct techniques involved, the unexpected twists in execution, and the new or underexplored attack surfaces they revealed.

#10 Panoptic Incident: XOR Linearity Breaks the Position Fingerprint Scheme

#10 Panoptic Incident: XOR Linearity Breaks the Position Fingerprint Scheme

On August 29, 2025, Panoptic disclosed a Cantina bounty finding and confirmed that, with support from Cantina and Seal911, it executed a rescue operation on August 25 to secure roughly $400K in funds. The issue stemmed from a flaw in Panoptic’s position fingerprint calculation algorithm, which could have enabled incorrect position identification and downstream fund risk.