【入門編】 ZK Rollupにおける回路(Circuit)のバグと証明検証の脆弱性 – IoT・OT（制御システム） & ブロックチェーンセキュリティ防御ガイド

こんにちは！新人ITエンジニアの皆さん、そしてブロックチェーンや最先端のセキュリティの世界へ足を踏み入れたばかりの皆さん、日々の開発やインプレッションの学習、本当にお疲れ様です。

「スマートコントラクト」「ゼロ知識証明」「ZK Rollup」……。なんだか映画のタイトルやSF小説に出てきそうな、すごく難しそうな言葉が並んでいますよね。「自分にはまだ早いかも……」なんて思っていませんか？大丈夫です！一歩ずつ、身近な例えから紐解いていけば、必ず本質が見えてきますよ。

今回は、現代のブロックチェーン技術で最もホットかつ、一歩間違えると大惨事になりかねない「ZK Rollupにおける回路（Circuit）のバグと証明検証の脆弱性」について、泥臭い現実のインシデントの匂いも交えつつ、優しく解説していきますね。

—

1. 家の鍵と「秘密の暗号パズル」で理解するZK Rollup

まずは、難しい数式を一切使わずに、この技術の仕組みをイメージしてみましょう。

皆さんが住んでいる「家の鍵」を想像してください。あなたが家に入るとき、普通は鍵穴に本物の鍵を挿して回しますよね。でも、もし「私はこの家の合法的住人です」ということを証明するために、鍵そのものを見せずに、ドアの向こう側で複雑なパズルを解いてみせたらどうでしょう？ 外にいる大家さんは、あなたがパズルを解いたという事実（＝正解の証明）だけを見て、「あ、この人は本物の住人だな」とノーリスクで確信できます。

これがゼロ知識証明（Zero-Knowledge Proof: ZKP）の基本概念です。「中身（秘密）を見せずに、それが正しいことだけを証明する」という魔法のような技術ですね。

そして、この魔法を使って、ブロックチェーンの外（オフチェーン）で何千人もの取引をまとめて計算し、その「正しい結果の証明書」だけをブロックチェーン（オンチェーン）に提出する仕組みが ZK Rollup（ゼロ知識ロールアップ） です。手数料を安く、かつ爆速にするための最先端の仕組みとして、今のWeb3界隈で引っ張りだこになっています。

—

2. 攻撃者はどこを狙う？回路（Circuit）のバグとは

さて、ここからがセキュリティリサーチャーとしての本題です。
ZK Rollupの心臓部には、取引が正しいルールで行われたかを検証するための「演算回路（Circuit）」というプログラムが存在します。数学的な論理ゲートの塊のようなものです。

もし、この回路の設計図に「ほんの小さな書き間違い」があったらどうなるでしょうか？

例えば、家の鍵のパズルを作る際、設計図をうっかり間違えて「鍵の歯が1本足りなくても、なぜかドアが開いてしまうバグ」を作ってしまったとします。正当な住人はもちろん入れますが、もし泥棒がそのバグ（抜け穴）に気づいたら……？そう、泥棒は不正な鍵で簡単に家に入り込み、中の資産を根こそぎ盗み出すことができますよね。

ZK Rollupの回路バグもこれと全く同じです。

資産流出のリスク： 攻撃者が不正な取引（自分に大量のトークンを送るなど）を含んだデータを作り、それが「正しい」というニセの証明書を生成して検証コントラクトを言くるめてしまう。結果、プールされていたユーザーの資産がすべて抜き取られる。
資産凍結のリスク： 回路の論理破綻やエラーハンドリングの不備により、正当な取引データですら「不正」と判定されてしまい、二度と引き出せなくなる（ゴーストタウン状態になる）。

現場のエンジニアにとって、回路のバグは「数式ベースのバグ」であるがゆえに、通常のWebアプリのバグ（SQLインジェクションやXSSなど）よりも発見が難しく、見逃されたときのダメージが文字通り致命的になるという特徴があります。

—

3. 実践！検証コントラクトの脆弱性をコードで見てみよう

それでは、ブロックチェーン側（イーサリアムなど）で、ZK証明を受け取る「検証スマートコントラクト」のイメージをコードで覗いてみましょう。

今回はSolidityという言語で書かれた、ありがちな「チェック漏れ」のサンプルを見てみます。一歩ずつ、コメントを読みながら確認していきましょう。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

/**
 * @title 脆弱性を含んだZK検証コントラクトの例
 * @notice 新人の皆さんは「どこが危ないか」を一緒に探してみましょう！
 */
contract VulnerableVerifier {

    // 最後に検証された状態のハッシュ値
    bytes32 public currentStateRoot;

    // 外部の数学的検証ライブラリ（実際にはcircomなどで生成されたペアリング検証等が入る）
    address public immutable groth16Verifier;

    constructor(address _verifier) {
        groth16Verifier = _verifier;
    }

    /**
     * @notice ロールアップのバッチを検証し、状態を更新する関数
     * @param _proof ゼロ知識証明のバイナリデータ
     * @param _publicInputs 証明に対する公開入力（前の状態、次の状態など）
     */
    function submitBatch(
        bytes calldata _proof, 
        uint256[] calldata _publicInputs
    ) external {
        
        // 【脆弱性のポイント！】
        // 配列の長さ（Length）や、特定のインデックスの存在チェックをサボっていませんか？
        // 攻撃者が空の配列や、細工されたデータを渡してきた場合のバリデーションが抜けています。
        
        // 数学的な証明が正しいかを外部コントラクトに問い合わせる
        bool isValid = IVerifier(groth16Verifier).verifyProof(_proof, _publicInputs);
        
        require(isValid, "Invalid ZK Proof: 証明が無効です！");

        // 状態を更新（_publicInputs[1]が次の状態ルートだと仮定）
        // ※ ここでインデックスの範囲外アクセス（Index Out of Bounds）の考慮がないと危ない
        currentStateRoot = bytes32(_publicInputs[1]);
    }
}

// 外部の検証インターフェース
interface IVerifier {
    function verifyProof(bytes calldata, uint256[] calldata) external view returns (bool);
}

何が問題だったのでしょうか？

上記のコードの恐ろしいところは、IVerifier 自体が正しく動いていたとしても、呼び出し側の submitBatch 関数で _publicInputs の中身のバリデーション（長さのチェックや範囲確認）が欠落している点 です。

攻撃者は、配列の要素数を意図的に改変したり、ダミーのデータを差し込むことで、検証ロジックをバイパスし、不当に currentStateRoot を書き換えてしまう可能性があります。現実のインシデントでも、「数学的な証明そのものは完璧だったのに、それを囲むスマートコントラクトの接着部分（グルーコード）のバグでハッキングされた」というケースが後を絶ちません。

—

4. 安全な開発に向けた対策と心構え

では、こうしたZK回路や検証コントラクトのバグから身を守るために、私たちはどう行動すればよいのでしょうか？一歩ずつ、実践的な対策を学んでいきましょう！

1. 徹底的なFuzzing（ファジング）とテスト自動化

回路のテストには、普通のユニットテストだけでは不十分です。ランダムな入力値を何百万回も流し込んで回路が破綻しないかを確かめる「ファジングツール」や、SMTsolver（数式ソルバー）を用いた形式検証（Formal Verification）を必ずパイプラインに組み込みましょう。

2. マルチプル・オーディット（複数の外部監査）の実施

ZKのセキュリティは専門性が極めて高いため、社内のレビューだけで済ませるのは非常に危険です。最低でも2社以上の信頼できるWeb3セキュリティ専門ファームにコードレビューを依頼するのが業界の標準（デファクトスタンダード）です。

3. 多層防御（Defense in Depth）の思想を忘れない

「ゼロ知識証明があるから絶対に安全だ」と過信せず、オンチェーン側でもタイムロック（Time-lock：不正な更新があっても直ちに反映されず、数日間の猶予期間を設ける仕組み）や、不正を検知して一時停止する「サーキットブレーカー（Emergency Stop）」を必ず実装しておきましょう。家の鍵だけでなく、防犯カメラや二重ロックをかけるのと同じ発想ですね。

—

まとめ

今回は、ZK Rollupにおける回路のバグと証明検証の脆弱性について、身近な例えと具体的なコードを交えて解説しました。

難解に見える最先端技術も、「正しさを証明する仕組みのどこかに、人間の書き間違いや想定外の抜け穴がないかを探す」というセキュリティの本質は、いつの時代も変わりません。

新人の皆さん、最初は分からないことばかりで圧倒されるかもしれませんが、焦る必要は全くありません。「なぜこのコードはこういう書き方をしているんだろう？」「もし意図しない変数が渡されたらどうなるだろう？」という疑う目と好奇心を大切に、一歩ずつ安全なコードを書けるエンジニアを目指していきましょう！

それでは、次のセキュリティ解説記事でお会いしましょう！