Sui PTB 是什么？一串命令怎么在一条交易里原子完成

一条交易里的微型程序：PTB 的结构

Sui 官方文档把普通用户提交的交易定义为可编程交易块（Programmable Transaction Block，PTB）：一串按顺序执行的命令，作用在输入上，产出结果。它允许在一条交易里调用多个 Move 函数、管理多个对象、拆分和合并多个币，而无需为组合动作专门发布新合约。这与以太坊模型差别明显：以太坊要原子地完成一组操作，通常得部署一个组合合约再调用它；Sui 把这层组合能力下沉到了交易格式本身，命令清单就是那段”微型程序”。

命令、输入与结果的流动

PTB 的输入分两类：网络上的对象，或者纯值（整数、地址、字符串等按 BCS 编码的字节）。命令执行时按编号引用输入数组和前面命令的结果数组——结果是每个命令各自一格的二维结构，前一条命令的产出可以直接喂给后一条。以转账拆分为例：先拆分 gas 币，再各自转入两个目标地址，两条命令在同一个块里一气呵成。官方 CLI 甚至允许给结果起名字再引用，说明这套数据流是显式建模的，而非隐式约定。命令执行期间修改只是暂存，全部命令成功后交易效果原子地生效；任何一条命令失败，前面命令的改动也一并作废，链上不会留下半完成的中间状态。

对象版本是安全性的锚点

PTB 引用对象时不是只写一个 ID：属于发送者的对象要带上版本号和摘要，共识据此校验”你引用的确实是这个对象此刻的样子”；共享对象的版本与摘要由共识协议决定，交易需声明其初始共享版本，共识在尚未见过该对象交易时以这个初始版本为准。这个细节解释了 PTB 的原子性为什么廉价：验证者执行前先核对输入版本，任何一格对不上，整条交易作废重试，不必担心中间态被别的交易偷走。反过来说，版本冲突也是 PTB 特有的失败模式——两条并发交易争夺同一对象时，总有一条要更新引用重发，这对高频做市类程序尤其常见。

与普通交易、系统交易的边界

Sui 的交易只有两大族：任何人可提交的 PTB，和只有验证者能提交的系统交易（处理纪元切换、检查点等网络事件）。日常要判断的组合操作问题——批量铸造加空投、闪借后偿还、先兑换再抵押——在 Sui 上都可以压进一条 PTB，一次签名、一次失败回滚；在以太坊模型里则要拆分多笔、自担中间态风险。需要提醒的边界是：PTB 内命令数量与交易体积有协议上限，超长组合仍要靠合约侧完成；并且原子性只覆盖这条交易自身，跨交易、跨时段的组合仍需程序逻辑自己负责兜底。

用户体验与gas计费的连带影响

PTB 把组合能力放进交易格式后，钱包侧的授权界面也获得了结构性好处：钱包可以对命令清单逐条解码展示，用户签的是一列可读动作，而不是一个不透明的函数调用。计费同样按块算：整条 PTB 共享一个 gas 预算，执行前通常先以 dry-run 估算命令总开销，预算不足在模拟阶段就能发现，省掉链上反复试错。对开发者，PTB 还改变了合约设计直觉——很多在以太坊上”必须写成合约方法”的流程，在 Sui 上只是客户端拼装的一串内建命令（转账、拆分、合并、Move 函数调用），Move 包只需暴露最小原语。当然灵活性有代价：交易体积变大、验证者要为每条交易解析命令依赖图，官方 CLI 也提醒数组参数在部分 shell 里需要引号转义、变量重名默认不告警，这类细节会直接决定构造失败与否。理解 PTB，就是理解 Sui 把”原子性、对象并发、组合能力”三件事同时押在交易层的设计选择。本文是机制说明，不构成任何投资建议。