こんにちは！日々、ブロックチェーンやIoTの世界で奮闘されている新人のIT担当者や開発者の皆さん、セキュリティ対策に頭を悩ませていませんか？
「ゼロ知識証明（ZK-Rollup）」や「スマートコントラクト」といった最先端の言葉を聞くと、なんだか難解で自分には関係ない壁のように感じてしまいますよね。でも、安心してください。セキュリティの根底にある考え方は、私たちが普段暮らしている現実世界の防犯とまったく同じなんです。
今回は、最先端のブロックチェーン技術であるZK-Rollupの回路設計に潜む、「算術演算のオーバーフロー（桁あふれ）」というちょっぴり怖い、けれど仕組みが分かれば対策できる脆弱性について、身近な例えを交えながら一歩ずつ優しく紐解いていきましょう！
—
1. 家の鍵と「回転式ダイヤル錠」で考えてみるオーバーフロー
まずは、セキュリティの基本をイメージするために、身の回りの防犯の仕組みを思い出してみましょう。
皆さんのご近所や、古い自転車のチェーンロックなどで、数字をクルクル回して合わせる「ダイヤル式の鍵」を見たことはありませんか？
例えば、3桁のダイヤル錠があったとします。この鍵で表現できる数字は 000 から 999 までですよね。では、この鍵が 999 を指している状態で、さらに無理やり「＋1」回したらどうなるでしょうか？
そう、鍵は一周して 000 に戻ってしまいますよね。
現実世界であれば「あ、一周しちゃったな」と気づくことができますし、壊れたりもします。しかし、コンピュータの世界、特にブロックチェーンの計算を行う「回路（Constraint System：制約システム）」の中では、この「一周して元に戻ってしまう現象」が、時として大泥棒を招き入れる致命的な隙（脆弱性）になってしまうのです。
これが、今回お話しする「算術演算のオーバーフロー」です。
—
2. ZK-Rollupの回路で何が起きているのか？
「ZK-Rollup（ゼロ知識ロールアップ）」は、たくさんの取引をまとめて小さく圧縮し、ブロックチェーンの混雑や手数料を解消する素晴らしい技術です。この技術の裏側では、「この計算は正しく行われましたよ」という証明書を作るために、複雑な「数学の回路（スマートコントラクトの回路）」が動いています。
この回路の中では、現実のパソコンのように無限に大きな数字を扱えるわけではありません。あらかじめ決められた「有限の範囲（有限体）」の中で計算が行われます。
ここで想像してみてください。
悪意ある攻撃者が、この回路に対して「わざと計算結果が上限を超えて一周してしまう（オーバーフローする）ような巨大な数値」を入力したとします。
- 本来のルール：所持金は
0以上100以下でなければならない。 - 攻撃のトリック：上限ギリギリの計算を仕掛け、計算結果をオーバーフローさせて、マイナスの数字を裏側のシステムに「ものすごく大きなプラスの数字」として誤認させる。
回路の設計が甘く、この「数字が一周してしまったこと」を厳密にチェック（制約）していないと、回路は「おっ、正しい計算結果ですね！」と勘違いして、本来は通してはいけない不正な取引の証明書を発行してしまうのです。
家で例えるなら、ダイヤル錠を力技で一周させて、本来開かないはずの扉の鍵を「正しく解錠された」とシステムに誤認させるようなものですね。怖いですよね……！
—
3. 実装コードで見る脆弱性と安全な設計
それでは、実際のスマートコントラクトやZK回路の擬似コードを使って、何がダメで、どう直すべきなのかを見ていきましょう。
以下の例は、CircomなどのZK回路言語をイメージした、ユーザーの残高と引き出し額を計算するシンプルなコードの断片です。
❌ 危険な実装例（オーバーフローを見逃してしまう回路）
// 【危険】単純に引き算のチェックだけをしている回路
template WithdrawCheck() {
signal input currentBalance; // 現在の残高
signal input withdrawAmount; // 引き出し額
signal output newBalance; // 新しい残高
// 単に引き算をしているだけ
// ここで withdrawAmount が currentBalance より大きいと…？
newBalance <== currentBalance - withdrawAmount;
// 「新しい残高は0以上であること」の制約が抜けている！
}このコードの何が問題か分かりますか？
もし currentBalance が 10 で、withdrawAmount が 15 だった場合、通常のプログラミング言語ならエラーになります。しかし、有限体を扱う回路の中では、これが「マイナス5」ではなく、「てっぺんを超えて巨大なプラスの数字（アンダーフロー）」として計算されてしまい、不正に大金を引き出したことになってしまうのです。
⭕ 安全な実装例（ビット長と範囲を厳格に制限する回路）
安全な回路を作るためには、「計算結果が想定外の範囲になっていないか」を一つひとつ厳しく監視（制約）する必要があります。一歩ずつ対策を学んでいきましょう！
// 【安全】ビット長と範囲を厳格にチェックする回路
include "./comparators.circom"; // 比較用のライブラリ
template SafeWithdrawCheck() {
signal input currentBalance;
signal input withdrawAmount;
signal output newBalance;
// 1. 引き出し額が現在の残高以下であることを強制する制約
// （currentBalance - withdrawAmount がマイナスにならないことを証明する）
component leq = LessEqThan(252); // 252ビットの範囲で比較
leq.in[0] <== withdrawAmount;
leq.in[1] <== currentBalance;
leq.out === 1; // 必ず「以下（真）」であることを要求する
// 2. 安全に引き算を実行
newBalance <== currentBalance - withdrawAmount;
// 3. 【重要】結果のビット長（範囲）が想定内であることを明示的に制約する
// これにより、意図しないオーバーフローや桁あふれを完全にブロックします
signal isPositive;
isPositive <-- newBalance >= 0 ? 1 : 0;
isPositive === 1;
}このように、「計算する前後の値が、人間の想定する常識的な範囲（ビット長）に収まっているか」を回路のルール（制約）としてガチガチに固めておくことが、ZK-Rollupセキュリティの最大の肝になります。
—
4. 現場のインシデントハンドリングから学ぶ教訓
私たちセキュリティリサーチャーが実際の現場（Web3プロジェクトの監査など）でスマートコントラクトやZK回路をレビューするとき、一番最初に疑うのは「開発者が『人間は常識的な数字しか入力しないだろう』と性善説に立っていないか」という点です。
サイバー攻撃者は、私たちが想像もしないような巨大な数値を送り込んできたり、境界値（0や最大値など）の隙間を縫うように攻撃を仕掛けてきます。
もし、皆さんの開発するシステムや回路で不審な挙動や、計算結果のズレを見つけたら、以下の手順で迅速にインシデント対応を行ってください。
1. 回路の実行停止（可能であれば）：被害が拡大する前に、ブリッジやコントラクトの一時停止機能を検討する。
2. 制約システム（Constraint System）の監査：すべての入力値（Signal）に対して、ビット長や上限・下限のチェック（Range Proof）が漏れていないか全数調査する。
3. テストケースの強化：あえて「オーバーフローギリギリの数値」や「マイナスになる不正な数値」を大量に流し込むファジングテスト（Fuzzing）を必ず実施する。
—
おわりに：一歩ずつ、セキュアな開発者へ！
今回は、ZK-Rollupの回路設計における算術演算のオーバーフローについて、家の鍵やダイヤル錠の例えを交えて解説しました。
最初は難しく見えた「制約システム」や「有限体」という言葉も、蓋を開けてみれば「数字が一周してズルされないように、しっかり見張りのルールを作ろう！」という、とてもシンプルな防犯の基本に行き着くことが分かっていただけたのではないでしょうか。
セキュリティは一朝一夕にはマスターできませんが、こうした日々の小さな気づきと丁寧な実装の積み重ねが、あなた自身とユーザーの大切な資産を守る最強の盾になります。
それでは、今日も安全で素晴らしい開発ライフを！一緒に一歩ずつ進んでいきましょう！
コメント