【実務・中級編】ガス最適化とDoS攻撃のトレードオフ – IoT・OT（制御システム） & ブロックチェーンセキュリティ防御ガイド

スマートコントラクトにおける「ガス最適化」という名の罠：DoS攻撃を招く設計ミスを正す

現場でコードを叩いていると、「ガス代が高いから」という理由でループ処理を極限まで削ったり、複雑なロジックを無理やり1つのトランザクションに押し込もうとするエンジニアによく出くわす。その最適化、一見すると賢そうに見えるが、実はコントラクトを物理的に破壊するDoS攻撃の入り口になっていることに気づいているだろうか。

今回は、IoTや制御システムのような「止まってはならない」インフラ基盤をWeb3上で構築する際に陥りがちな、ガス制限を悪用したDoS攻撃のメカニズムと、それを防ぐための「泥臭い」設計思想について解説する。

—

1. なぜ「ガス最適化」がDoS攻撃を招くのか

スマートコントラクトには、1つのトランザクションで消費できるガス量（Block Gas Limit）という物理的な限界がある。攻撃者はこの限界を逆手に取り、コントラクトの処理を意図的にパンクさせる。

代表的なのが「配列の反復処理によるDoS」だ。例えば、ユーザーリストを配列で管理し、全員に報酬を分配するような関数を想像してほしい。

// 危険な実装例：ユーザーが増えるとガス代が跳ね上がり、いずれ処理不能になる
function distributeRewards() public {
    for (uint256 i = 0; i < userList.length; i++) {
        // 外部送金処理
        payable(userList[i]).transfer(1 ether); 
    }
}

ユーザーが100人、1000人と増えていくと、distributeRewardsを呼び出すために必要なガスがブロック上限を超えてしまう。攻撃者は、適当なアドレスを大量に登録してユーザー数を水増しするだけで、この関数を「二度と実行できない状態」に追い込める。これが、ガス制限を利用したDoS攻撃の正体だ。

—

2. 実務で使える「Pull型」パターンへの転換

この問題を解決する唯一の解は、「Push（押し付け）型」から「Pull（引き出し）型」への設計変更だ。サーバー側で一括処理するのではなく、個々のユーザーが自分のタイミングで報酬を引き出せるようにする。

セキュアな実装パターン（Solidity）

// 改善版：個々のユーザーが自分で引き出す設計
mapping(address => uint256) public pendingWithdrawals;

function distributeRewards(address[] memory users, uint256 amount) public onlyOwner {
    for (uint256 i = 0; i < users.length; i++) {
        // 全員に送金せず、各個人の残高を更新するだけにする
        pendingWithdrawals[users[i]] += amount;
    }
}

function withdraw() public {
    uint256 amount = pendingWithdrawals[msg.sender];
    require(amount > 0, "引き出し可能な残高がありません");
    
    // 再入攻撃を防ぐため、送金前に残高をクリアする（Checks-Effects-Interactions）
    pendingWithdrawals[msg.sender] = 0;
    payable(msg.sender).transfer(amount);
}

このように、ガス消費を一定に保ち、ループ処理をコントラクトのメインフローから排除することが、大規模なシステム運用において不可欠な鉄則だ。

—

3. インフラ側からの防御：WAFとレートリミットの重要性

ブロックチェーン上のロジックだけでなく、コントラクトを叩くWebフロントエンドやAPIサーバー側での防御も忘れてはならない。不正なリクエストをブロックするNginxの設定例を紹介する。

Nginxレートリミット設定（/etc/nginx/conf.d/limit.conf）

過剰なリクエストを抑制し、コントラクトの呼び出し頻度を制限することで、ガス代を浪費させる攻撃を水際で防ぐ。

# ユーザーごとのリクエスト制限（IP単位）
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

server {
    location /api/submit-transaction {
        # 毎秒10リクエストを超えたら429エラーを返す
        limit_req zone=api_limit burst=5 nodelay;
        proxy_pass http://backend_cluster;
    }
}

—

4. セキュリティリサーチャーからの助言

最後に、現場のエンジニアへ伝えたいことがある。

「ガスを節約する」こと自体は悪いことではない。しかし、それが「処理のスケール性を犠牲にする」こととトレードオフになっていないかを常に自問自答してほしい。

1. ループの上限を設ける: どうしてもループが必要なら、一度に処理する件数を制限し、複数回に分けて実行できる「ページネーション」機能を実装すること。
2. 外部呼び出しを慎重に行う: transferやcallなどの外部呼び出しは、ガス消費が激しく、かつ失敗のリスクを孕んでいる。必ずtry-catch的なエラーハンドリングを意識すること。
3. 監査を前提にする: どんなに美しいコードも、PoCを書いて攻撃してみなければ脆弱性は見抜けない。「自分が攻撃者ならどうやってこのコントラクトを詰まらせるか」を考える習慣を身につけてほしい。

Web3の世界では、一度デプロイしたコードは修正が困難だ。コードを書く前に、必ず「そのロジックが数千人規模のトラフィックに耐えうるか」という視点を持って設計にあたってほしい。それが、プロのエンジニアとしての最低限の流儀だ。