Hedera 网络里，一笔交易只属于一个服务，跨服务的组合动作过去要么写智能合约、要么靠镜像节点查状态接力。HIP-551 状态 Final、随 v0.66.0 发行落地，补上的是协议级的批量：一串互相依赖的原生调用捆成一笔 AtomicBatch 交易，规范的目标写得很硬——满足 ACID，全部应用或全部回滚。动机部分还有个顺手的安全收益：捆绑执行让恶意用户无法在你几条交易中间插一笔，抢跑夹击的窗口被关死。
内层交易：各自签名、各自付费、不能套娃
批量交易的外壳里装着若干“内层交易”，规范给它们定了九条规矩：每条都是独立签过名的正规交易——你签它即表示接受它的结果；每条自带付费人，节点费、网络费、服务费一样不少；每条有自己的 TransactionID 并在批内单独去重，两条同 ID 直接拒收；内层的 scheduled 必须为 false、nonce 为 0；授权只看它自己的密钥，不看批密钥；批量不能再装批量；网络冻结类交易不能进批；内层的 nodeAccountID 必须填占位值 0.0.0——这个标记既说明“我是批里的一员”，也让整批重提交时不必重新签内层；最后，每条内层必须设 batchKey。
batchKey：防调包的那把锁
批密钥解决的是组装信任问题。没有它，一个拿到你签好内层交易的恶意组装者可以抽走一条、调个顺序、混进别的交易重打包。batchKey 把“谁能把这份批提交上网”钉死成一个受信账户：内层交易离开批量语境就不许单独执行；外壳那笔 AtomicBatch 必须由批内所有不同的 batchKey 一起签名——两条内层各指向不同批密钥时，外壳就得集齐两把钥匙；反过来，外层交易自己不许设 batchKey，谁设谁被拒。目前只支持 Ed25519 和 secp256k1 公钥。另有一条提交侧的自由：外壳的提交人可以是任何账户，不必有权执行批里的每一条内层，只要签名齐了就行。
全批回滚，但钱照扣
失败时的账目是用户最容易吃亏的地方。规范的处理原则：任何一条内层交易失败，整批作废；但“跑过”不等于“算过账”——它给的例子是 A 成功、B 失败、C 没轮到：A 的效果随后被回滚，可 A 按其交易类型照收全额手续费；B 失败也照收；只有没执行的 C 分文不取。外壳 AtomicBatch 自身的费用无论成败都收。换句话说，批量买的是“不留半截状态”的确定性，不退款的是“这批确实被执行过”的成本。
回执怎么看：一层套一层的账页
批交易对外只返回一个普通的交易响应，内层大多不在预检里被校验，所以看批结果不能只看外层。规范给的动线：批交易和每一条被执行的（含失败的）内层交易都会生成自己的交易回执，想知道每条内层的返回码，要逐条查内层回执；交易记录里，内层的 parentConsensusTimestamp 指向外层批的 consensusTimestamp，顺着这个父时间戳就能把整批的记录串起来核对，区块流同理。还有一条限制为这种关联留了安全余量：批交易不允许被 ScheduleCreate 排到未来执行。
用户签名前的三查与适用边界
第一查，批里的每条内层你都要像对普通交易一样逐个看：签的是内层，不是“整批”这个概念，签名时你已经逐条承诺了结果；第二查，batchKey 是不是你指定的受信组装方，它决定谁能把这一坨提交上网——把它交给交易所或托管方当便利开关前，想清楚这等于把“按你签的样子整批执行”的权力给了组装流程；第三查，额度与余额，失败也要扣费，一条塞了五十个动作的大批即使最后一步翻车，前面几十条的网费照单全收。批量能替代一部分合约编排（比如先解冻、发货、再冻结的“绑号 NFT”场景，规范列了七个用户故事），但它替代不了全部：需要查询链上状态再分支的场景仍要合约。涉及费用的批量操作不构成投资建议，机制以 HIP-551 规范 2026-10 版本原文为准；额度授权与它的搭配可回看本栏目同日文章《别人替你转走的每一笔都有上限：Hedera 原生额度 API HIP-336 的授予与回收》。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。