把几笔交易绑在一起上链，是高频场景的共同需求：一笔源头交易和它的后跑交易最好落在同一个共识批次里、保持先后。Sui 给了两条路：可编程交易块（PTB）把多个操作装进单笔交易，原子执行、只有一个签名人；软捆绑（Soft Bundle）则允许不同的签名人把各自签好的交易捆成一个提交单元，由 Sui 高概率地一起排序执行。软捆绑对应 SIP-19，提案状态为 Final，由 Shio 一方提出并实现，链上通过 soft_bundle 协议配置开关启用。本文按官方文档拆它的机制、限额与已知边界。
PTB 管不了的场景
文档把软捆绑的定位讲成三点：一是捆绑里的交易可以由不同账户签名；二是允许部分回退——捆里某笔交易失败不强制拖垮整捆；三是跨账户排序——捆内交易的相对次序会以尽力而为的方式带进共识。它补的正是 PTB 的短板：PTB 只适合一个账户掌控全部操作的情形。文档给出的典型需求是 MEV 订单流：一笔源头交易和一或多笔来自不同方的后跑交易，需要按已知顺序落在同一个共识提交里。
提交路径与排序保持
常规路径下每笔交易各自提交给验证者，验证者校验签名、输入存在性与 gas 预算后，把它放进自己下一个有空间的提案；同价交易的最终次序受客户端无法直接控制的因素影响。软捆绑换了提交方式：通过验证者的 SubmitTransaction gRPC 方法，把提交类型设为 SoftBundle，连同各笔已签名交易一起发出。验证者把这组交易当一个单元处理，在同一个批次里送进共识，从而保持相对次序。文档特别提醒：共识提交之后还有一道按 gas 价排序的 PostConsensusTxReorder——只要捆内全部交易使用同一 gas 价，这道重排不会改变它们的相对顺序；gas 价不同，彼此之间仍可能被重排。这套机制提供的是高概率，不是硬性保证。
捆级限额与逐笔检查
整捆请求有三道捆级闸门：至少含一笔交易；笔数不得超过 max_soft_bundle_size，文档记录测试网与主网当前取 5；捆内交易序列化后的总大小不能超过共识块字节上限 consensus_max_transactions_in_block_bytes 的一半，另一半留给序列化开销。过了捆级闸门，验证者再逐笔检查：任何一笔无法反序列化、有效性校验失败或签名无效，整个请求直接失败；单笔因已经执行过或验证者过载而无法入队，只记为该位置被拒，不拖垮其余交易。SIP 早期草案曾要求每笔交易访问共享对象并用同一 gas 价，当前实现没有把这些作为拒收规则，但同价仍然影响排序表现。
对象锁与拒绝的代价
Sui 的独占对象锁在这里格外关键。同一个捆里两笔交易若锁同一个独占对象（例如共用同一个 gas 对象），整捆不可能成功，官方给出的做法是每笔交易用各自的 gas 对象。更重的一处边界写在安全考量一节：如果客户端已经让法定数量验证者签了捆里的交易、捆绑随后却被拒，这些交易涉及的独占对象可能被锁到纪元结束。文档把这归为既有风险——先签名后不提交本来就能造成同样后果——并要求客户端负责把已签名交易最终提交；SIP 同时建议一个可选兜底：被拒的捆拆回成单笔重发。对代客组装捆绑的服务，则要评估其信任模型：文档承认该接口让订单发起方抢跑在技术上更容易发生，提出的缓解是接口审计日志，供运营方发现异常并提醒用户。
一句话边界
软捆绑用不保证、但高概率的次序换来了不动共识主干的简单设计。用它就要接受订单流排序是尽力而为，并处理好签名、提交、最终确定三段链路里每一段的失败形态。本文按官方文档描述机制，参数取值以当时文档为准；不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。