---
title: "ERC-4626 初回預入インフレ攻撃：丸めでシェアが消失する仕組み"
description: "直接寄付が空の ERC-4626 Vault の交換レートを操作し、預入者のシェアをゼロに切り捨てる仕組みと、実装者や利用者がリスクを抑える方法を解説します。"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ERC-4626 初回預入インフレ攻撃：丸めでシェアが消失する仕組み

> 教育目的の情報であり、投資助言ではありません。投資により損失が生じる可能性があります。

<a id="answer"></a>

## 端的な回答

初回預入インフレ攻撃は、空またはほぼ空の ERC-4626 Vault を標的にします。攻撃者はごく少量を預け入れて最初のシェアを受け取った後、原資産を Vault に直接送金します。この寄付によって `totalSupply()` を増やさずに `totalAssets()` が増加し、既存の各シェアの価値が高まります。

被害者の預入がその操作されたレートで換算されると、整数除算によって受取シェアがごくわずか、またはゼロに切り捨てられる場合があります。被害者の資産は Vault に残る一方、発行済みシェアを保有する攻撃者は、膨張した資産請求権を償還できます。これは交換レート操作とスリッページの問題であり、ERC-4626 インターフェース自体の欠陥ではありません。

<a id="mechanism"></a>

## 仕組み

手数料や保護用オフセットのない単純な Vault では、預入で発行されるシェアはおおよそ `assets * totalSupply / totalAssets` です。ERC-4626 は、所定の資産額に対するシェア計算について、Vault に有利となるよう切り捨てることを要求しています。通常の交換レートでは丸め損失はごく小さいものの、シェア価格がつり上げられると、一シェア未満の価値しかない預入は丸めによって 100% を失う可能性があります。

攻撃が成立するかどうかは実装の詳細に左右されます。特に `totalAssets()` が Vault のトークン残高を読み取る場合、ERC-20 の直接送金によって、シェアを発行せずに会計上の資産が増えることがあります。また、攻撃者はシェア供給量が極めて少ない間に、被害者より先に取引を実行する必要があります。異なる会計方式や明示的な防御策を採用する Vault は、同じ形では脆弱でない可能性があります。

<a id="example"></a>

## 例

脆弱な空の Vault が 1:1 のレートで始まるとします。攻撃者は 1 単位の資産を預け入れて 1 シェアを受け取り、その後 999 単位を直接寄付します。これで 1 シェアを 1,000 単位の資産が裏付ける状態になります。被害者が 999 単位を預け入れると、単純な計算では整数の丸め後に `999 * 1 / 1,000 = 0` シェアとなります。

その後、Vault は 1,999 単位の資産を保有しますが、存在するのは攻撃者の 1 シェアだけです。預入処理がゼロシェアの結果を許容し、手数料やその他の制約もなければ、攻撃者はそのシェアを全 1,999 単位の資産と交換できます。その内訳は、最初に預け入れた 1 単位、寄付した 999 単位、被害者が預け入れた 999 単位です。取引コストを差し引く前の攻撃者の粗利益は、被害者の 999 単位となります。

<a id="risks"></a>

## リスクと防御策

実装者は、十分な初期流動性の投入、初期シェアのバーンまたはロック、ゼロでないシェア出力の強制、あるいは仮想資産と仮想シェアを使った交換レート設計によってリスクを軽減できます。OpenZeppelin の実装は仮想量を追加し、小数桁オフセットを通じてシェアの精度を高めます。文書化されたモデルでは、仮想シェアが寄付の一部を取り込むため、操作は利益を生まなくなるか、費用が大幅に増えます。どの防御策にも前提があるため、直接送金、丸め境界、手数料、損失、特殊なトークン挙動に対してテストする必要があります。

利用者とインテグレーターは、`previewDeposit()` を保証された最低値ではなく、見積もりとして扱う必要があります。受入可能な最低シェア数を強制し、その下限を満たさなければリバートする関数またはルーターを介して預入を送信してください。新規またはシェア供給量の少ない Vault に預け入れる前に、`totalAssets()`、`totalSupply()`、実装の換算式、意図しないトークン送金が会計に影響するかを確認してください。有利なフロントエンド見積もりが表示されていても、実行順序を変更され得る取引は保護されません。

<a id="misconceptions"></a>

## よくある誤解

- **誤解 1：ERC-4626 自体が安全な交換レートを保証する。** この標準は共通インターフェースと丸め動作を定義しますが、すべての実装を交換レート操作から守るものではありません。

- **誤解 2：`deposit()` の直前に `previewDeposit()` を呼び出せば、その出力が保証される。** 呼び出し間や実行前にオンチェーン状態が変わる可能性があります。預入経路には、強制可能な最低シェア数の制限が必要です。

- **誤解 3：ゼロシェアになる預入だけを拒否すれば、攻撃を排除できる。** 最も深刻な結果は防げますが、攻撃者は依然として預入者に少数のシェアしか受け取らせず、大きな丸め損失を負わせる可能性があります。防御策は、結果がゼロでないことだけでなく、許容スリッページを制限すべきです。

<a id="related"></a>

## 関連トピック

- [ERC-4626 Vault 標準](/ja/crypto/erc4626-vault/)
- [Fraud Proof](/ja/crypto/fraud-proof/)
- [アップグレード可能コントラクトの初期化処理乗っ取り](/ja/crypto/initializer-takeover/)
- [スマートコントラクト](/ja/crypto/smart-contract/)
- [取引シミュレーション](/ja/crypto/transaction-simulation/)

<a id="sources"></a>

## 出典

- [ERC-4626：トークン化 Vault](https://eips.ethereum.org/EIPS/eip-4626) - Ethereum Improvement Proposals（参照日：2026-08-20）
- [ERC-4626 トークン化 Vault 標準](https://docs.openzeppelin.com/contracts/4.x/erc4626) - OpenZeppelin（参照日：2026-08-20）
- [OpenZeppelin の ERC4626 実装](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC4626.sol) - OpenZeppelin（参照日：2026-08-20）

Source: https://wiki.fcontext.com/ja/crypto/erc4626-inflation-attack/index.mdx