Arbitrum API：在以太坊 Layer 2 上进行 ERC-20 支付

Arbitrum 是一个乐观 rollup。交易在 Arbitrum 自己的基础设施上执行，网络将压缩后的交易数据发布到以太坊，任何人都可以根据链上数据重建 L2 的状态。「乐观」描述的是安全模型：状态更新在发布时被假定为有效，随后进入一个挑战窗口，期间任何观察者都可以针对不正确的更新提交欺诈证明。以太坊充当争议的仲裁者。由于底层数据存放在以太坊上，作弊无法被隐藏，L2 继承了 L1 的安全性，而不必自行建立一套验证者集合。

这一设计也解释了费用结构。一笔 Arbitrum 手续费支付两部分：L2 上的执行（成本低廉），以及该交易在向以太坊发布批量数据中所占的份额。自 2024 年 3 月起，这些数据进入了 EIP-4844 引入的 blob 空间，使发布成本降低了约 90%，并在 2025 年和 2026 年将典型的 Arbitrum 手续费维持在几美分以下。数百笔转账共享一个批次，因此每笔转账只承担 L1 成本中极小的一部分，而不是完整的 L1 交易手续费。

存在两条公开的 Arbitrum 链，名称经常被混淆。Arbitrum One 就是上面描述的 rollup：所有交易数据都落在以太坊上，信任假设归结为以太坊自身的信任假设。Arbitrum Nova 则运行 AnyTrust 协议。它的交易数据由一个数据可用性委员会（Data Availability Committee）链下持有，只要该委员会中至少有两名成员诚实行事，系统就保持稳固；如果委员会未能提供数据，链会回退到完整 rollup 模式。将数据保留在以太坊之外让 Nova 再度变得更便宜，代价是多了这一层信任假设。

在实践中这种划分很清晰。Nova 承载游戏和社交类应用，这类工作负载交易数量极多、单笔价值很低，委员会带来的权衡是可以接受的。Arbitrum One 承载 DeFi 协议、稳定币流动性和交易所支持。当一个支付集成、交易所提现页面或本文在没有限定词的情况下说「Arbitrum」时，指的就是 Arbitrum One。这是你用户的 USDC 和 USDT 实际存放的链。

整个 2026 年，在以太坊主网上一笔 ERC-20 转账的费用在 1 到 20 美元之间浮动，取决于网络拥堵程度。同样的转账在 Arbitrum 上大约只需两到二十美分——大约低两个数量级，因为大部分手续费用于成本低廉的 Layer 2 执行，而不是以太坊 gas。

两条链都是动态定价，所以绝对数字会随 ETH 价格和网络负载波动，但主网上的 gas 拍卖机制会恰好在活动高峰期让手续费飙升——这对支付业务来说是最糟糕的相关性。大约两个数量级的比例才是稳定不变的部分。

对支付后端来说，比例比任何一个绝对数字都更重要，因为支付操作会成倍放大手续费。一笔客户存款意味着一笔转入、一次清扫进热钱包，最终还有一笔转出付款：一次付款对应三次手续费事件。在主网价格下，团队的应对方式是批量清扫、延迟付款，而被延迟的资金则表现为分散在各个存款钱包中被搁置的营运资金。在 Arbitrum 价格下，你可以按计划清扫、按需付款，手续费这一行会淹没在会计噪音之中。

小额支付也重新变得可行。L1 上一笔十美元的转账在糟糕的一天可能因 gas 损失两位数百分比，这也是为什么没有人在主网上给任何东西标价十美元。在 Arbitrum 上，同样的转账只损失百分之几个点的零头。按笔计费、按用量计费和小额退款，从经济上荒谬变成了不起眼的小事。

Arbitrum 完全兼容 EVM，对支付而言这句话有精确的含义：同样的 0x 地址格式，同样的 EIP-55 校验和，同样的 ERC-20 合约接口，同样的签名方案。部署在 Arbitrum 上的代币合约暴露的 transfer 函数与其主网上的对应版本完全相同。代币标准本身没有为 L2 重新发明任何东西，这也是为什么为以太坊构建的钱包、区块浏览器和库，只需更换 RPC 端点就能处理 Arbitrum，无需其他改动。

通过 API，这一切浓缩为一个路径片段。POST /api/v2/ethereum/transactions/erc20 和 POST /api/v2/arbitrum/transactions/erc20 接受完全相同的请求体：合约地址、from、to、amount。你的校验逻辑、Webhook 处理程序和数据库结构可以原样保留，因为两条链上的地址和交易哈希形式相同。带来的实际好处可以直白地说清楚：同一个 API 调用，换一条链。已经通过 Chaingateway 运行以太坊的团队，通常一个下午就能加上 Arbitrum，把「链」变成配置表中的一列，而不是代码中的一个分支。

有一件事无法直接沿用：余额。这是下一节的内容。

一个 ERC-20 余额是某条特定链上合约内部的一条记录。以太坊上的 USDT 和 Arbitrum 上的 USDT 是两条不同的合约记录，持有其中一个并不能让你获得另一个。在你的热钱包能在 Arbitrum 上发送代币之前，这些代币必须先存在于 Arbitrum 上。API 无法凭空把它们搬过去；没有任何 API 能做到这一点。

有两条常见途径能把代币送到那里。Arbitrum 跨链桥在以太坊上锁定代币，并在 L2 上铸造其对应的代表资产。同样的机制反过来运行，用于提现回 L1，而这个方向包含挑战窗口，因此通过官方跨链桥把价值转回以太坊大约需要一周时间，除非你付费给第三方的快速跨链桥来垫付流动性。对大多数运营者来说更简单的途径是：从支持 Arbitrum 提现的交易所直接提现，一步就能把代币放到 L2 上，完全跳过跨链桥的机制。

也要为 gas 做好预算。Arbitrum 上的手续费以 ETH 支付，因此热钱包在持有代币的同时也需要在 L2 上保留少量 ETH 余额。金额很小，每笔转账只需几美分，但一个持有代币却没有 ETH 的钱包完全无法转账，这种失败模式应该在被写进事后复盘之前，先触发一条监控告警。

Arbitrum 的出块速度远低于一秒，因此存款几乎在用户发送后立刻就能被看到。Chaingateway 会把这一事件转发到你的后端，而不是让你去轮询。在你的账户中设置一个私密密钥后，每次 Webhook 投递都会携带一个 X-Signature 请求头——对 payload 中 txid 字段做 HMAC-SHA256 并用 base64 编码的结果——让你可以验证它确实来自 Chaingateway。投递失败的通知会保留在失败通知列表中，可以通过 POST /api/v2/arbitrum/webhooks/notifications/{id}/retry 重新发送。

GET /api/v2/arbitrum/webhooks/notifications 返回投递历史，便于审计，或者在你这边发生停机后重放事件。Webhook 指南介绍了设置方法和签名验证。

一个具体的、从头到尾的存款流程。每位客户都拥有自己专属的存款地址，这使得传入付款无需用户经常忘记填写的备注字段即可归属清晰。你通过 Webhook 监控这些地址，而监控本身不需要任何密钥。

从存款到入账

一位客户从其交易所账户发送 200 USDC，并选择 Arbitrum 作为提现网络。区块在远低于一秒的时间内落地，因此转账几乎立刻上链，Chaingateway 会向你的接口发送这一事件的 POST 请求。你的处理程序验证 HMAC 签名，将代币合约与白名单核对，并将该笔存款记录为待处理。一旦存款满足你自己的确认策略，该记录就切换为已入账。在这样快速的链上，客户会把整个过程体验为即时完成，这在收银环节是有价值的：「已收到付款」是在用户开始怀疑是否成功之前出现，还是之后出现，这中间的差别很重要。

清扫与付款

接下来是那些曾经因为 L1 手续费而令人头疼的日常事务。按计划，或者每当某个余额超过阈值时，你通过 POST /api/v2/arbitrum/transactions/erc20 把存款从存款地址清扫进热钱包。由于每次清扫只需几美分，这可以按小时执行而不是按周执行，让资金集中在付款流程能够触达的地方，而不是零散分布在成百上千个地址上。提现是同一个调用，方向相反：从热钱包到客户地址。这套流程中除了路径片段和手续费水平之外，没有任何东西是 Arbitrum 特有的，而正是手续费水平让按小时的清扫计划变得可以承受。

完全兼容 EVM 意味着以太坊方面的知识可以一对一迁移：地址校验和、代币合约以及签名行为都与主网完全一致。手续费只是以太坊 L1 的一小部分，这让小额转账从亏损变成了可以忽略的舍入误差。安全性来源于以太坊本身，因为交易数据被发布到 L1，错误的状态可以在那里被挑战。而且这个生态并不是对未来的押注：大型 DeFi 协议今天就在 Arbitrum 上生产运行，因此流动性、区块浏览器和钱包支持已经存在。

Chaingateway 支持 Arbitrum 上的标准代币，包括成熟的稳定币，也包括跨链桥接的资产和自定义发行的代币。集成方式在每条受支持的链上都是一样的：构建一次，扩展时把同一份代码指向 /api/v2/ethereum/、/api/v2/polygon/ 或 /api/v2/bsc/。blockchain API 总览列出了全部七条链。

这些应用场景与其他 EVM 链相同：几秒内即可结算的稳定币收银流程、交易平台的存款监控、来自热钱包的提现处理、空投和归属付款、SaaS 的周期性计费、跨境转账。Arbitrum 突出的地方在于那些被主网价格挤出局的场景——微支付、高频清扫，以及每个都需要偶尔维护交易的按用户存款地址。

大多数团队并不是从零开始构建 Arbitrum 支持。他们是把它作为第二条链加到已有的 Chaingateway 集成中，复用同一代码路径，按请求切换链。

为任意请求添加 X-Network: testnet，它就会运行在测试网络上；Arbitrum 的公共测试网是 Arbitrum Sepolia，测试用 ETH 可以从水龙头免费获取。路径、请求体和响应结构都不会改变，因此你演练用的代码与最终上线的代码逐字节相同。

在上主网之前，至少完整跑一遍存款周期：传入转账、Webhook 投递、签名验证、清扫。值得提前发现的错误——例如处理程序在错误的 payload 字段上计算 HMAC，或者接口被负载均衡器超时中断——在测试网和生产环境中的表现完全一致。唯一的区别是它们让你付出的代价。上线只是删除那一个请求头。

客户端错误和服务器错误需要相反的处理方式。4xx 意味着请求本身有问题——令牌过期、地址格式错误、钱包无法覆盖的金额——重试相同的请求只会重复这个拒绝；记录下来并修正输入。5xx 或网络超时不能说明你的输入有任何问题，所以应使用指数退避加上限进行重试。

真正值得为之设计的情形是发送操作中那种模棱两可的超时。你的 HTTP 客户端放弃了，但转账可能其实已经发出去了，盲目地重发正是重复付款的成因。在重试任何转账之前，先检查实际发出去了什么——GET /api/v2/arbitrum/transactions 列出了通过 API 创建的转账——只有在能确认第一次尝试确实失败时才重新发送。从第一天起就把这项检查内置到付款处理程序中。它每次重试只多花一次 GET 请求的成本，却能省下那次代价高得多的对话——要求客户把重复付款寄回来。