你在这里。看看这个问题与其他知识怎样相连。
选择节点前往页面 · 展开后可留在地图中阅读
一个问题
ArcBlock 交易：信封与具体操作
读懂签名的外层记录与有类型的内部操作。
- 签名外层包含→
- itx 类型描述→
- 具体操作
ArcBlock 已发布的交易格式把外层交易与有类型的内部交易分开。外层记录包含发送者、链 ID、签名等字段；内部操作说明要做什么，例如声明账户或转移资产。
读出究竟授权了什么
文档中的 itx 承载内部操作及其类型。浏览器可以把操作解码成可读形式，网络接收的则是编码、签名后的交易。可读显示是在解释记录，不是另外一次授权。
因此，应用可以具体地问：这个签名者究竟授权了在哪条链上做哪项操作？只读取交易哈希，还没有读懂操作含义。
比较执行边界
Ethereum 的 EVM 执行合约代码；ArcBlock 交易文档则提供具名的操作类型。不能因为两边都有签名交易，就推定 Solidity 合约可以直接作为 ArcBlock 交易提交。
链接文档是这里所述结构的参考。实际集成应使用目标链支持的交易版本与 SDK；历史示例不能证明今天的费用策略或端点配置。
从请求走到结果
公开的第一笔交易教程以声明账户为例：先发送声明，取得交易哈希，再把哈希交给 getTx 查询交易信息。这是不同的步骤。哈希是查找记录的标识，不能替代对结果的检查。
查询响应与交易信息要分开读。历史示例既有外层响应码，也有 info 内的操作状态码、链标识、交易内容和区块高度等字段。应把解码后的操作与原本要做的账户声明对照，并核对最终的账户记录。如果暂时查询不到，结果应记为未知，而不是立即重复业务操作。
教程样例的高度为零，适合解释返回结构，却不能证明交易已进入最终确定的区块。生产环境判断确认，还需要目标网络的已提交区块与共识证据。交易哈希或查询层的一句“OK”，都不能独自证明这些条件。
来源与延伸阅读
一个具体操作：Multi IO
TransferV3Tx 在一次转账中组织多个输入与输出。ArcBlock Multi IO进一步说明这些记录的含义，以及它与设计灵感来源 Bitcoin UTXO 的关系。