一份合约，怎样装下整个资产世界？

如果一个应用只发行一种可互换货币，ERC-20 很自然；如果它只管理一组逐件唯一的收藏品， ERC-721 很自然。可现实系统经常同时需要许多种资产，而且同一种资产还可能有许多份。

用 ERC-20 处理前两种资产，通常要为每种代币部署或维护独立合约；用 ERC-721 处理最后一种资产，token id 标识具体物品，但没有“同一 id 有 100 份”的余额概念。 ERC-1155 的提案正是为“一份系统里有很多 token type”设计：一份合约可以管理任意数量的 token id，每个 id 有自己的余额、供应和元数据。^[1]

合约地址回答“哪一本总账”，token id 回答“总账里的哪一种资产”，amount 回答“这个账户有多少”。

理解 ERC-1155 最重要的一行，不在转移函数，而在余额模型： 同一个账户对不同 id 分别拥有一个无符号整数余额。

这是一种帮助理解接口的逻辑模型，并非规范强制的 Solidity 存储布局；具体实现可以不同。

这张表解释了接口差异。ERC-20 的 balanceOf(account) 默认大家都在问同一种代币； ERC-1155 必须再传一个 id。ERC-721 的 ownerOf(tokenId) 直接问某件 唯一物品归谁；ERC-1155 则问“某账户拥有某类型多少份”。^{[2] [3]}

“供应量为 1”为什么还不够证明它永远是 NFT？

当前某个 id 的总供应量是 1，只能证明“现在观察到一份”。如果管理员明天还能对同一 id 再次 mint，它就不再具有永久唯一性。OpenZeppelin 的 ERC1155Supply 也明确提醒：totalSupply(id) == 1 可能意味着 NFT，但并不保证未来不会继续铸造。 ^[8]

选择标准不是评奖。稳定币通常需要整个 DeFi 生态熟悉的 ERC-20 接口； 逐件唯一、按单件授权和转移的收藏品常适合 ERC-721；大量异构资产共存、需要原生批处理时， ERC-1155 的二维模型更自然。

ERC-1155 的力量来自一组很小但组合良好的接口。注意：标准定义的是外部可交互行为， 并不规定“谁能铸造”“最大供应是多少”或“能否暂停”。

两个 Batch 函数都不是“随便塞一堆东西”

balanceOfBatch(accounts, ids) 按位置配对：结果第 i 项是 balanceOf(accounts[i], ids[i])，不是每个账户与每个 id 的笛卡尔积。 safeBatchTransferFrom(from, to, ids, values, data) 则把 ids[i] 与 values[i] 配对，并且整个批次只有同一个 from 与同一个 to；两组数组长度必须一致。 ^[1]

interface IERC1155 is IERC165 {
    function balanceOf(address account, uint256 id)
        external view returns (uint256);

    function balanceOfBatch(address[] calldata accounts, uint256[] calldata ids)
        external view returns (uint256[] memory);

    function safeTransferFrom(
        address from, address to, uint256 id, uint256 value, bytes calldata data
    ) external;

    function safeBatchTransferFrom(
        address from, address to,
        uint256[] calldata ids, uint256[] calldata values, bytes calldata data
    ) external;

    function setApprovalForAll(address operator, bool approved) external;
    function isApprovedForAll(address account, address operator)
        external view returns (bool);
}

ERC-1155 要求通过 ERC-165 报告核心接口支持，即 supportsInterface(0xd9b67a26) == true。这让钱包或合约先询问 “你会不会说 ERC-1155”，再选择正确的交互方式。^[4]

Alice 把金币、药水、季票和遗物一起交给一个市场托管合约。若资产分散在不同标准合约中， 通常需要多次 token-level 转移调用；在同一 ERC-1155 合约里，可以用一次 safeBatchTransferFrom 表达整个包。

为什么批量通常更高效，但不能写成“永远省 X%”？

多个 token type 共用一份合约，减少重复部署的字节码；批量转移还共享一次交易基础开销、 一次外部入口，并在一组循环中更新余额；OpenZeppelin 等常见实现通常共享一次批量回调。EIP-1155 因此说： 与为多个 token type 发送多笔单独交易相比，批量转移可以降低交易成本。 ^[1]

但费用不是标准常数。单一 id 转移时，safeTransferFrom 可能比构造长度为 1 的 batch 更合适；自定义存储、重复 id、接收方逻辑、冷/热存储访问、L1 或 L2 的费用结构都会改变结果。 正确说法是“ERC-1155 提供原生聚合机会”，不是“ERC-1155 每次都最便宜”。

把 token 发给一个不会处理它们的合约，资产可能永久卡住。ERC-1155 因此只有 safe 风格的 标准转移：若接收地址当前有代码，token 合约要调用接收钩子并验证明确的返回值。

单类型接收函数是 onERC1155Received，接受值为 0xf23a6e61；批量接收函数是 onERC1155BatchReceived， 接受值为 0xbc197c81。接收方也可以主动 revert 表示拒绝。 规范允许一次批量钩子，也允许以多次单项钩子覆盖所有余额变化；这里的互动模型展示前一种常见实现。 ^[1]

为什么“先更新、再回调”仍然要警惕重入？

回调是一次外部合约调用。接收合约在回调期间可能再次调用 token 合约或调用你系统里的其他函数。 标准要求相关余额与事件在回调前更新，符合 checks-effects-interactions 的基本方向；但你的自定义逻辑 如果在回调之后才维护关键状态，就可能暴露重入窗口。OpenZeppelin 5.x 文档因此不建议覆写 带 acceptance check 的内部函数，而建议把自定义状态逻辑放在 _update。 ^[7]

ERC-1155 核心没有 ERC-20 那种“给 spender 100 单位额度”，也没有 ERC-721 的单 token id 授权。标准授权入口是 setApprovalForAll(operator, approved)。

这种设计让一个市场只需获得一次授权，就能处理用户在该集合/世界中的多种资产； 也意味着恶意或被攻破的 operator 可能移动该合约内的全部 token type。授权事件 ApprovalForAll(owner, operator, approved) 必须记录开启或关闭。 ^[1]

多资产合约若为每个 id 重复保存完整 URL，会增加链上存储。ERC-1155 的可选 Metadata URI 扩展允许所有 token type 共享一个包含 {id} 的模板。

客户端遇到 URI 或元数据 JSON 值中的 {id} 时，必须用 64 个十六进制字符替换： 只用 0-9a-f，不带 0x，左侧补零。标准元数据 JSON 可以包含 name、description、image，也有可选 decimals 字段用于显示数量的小数位。^[1]

链上的 token，为什么画面仍可能被改？

合约通常只返回 URI；名称、描述和图片可能位于普通 HTTPS 服务器或可变的内容入口。 若管理员能改 base URI、服务器能替换 JSON，用户界面看到的内容就可能改变。 选择 IPFS 等内容寻址存储、冻结 URI、把 JSON 作为 data URI 放到链上，能改变信任边界， 但成本和可更新性也不同。OpenZeppelin 官方指南特别提醒：元数据不在链上时，开发者可以改变底层信息。 ^[6]

下面是一份教学骨架：金币与季票可以按策略增发；唯一资产使用独立 id，并用永久 uniqueIdUsed 记录防止销毁后重铸。它展示边界，不是未经审计即可上线的产品。

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

import {ERC1155} from
    "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";
import {ERC1155Supply} from
    "@openzeppelin/contracts/token/ERC1155/extensions/ERC1155Supply.sol";
import {Ownable} from
    "@openzeppelin/contracts/access/Ownable.sol";

contract WorldItems is ERC1155Supply, Ownable {
    uint256 public constant GOLD = 1;
    uint256 public constant SEASON_PASS = 7;
    mapping(uint256 id => bool) private uniqueIdUsed;

    constructor()
        ERC1155("ipfs://bafy.../{id}.json")
        Ownable(msg.sender)
    {
        _mint(msg.sender, GOLD, 1_000_000, "");
        _mint(msg.sender, SEASON_PASS, 500, "");
    }

    function mintFungible(
        address to,
        uint256 id,
        uint256 amount
    ) external onlyOwner {
        require(id == GOLD || id == SEASON_PASS, "restricted id");
        _mint(to, id, amount, "");
    }

    function mintUnique(address to, uint256 id) external onlyOwner {
        require(id >= 1_000_000, "unique id range");
        require(!uniqueIdUsed[id], "id permanently used");
        uniqueIdUsed[id] = true;
        _mint(to, id, 1, "");
    }

    function burn(uint256 id, uint256 amount) external {
        _burn(msg.sender, id, amount);
    }
}

逐行看真正的安全假设

1. ERC1155Supply 是扩展，不是核心保证 它跟踪每个 id 的 totalSupply 和 exists；不能从所有 ERC-1155 合约假设这些函数存在。
2. onlyOwner 决定谁能增加供应 部署者私钥、代理升级管理员或角色合约若被攻破，供应规则也会被改写。
3. 常量只固定 id，不固定供应 GOLD = 1 只是编号；真正的供应来自每次 _mint 与 _burn 的累计结果。
4. 唯一 id 需要永久使用记录 只检查 totalSupply(id) == 0 会允许销毁后再次铸造；永久映射把“曾经使用”也纳入约束。
5. 接收钩子仍会执行 _mint 给合约地址时也要通过 receiver acceptance check；接收方可以拒绝或触发回调逻辑。

OpenZeppelin 的基础实现使用 mapping(uint256 id => mapping(address account => uint256)) 存余额，并把 operator 授权存为 owner 与 operator 的二维映射。它提供内部 _mint、_mintBatch、_burn、_burnBatch， 由应用决定如何安全暴露。^[5]

ERC-1155 为减轻合约存储，不要求提供“列出所有 id”或“列出某账户全部资产”的核心函数。 区块浏览器、市场与钱包通常从部署区块开始监听事件，在链下数据库中维护 token id、供应和 URI。

标准要求所有余额变化——包括零值转移、创建与销毁——发出 TransferSingle 或 TransferBatch；事件必须足以让观察者重建当前余额。 若要宣布一个尚无初始余额的新 id，规范建议从零地址向零地址发出 value 为 0 的 TransferSingle。^[1]

面对任何 ERC-1155 合约，用这八问完成第一轮审计

1. 这是什么链、哪个合约、哪个 id？ 名称和图片可能重名；完整身份至少需要 chain id、contract address 与 token id。
2. 该 id 的供应不变量是什么？ 查当前总量、上限、是否可增发、是否可销毁、销毁后能否重铸，以及约束是否真的在代码里。
3. 谁持有 mint、pause、URI 与 upgrade 权限？ 标准没有规定这些角色；owner、多签、Timelock、代理管理员都可能改变资产含义。
4. ApprovalForAll 会暴露哪些 id？ 枚举 owner 在这份合约中的所有资产，不要只看当前准备交易的那一件。
5. 接收钩子是否产生外部调用风险？ 检查回调前后状态、重入保护、转发逻辑，以及合约是否有安全的出库路径。
6. 批量数组的语义是否被正确验证？ ids 与 values 必须同长且按位置配对；自定义逻辑不要错误假设 id 一定唯一或已排序。
7. 元数据在哪里，谁能改变？ 追踪 base URI、内容哈希、服务器、IPFS pin、链上 data URI 与管理员更新路径。
8. 索引器的视图能否与链上余额对账？ 用 balanceOf/Batch 抽样复核事件数据库，处理重组、部署起点和代理升级后的事件连续性。

六题自检

token type

ERC-1155 中由一个 uint256 id 标识的资产类别；同一 id 可有任意数量余额。

operator

经 owner 授权、可以代表其转移同一 ERC-1155 合约内 token 的地址。

batch

在一个标准调用里按位置处理多组 id/value 或 account/id 配对。

magic value

receiver hook 必须返回的 bytes4 常量，用明确响应证明接收合约理解并接受 token。

mint / burn

供应增加/减少；通过 Transfer 事件中零地址作为 from/to 表达，但公共入口由实现决定。

indexer

扫描链上事件并建立可搜索数据库的系统；帮助发现 token id，但不替代合约状态验证。

1. 01
   ERC-1155 · Multi Token Standard

   核心规范：函数、事件、safe transfer、receiver、URI 替换、审批、批量能力与事件可追溯性。

2. 02
   ERC-20 · Token Standard

   同质化代币的 balance、transfer、allowance 与事件基线，用于比较一维余额模型。

3. 03
   ERC-721 · Non-Fungible Token Standard

   逐件唯一资产、ownerOf、单件授权与 safe receiver 的规范基线。

4. 04
   ERC-165 · Standard Interface Detection

   supportsInterface 与 interface id 的定义；ERC-1155 依赖它发布接口能力。

5. 05
   OpenZeppelin Contracts v5.6.1 · ERC1155.sol

   锁定发布版本的官方实现，可核对二维余额、operator approval、URI、更新与接收检查的实际代码结构。

6. 06
   OpenZeppelin Contracts 5.x · ERC-1155 Guide

   多代币模型、创建、URI、发送给合约与 ERC1155Holder 的官方教学说明。

7. 07
   OpenZeppelin Contracts 5.x · ERC1155 API

   当前 5.x 函数、扩展、错误、acceptance check 与重入注意事项的 API 参考。

8. 08
   OpenZeppelin Contracts 5.x · ERC1155Supply

   每 id 供应跟踪、exists，以及“供应为 1 不保证未来不会继续铸造”的明确边界。

9. 09
   ethereum.org · Token Standards

   以太坊开发者文档对 ERC-20、ERC-721、ERC-1155 及其组合与批量价值的概览。