Skip to main content

什么是捆绑包

捆绑包是一组 1 到 4 笔交易,它们按顺序执行,并且要么全部成功,要么全部不执行。捆绑包中的每笔交易要么按您给定的顺序在同一个区块中上链,要么全都不上链。 当后面的交易只有在前面的交易成功后才有意义时,请使用捆绑包,例如先执行一笔准备交易,再执行一笔兑换。
捆绑包只能在启用了 Jito 的领导者上链。 一组交易无法在质押加权路径或直连 TPU 路径上保持原子性,因此捆绑包只走区块引擎路径。当前领导者未运行 Jito 时,捆绑包会等待下一个运行 Jito 的领导者。对于单笔交易,常规发送会使用全部三条路径,上链更快。

规则

小费遵循与单笔发送相同的小费规则:一条顶层的 SystemProgram 转账,转给已公布的小费账户,由签名者出资,且小费账户位于静态密钥中。该小费减去 5,000 lamports 基础费用后,即成为整个捆绑包的 Jito 出价。由于捆绑包是原子的,只有整个捆绑包上链时才会支付小费。

JSON-RPC sendBundle

返回结果是一个捆绑包 id。请保留它以查询捆绑包的状态。对于 base58 编码的交易,sendBundle 也接受 {"encoding": "base58"}。下面的示例使用 base64。
JavaScript 和 Python 示例从发送交易中导入辅助模块。 响应:

POST /send-bundle

该二进制路由采用与 /send-batch 相同的帧格式:每笔交易先是一个大端序 u16 长度,后跟原始交易字节,共 1 到 4 帧,按执行顺序排列。
响应:
错误使用与其他普通 HTTP 路由相同的格式和状态码。被整体拒绝的捆绑包会返回 bundle 标签。

跟踪捆绑包

使用捆绑包 id 数组调用 getInflightBundleStatuses
结果按您请求的顺序,为每个捆绑包 id 返回一个条目:
landed_slot 是捆绑包上链的 slot,尚未上链时为 nullstatus 是以下四种状态之一: Apex 重新提交期间,捆绑包 id 保持不变,因此请继续轮询发送捆绑包时拿到的那个 id。 请向您发送捆绑包的同一个 Apex 端点查询。捆绑包 id 不在端点之间共享。 由于捆绑包是原子的,您也可以像确认任何交易一样确认它:只要其中任意一个签名在 Solana RPC 的 getSignatureStatuses 中显示为已确认,整个捆绑包就已上链。

捆绑包还是批量?