Cartesi Rollups中Portal工作原理及消息payload示例咨询

通道确认结论 #

是，用户向Portal转入资产时触发的通知消息，DApp后端必然通过Advanced通道接收。
实际运行逻辑：用户在Layer1调用对应资产Portal的存入方法完成资产转移后，Portal合约会自动调用Rollups核心输入合约的addInput接口，将资产存入的全量信息封装为标准Advance类型输入提交到链上，DApp节点同步到该输入后，会直接推送给后端的Advance处理逻辑，这类资产通知消息不会走Inspect通道。
这类Advance输入有两个固定识别特征：

• 输入的msg_sender字段值固定为对应资产类型的Portal合约部署地址
• 输入payload为严格遵循Solidity ABI规范编码的二进制数据，不同资产类型的Portal对应payload结构存在差异

资产存入类消息Payload示例 #

以下为两类最常用存入场景的payload样例，均以十六进制字符串格式展示：

ETH存入（对应EtherPortal） #

Payload固定结构：前4字节为操作标识0xd0e7d0c5（ETH存入操作的函数选择器），后续按顺序拼接32字节存入方地址、32字节存入金额（大端格式，单位wei）、用户存入时传入的任意长度附加业务数据。
示例payload：

0xd0e7d0c5000000000000000000000000f39fd6e51aad88f6f4ce6ab8827279cfffb922660000000000000000000000000000000000000000000000000de0b6b3a764000068656c6c6f2063617274657369

字段拆解：

• 前4字节0xd0e7d0c5：标记这是ETH存入操作
• 接下来32字节：存入发起方地址为0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266
• 再接下来32字节：存入金额为1 ETH（即10^18 wei）
• 最后一段：附加业务数据为UTF-8编码的字符串hello cartesi

ERC20代币存入（对应ERC20Portal） #

Payload固定结构：前4字节为操作标识0x2fc24704（ERC20存入操作的函数选择器），后续按顺序拼接32字节代币合约地址、32字节存入方地址、32字节存入金额（对应代币最小精度单位）、用户存入时传入的任意长度附加业务数据。
示例payload：

0x2fc247040000000000000000000000005fbdb2315676b786106aa86cd6d1a56a18c398b000000000000000000000000f39fd6e51aad88f6f4ce6ab8827279cfffb9226600000000000000000000000000000000000000000000000000000000000f4240

字段拆解：

• 前4字节0x2fc24704：标记这是ERC20代币存入操作
• 接下来32字节：存入的ERC20代币合约地址为0x5fbdb2315676b786106aa86cd6d1a56a18c398b0
• 再接下来32字节：存入发起方地址为0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266
• 再接下来32字节：存入金额为1,000,000个代币最小单位（若代币精度为18，对应0.001枚代币）

提示：ERC721、ERC1155资产的存入payload逻辑和上述结构一致，仅前4字节操作标识和后续拼接字段的顺序、类型存在差异。后端解码时建议先匹配前4字节的操作类型，再按对应结构解析后续字段，避免解析错误。

内容的提问来源于stack exchange，提问作者Albert Nguyen