【テクニカル・上級編】ガス制限攻撃(DoS)の防止：ループ処理の制限とページネーション – IoT・OT（制御システム） & ブロックチェーンセキュリティ防御ガイド

ガス枯渇の深淵：スマートコントラクトにおける「無限のループ」を封殺するアーキテクチャ設計

SCADAの現場で、PLC（プログラマブルロジックコントローラ）のメモリバッファをパケットフラッドで溢れさせ、制御系をハングアップさせる手法を見たことがあるだろうか。あれと同じことが、イーサリアムのEVM（Ethereum Virtual Machine）上でも起きている。それが「ガス制限によるDoS攻撃」だ。

ブロックチェーンという分散型コンピューティングにおいて、計算リソース（ガス）は有限だ。コントラクト内のループ処理が、入力データ次第で「無制限」に膨らむ構造になっている場合、それは攻撃者にとって最高の射撃場となる。

今日は、教科書的な「ループを避けろ」という助言を一歩超えて、堅牢なアーキテクチャを設計するための「エンジニアの防衛術」について語ろう。

1. なぜ「配列の反復」は死を招くのか

スマートコントラクトで最も脆弱なパターンは、動的な配列をループで回して処理を行うことだ。例えば、ユーザーの保有資産を全走査して計算するような関数だ。

// 警告：これはDoS攻撃の標的となるアンチパターン
function claimAllRewards(address[] memory users) public {
    for (uint256 i = 0; i < users.length; i++) {
        // 外部コントラクト呼び出しや複雑な計算
        _distribute(users[i]); 
    }
}

この関数に、数千件のユーザーアドレスを詰め込んだトランザクションを送ってみよう。EVMのブロックガスリミットに達した瞬間、その関数は実行不能になる。一度ブロックガスリミットを超えてしまったデータ構造は、ガスをどれだけ積んでも処理できなくなる。これが、私たちが「ガス枯渇による恒久的なDoS」と呼ぶ状態だ。

2. ページネーションと「プル型」の強制

現場で求められるのは、処理を「小分けにする（ページネーション）」か、「ユーザーに個別に実行させる（プル型）」という設計思想の転換だ。

ページネーションの実装

以下のように、処理する範囲をインデックスで指定させる設計が標準であるべきだ。

// 改善版：オフセットとリミットを用いた安全な走査
function distributeRewards(uint256 offset, uint256 limit) external {
    uint256 length = users.length;
    // ガス消費を予測可能にするためのガードレール
    uint256 end = (offset + limit > length) ? length : offset + limit;

    for (uint256 i = offset; i < end; i++) {
        _distribute(users[i]);
    }
}

この実装であれば、フロントエンド側で limit を動的に調整し、ブロックのガスリミット内に収まるように処理を分割して送信できる。

3. IoT/OTセキュリティの文脈から見る「状態の非同期化」

SCADAのセキュリティアーキテクチャでは、制御系と監視系をネットワーク的に分離し、バッファオーバーフローを防ぐために「キューイング」を行う。これをスマートコントラクトに適用するなら、「計算を一度に完了させようとしない」ことだ。

複雑な計算が必要な場合は、データを一度コントラクト内の mapping（ハッシュテーブル）に保存し、処理の完了フラグを立てる。一度に全ての配列を走査するのではなく、トランザクションをまたいで状態を更新する設計にする。

状態管理の最適化例

struct BatchProcess {
    uint256 nextIndex;
    bool isCompleted;
}

// 処理を複数トランザクションに分割するステートマシン設計
function processBatch(uint256 batchSize) external {
    require(!processState.isCompleted, "既に完了しています");

    uint256 start = processState.nextIndex;
    uint256 end = start + batchSize;
    // ...処理ロジック...
    
    processState.nextIndex = end;
    if (end >= totalItems) {
        processState.isCompleted = true;
    }
}

4. 監査の観点：何を見抜くべきか

セキュリティリサーチャーとしてコードをレビューする際、私は以下のポイントを必ず確認する。

入力配列の長さ制限: 関数引数に array を取る場合、require(array.length <= 50) のようなハードリミットが設定されているか。
外部呼び出しのガス消費: ループ内の外部呼び出しが、予期せぬガス消費（GAS_LIMIT の変動）を招かないか。特に、呼び出し先が攻撃者によって制御可能なコントラクトであれば、リソース枯渇は必然だ。
ストレージアクセスのコスト: SSTORE 命令は非常に高コストだ。ループ内でのストレージ更新回数が、ガスリミットを圧迫していないか計算せよ。

最後に：防御の哲学

スマートコントラクトにおけるDoS防御とは、単なるコーディング規約ではない。それは「いかにしてシステムを、入力の悪意から独立して実行可能に保つか」という可用性の設計そのものだ。

耐量子暗号への移行や、ゼロ知識証明を用いた計算のオフチェーン化など、技術は常に進化している。しかし、どんなに技術が洗練されても、ループ処理の境界条件（Boundary Condition）を制御できないエンジニアは、必ず脆弱性という名のバグを埋め込む。

現場の泥臭いインシデントは、常に「想定外の大きなデータ」から始まる。皆さんの書くコードが、数年後も静かに稼働し続けることを願っている。攻撃者は常にあなたの「ループの終わり」を狙っていることを忘れないでほしい。