Back to Blog

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

August 17, 2021
12 min read

概要

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

0xffffff. 前書き

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

おすすめの読み物:

  • Ethereumの初心者の方は、ブログ全体を読むことを強くお勧めします。
  • Ethereumのエキスパートで、無制限承認の経験がある方は、セクション0x2から読み始めてください。

0x0. 背景

「無制限承認とは何か」という議論に入る前に、「ERC20トークンにおける承認とは何か」を振り返りたいと思います。

ERC20トークン

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

承認メカニズム

承認プロセスは、主に3つのエンティティ(送信者受領者トークンコントラクト)と、ERC20標準の2つの関数(approvetransferFrom)および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種類に分類できます。

  • ゼロ承認: 承認額がゼロです。これは基本的に、ユーザー/送信者が特定のプラットフォーム/受領者からの許可を取り消そうとしていることを意味します。
  • 無制限承認: 承認額は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ストアの情報(下の図を参照)によると、CoinbaseMetamaskはどちらも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

このセクションでは、BancorCurve Financeを比較します。下の図に示すように、defipulseの最新統計(2021年8月7日現在)に基づくと、Curve FinanceBancorは、総ロックバリューの点でそれぞれ第一位と第五位の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のUIも同じ問題を抱えています。(私たちの講演でも、証拠とともに言及しています。)

0x23. オンチェーン調査

0x231. 動機

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

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

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

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

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

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

(以下の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の欠点も明らかです。

標準に適用されるフックのため、高いトランザクション手数料(詳細についてはこちらを参照)。 ユーザーは信頼できるオペレーターを選択する必要があります(これは再びユーザーに問題を投げかけます)。

0x32. EIP2612

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

0x4. 結論

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

私たちについて

https://www.blocksecteam.com

[email protected]

Twitter:https://twitter.com/BlockSecTeam

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

Sign up for the latest updates
The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis
Security Insights

The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis

This BlockSec deep-dive analyzes the KelpDAO $290M rsETH cross-chain bridge exploit (April 18, 2026), attributed to the Lazarus Group, tracing a causal chain across three layers: how a single-point DVN dependency enabled the attack, how DeFi composability cascaded the damage through Aave V3 lending markets to freeze WETH liquidity exceeding $6.7B across Ethereum, Arbitrum, Base, Mantle, and Linea, and how the crisis forced decentralized governance to exercise centralized emergency powers. The article examines three parameters that shaped the cascade's severity (LTV, pool depth, and cross-chain deployment count) and provides an exclusive technical breakdown of Arbitrum Security Council's forced state transition, an atomic contract upgrade that moved 30,766 ETH without the holder's signature.

Weekly Web3 Security Incident Roundup | Apr 13 – Apr 19, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Apr 13 – Apr 19, 2026

This BlockSec weekly security report covers four attack incidents detected between April 13 and April 19, 2026, across multiple chains such as Ethereum, Unichain, Arbitrum, and NEAR, with total estimated losses of approximately $310M. The highlighted incident is the $290M KelpDAO rsETH bridge exploit, where an attacker poisoned the RPC infrastructure of the sole LayerZero DVN to fabricate a cross-chain message, triggering a cascading WETH freeze across five chains and an Arbitrum Security Council forced state transition that raises questions about the actual trust boundaries of decentralized systems. Other incidents include a $242K MMR proof forgery on Hyperbridge, a $1.5M signed integer abuse on Dango, and an $18.4M circular swap path exploit on Rhea Finance's Burrowland protocol.

Weekly Web3 Security Incident Roundup | Apr 6 – Apr 12, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Apr 6 – Apr 12, 2026

This BlockSec weekly security report covers four DeFi attack incidents detected between April 6 and April 12, 2026, across Linea, BNB Chain, Arbitrum, Optimism, Avalanche, and Base, with total estimated losses of approximately $928.6K. Notable incidents include a $517K approval-related exploit where a user mistakenly approved a permissionless SquidMulticall contract enabling arbitrary external calls, a $193K business logic flaw in the HB token's reward-settlement logic that allowed direct AMM reserve manipulation, a $165.6K exploit in Denaria's perpetual DEX caused by a rounding asymmetry compounded with an unsafe cast, and a $53K access control issue in XBITVault caused by an initialization-dependent check that failed open. The report provides detailed vulnerability analysis and attack transaction breakdowns for each incident.