急速に動くブロックチェーンの世界では、単一の計算ミスが何百万ドルもの損失につながることがあります。最近、Solidityコミュニティで重要な人物でありSpearbitのCEOでもあるHari KrishnanがXで「これまで見た中で最も複雑なバグ／エクスプロイトは何ですか？ 特に数学や丸め誤差にまつわるトリッキーなバグを探しています」というシンプルな質問で興味深い議論を巻き起こしました。

セキュリティ研究者や開発者から多数の回答が寄せられ、数学的な複雑さや丸め誤差を巡る衝撃的なエクスプロイトが浮かび上がりました。これらの事例は単にスリリングな話に留まらず、スマートコントラクトのセキュリティがプロジェクトの成否を分けるミームトークン関連の開発者や投資家にとって重要な教訓を含んでいます。以下にスレッドのハイライトを平易な言葉で解説します。

KyberSwap Elastic Exploit: 精度が招いた失敗

印象的な事例としてzerosnacks.ethが挙げたのは、2023年11月のKyberSwap Elasticハック（約5470万ドルの流出）です。本質的には、同プラットフォームのConcentrated Liquidity Market Maker（CLMM）と、流動性提供者向けに手数料を複利化するReinvestment Curveを悪用したものです。

流れはこうでした：攻撃者はフラッシュローンを使い、プールの価格（sqrtP、価格の平方根を2^96でスケールした値）を操作しました。流動性を精密な量で出し入れすることで、価格境界（ticks）をまたぐトークンスワップの計算を誤らせたのです。calcReachAmount関数のバグは、reinvestment liquidityを含めてしまうことでトークン量を過大評価し、tickを跨ぐ際に流動性の更新をスキップさせてしまいました。その結果、流動性が「重複」して扱われ、攻撃者は大量の利益を得るために逆スワップを行えました。

厄介なのは、全てがsqrtP計算の精度と丸めに依存していた点です—微小なズレが巨大な利益に膨らんだのです。ミームトークンの作成者にとって、カスタム流動性モデルの危険性を示しています。数学に重い関数は必ず監査を！ 詳細な解析はここを参照してください: https://slowmist.medium.com/a-deep-dive-into-the-kyberswap-hack-3e13f3305d3a

Bunniハック：丸めの方向性に裏切られるとき

Philogyは最近のBunniハック（約840万ドルの流出）について触れました。BunniはEthereumとUnichain上のDeFiプロトコルで、出金時のアイドル残高更新における丸めエラーを突かれました。

攻撃者はフラッシュローンで300万USDTを借り、USDC/USDTプールの価格を極端に歪めてUSDC残高をわずか28 weiにまで減らしました。そして44回の微小な出金を通じて、USDC側の流動性見積もりだけが不釣り合いに減少する丸めを利用しました。これにより「ゴースト流動性」が生まれ、過大なスワップと利益が可能になったのです。

教訓はこうです：単一操作では安全に見える丸めが、連続した操作では災害を引き起こす可能性があるということ。Bunniのポストモーテムでは、孤立していれば安全だった丸めが連鎖すると利用可能になると指摘されています。流動性プールを使うミームトークンプロジェクトは、マルチステップのシナリオを厳密にテストしてください。詳細はBunniのブログポストを参照: http://blog.bunni.xyz/posts/exploit-post-mortem/

Aztec Plonk Verifier '0 Bug': ゼロ知識の悪夢

Vishal Singhが指摘したのは、AztecのPlonk verifierに関する「0バグ」です。Plonkはプライバシー保護トランザクション向けのzk-SNARKで、このバグは楕円曲線上のゼロの扱い方やFiat-Shamirチャレンジの処理に起因して、証明を偽造可能にしていました。

要するに、Plonkの論文準拠で「0」を無限遠点として扱うかどうかの不明確さが、攻撃者にチャレンジや多項式を操作させ、不正な証明を通してしまう余地を与えていたのです。公開入力が完全にハッシュ化されていなかったため、偽造のための調整が可能になっていました。

これは双線形ペアリングや多項式コミットメントなど高度な暗号数学に関わる非常にトリッキーな問題です。プライバシー重視のミームトークンに関わるブロックチェーン実務者にとって、ZK技術の実装上の落とし穴を示すものです。バグは修正済みですが、詳細な解析はここを参照: https://github.com/cryptosubtlety/00/blob/main/00.pdf

MIM_Spell攻撃：シェア操作の妙技

Misbahuは、2024年1月のMIM_Spell（Abracadabra）攻撃に関する詳細スレッドを紹介しました。攻撃者は借入シェアの操作を通じて資金を奪いました。

Abracadabraは債務を追跡するためにsharesシステムを使っています：borrow sharesは固定され、資産は利息とともに増加します。repayForAllはシェアを変更せずに総資産を減らすことで比率を歪める操作をしてしまいました。

攻撃者はフラッシュローンで資金を用意し、ほとんどの債務を返済した後、微小な借入と返済をループして総シェアをほぼ無限大に膨らませ、資産を低く保ちました。これにより、プロトコルは彼らの負債シェアを誤評価し、最小限の担保で全てを借りられるようになったのです。

純粋な数学のトリックで、プロトコル側に有利な丸め（切り上げ）がループで裏目に出ました。重要な修正点は、borrow sharesが資産を下回らないようにすることです。フルスレッドはこちら: https://x.com/kankodu/status/1752581744803680680

Raydiumの致命的バグ群：tickと流動性の問題

BrainiacはおそらくRaydiumのCLMMに関する重大な脆弱性（2024年に修正されたtick操作バグなど）を挙げました。

あるケースでは、increase_liquidity関数が攻撃者にtick（価格レンジ）を操作させ、不正な流動性を追加させることでプールを枯渇させる可能性がありました。これはポジション更新における数学的ミスに関わるものでした。

Raydiumのコードは値の損失を避けるために明示的な丸め方向を持っていますが、sqrt_price_mathやliquidity_mathのバグは適切に扱われないとエクスプロイトにつながります。

SolanaベースのミームトークンでRaydiumを使う場合は、tick境界と数学ライブラリを徹底的に監査してください。

一般的な丸めの恐怖

TianCi_Clubは古典的な例を共有しました：丸めエラーで流動性プール全体が枯渇するケースです。こうした厄介なバグは、手数料計算やシェア換算で生じ、floorやceilの繰り返しがトランザクションを通じて損失を蓄積します。

ミームトークンの世界では変動性がトレードを増幅するため、こうした誤差が資金を急速に消し去ることがあります。ユーザー安全を優先した丸めを選び、極端なケースをシミュレートしましょう。

これらのエクスプロイトは、しばしば微妙な丸めや精度のずれといった数学的バグが、十分に監査されたプロトコルさえも崩壊させ得ることを示しています。ミームトークンの熱が高まる中、開発者はセキュリティを最優先すべきです—Spearbitのような監査会社を検討し、実世界の知見を得るためにこうしたスレッドを追い続けてください。あなたの見た中で最もワイルドなバグは何ですか？ コメントで共有してください！