Balancerが$120Mの盗難に遭った脆弱性技術分析
2025年11月3日、BalancerプロトコルがArbitrum、Ethereumなどの複数のパブリックチェーンでハッキングされ、1.2億ドルの資産損失を被りました。攻撃の核心は精度損失と不変値（Invariant）操作の二重の脆弱性にあります。今回の攻撃の重要な問題は、プロトコルが小額取引を処理するロジックにあります。前言
2025年11月3日、BalancerプロトコルはArbitrum、Ethereumなどの複数のパブリックチェーンでハッキングを受け、1.2億ドルの資産損失を被りました。攻撃の核心は、精度損失と不変値（Invariant）操作の二重の脆弱性にあります。
今回の攻撃の重要な問題は、プロトコルが小額取引を処理するロジックにあります。ユーザーが小額の交換を行うと、プロトコルは_upscaleArray関数を呼び出し、この関数はmulDownを使用して数値を切り捨てます。取引の残高と入力金額が同時に特定の切り捨て境界（例えば8-9 weiの範囲）にある場合、明らかな相対精度誤差が生じます。
精度誤差はプロトコルの不変値Dの計算過程に伝播し、D値が異常に縮小されます。そしてD値の変動は、Balancerプロトコル内のBPT（Balancer Pool Token）価格を直接引き下げ、ハッカーはこの圧縮されたBPT価格を利用して、事前に設計された取引経路を通じてアービトラージを行い、最終的に巨額の資産損失を引き起こしました。
脆弱性利用Tx:
https://etherscan.io/tx/0x6ed07db1a9fe5c0794d44cd36081d6a6df103fab868cdd75d581e3bd23bc9742
資産移転Tx:
https://etherscan.io/tx/0xd155207261712c35fa3d472ed1e51bfcd816e616dd4f517fa5959836f5b48569
技術分析
攻撃入口
攻撃の入口は Balancer: Vault コントラクトで、対応する入口関数はbatchSwap関数で、内部でonSwapを呼び出してトークン交換を行います。
関数のパラメータと制限から、いくつかの情報が得られます：
攻撃者はVaultを通じてこの関数を呼び出す必要があり、直接呼び出すことはできません。
関数内部では_scalingFactors()を呼び出してスケーリングファクターを取得し、スケーリング操作を行います。
スケーリング操作はswapGivenInまたはswapGivenOutに集中しています。
攻撃モード分析
BPT価格の計算メカニズム ：
Balancerの安定プールモデルにおいて、BPT価格は重要な参考基準であり、ユーザーがどれだけのBPTを得られるか、各BPTがどれだけの資産を得られるかを決定します。
ここでD = 不変値（Invariant）、CurveのStableSwapモデルから来ています。
プールの交換計算において：
ここでBPT価格基準として機能する部分は不変値Dであり、BPT価格を操作するにはDを操作する必要があります。以下にDの計算過程を分析します：
上記のコードでは、Dの計算過程はスケーリングされたbalances配列に依存しています。つまり、これらのbalancesの精度を変更する操作が必要であり、Dの計算エラーを引き起こします。
精度損失の根源：
スケーリング操作：
上記のように、_upscaleArrayを通じて、残高が非常に小さい場合（例えば8-9 wei）、mulDownによる切り捨てが顕著な精度損失を引き起こします。
攻撃プロセスの詳細
これらの交換はすべて同じbatchSwap取引内で行われ、同じ残高状態を共有していますが、各交換は_upscaleArrayを呼び出してbalances配列を変更します。
Callbackメカニズムの欠如
主なプロセスはVaultが開始されており、どのように精度損失が蓄積されるのか？その答えはbalances配列の伝達メカニズムにあります。
上記のコードを分析すると、onSwapを呼び出すたびにVaultは新しいcurrentBalances配列を作成しますが、Batch Swap内では：
最初の交換後、残高が更新されます（ただし、精度損失のため、更新後の値は不正確な可能性があります）
2回目の交換は1回目の結果に基づいて計算を続けます
精度損失が蓄積され、最終的に不変値Dが著しく小さくなります
重要な問題：
Vaultは毎回新しい配列を渡しますが：
- 残高が非常に小さい場合（8-9 wei）、スケーリング時の精度損失が大きい
- Batch Swap内では、後続の交換が既に損失した精度の残高に基づいて計算を続けます
- 不変値Dの変化が合理的な範囲内にあるかどうかの検証がありません
まとめ
Balancerの今回の攻撃は、以下のいくつかの理由に要約されます：
スケーリング関数が切り捨てを使用 ：_upscaleArrayはmulDownを使用してスケーリングを行い、残高が非常に小さい場合（例えば8-9 wei）、顕著な相対精度損失を引き起こします。
不変値計算が精度に敏感 ：不変値Dの計算はスケーリングされたbalances配列に依存しており、精度損失がDの計算に直接伝播し、Dを小さくします。
不変値変化の検証が欠如 ：交換プロセス中に、不変値Dの変化が合理的な範囲内にあるかどうかの検証が行われず、攻撃者が精度損失を繰り返し利用してBPT価格を引き下げることが可能になりました。
Batch Swap内の精度損失の蓄積 ：同じbatch swap内での複数の交換の精度損失が蓄積され、最終的に巨額の財務損失を引き起こします。
この2つの問題、精度損失と検証の欠如、攻撃者による境界条件の巧妙な設計が相まって、今回の損失を引き起こしました。
リスク警告
