Solana一项旨在约束交易排序的提案，拟要求验证者检查同一批次内的交易是否符合费用优先级，但不会限制出块者决定哪些交易进入区块、批次从何处开始或结束。SIMD-0649的拉取请求于2026年9月25日关闭，未获合并，相关规则尚未生效。由于缺少当前批次规模的实测数据，该提案能否改善交易执行的可预测性仍不确定。
SIMD-0649拟检查批次内交易顺序
Solana账本将区块数据组织为多个批次。按提案设计，除豁免交易外，同一批次中的交易须按优先级从高到低排列。验证者在重放区块时会核对记录顺序；如发现不符合规则，便将该区块判定为无效，而不是收到区块后再替交易重新排序。
优先级相同的交易可以采用任意顺序，简单投票交易则不受该规则约束。提案所称的优先级分数，也不只是用户填写的费用高低：计算方式是出块者纳入交易可获得的奖励，除以交易执行前成本模型下的请求成本，并采用带有乘数及分母保护项的整数计算，以确保不同客户端得出一致结果。
按提案描述的费用规则，奖励包括优先费，以及未销毁的基础费用部分。若规则实施，观察者可以据此判断：出块者已经放入同一批次的非豁免交易，其排序是否符合统一标准。提案作者认为，统一校验有助于跨验证者客户端和调度器检查交易顺序，但它不回答某笔交易本来是否应该入块。
出块者仍掌握入块选择和批次边界
提案明确不试图建立覆盖整个时隙的统一优先队列。出块者仍可挑选纳入区块的交易、将交易延后至之后的批次，并决定批次边界。这样一来，两笔相互竞争的交易未必会进入同一批次接受排序比较；即便某笔交易优先级更高，只要它被放在后续批次，也不会因此自动排到较早批次的交易之前。
这意味着，批次内排序规则的约束范围小于整个时隙的排序，也不构成最佳执行保证。提案因此设置了批次大小下限，以免出块者通过将批次切得过小、减少可比较交易，让排序检查难以发挥作用。
除最后一个批次外，每批至少须覆盖两个前向纠错（FEC）集合。FEC集合由组成区块的数据分片（shreds）构成；按提案采用的固定大小规则，两个集合至少相当于64个数据分片。最后一个批次仍须接受排序检查，但由于时隙可能在批次填满前结束，不受这一规模下限约束。
批次规模数据仍不足以评估实际效果
9月23日的一条审查意见指出，即使设置批次下限，出块者仍可能在有利于分隔冲突交易时结束当前批次。审查者要求提供按调度器、客户端及市场条件拆分的现有批次规模数据，并建议测试不同下限对结果的影响。这些意见质疑的是规则在实际运行中的覆盖程度，并不代表出块者已在主网上采用过这种做法。
提案称，Agave和Firedancer的目标批次规模约为两个FEC集合，但提案和审查意见均未提供当前出块者实际批次规模的分布数据。因此，无法量化该下限会对日常出块行为产生多大影响，也难以判断它能否有效减少出块者调整批次边界的空间。
延迟与优先交易问题仍未解决
8月的一场讨论还提出延迟方面的顾虑：如果验证者必须等待整个批次到齐才能检查，可能影响Firedancer对部分到达数据进行重放的做法。修订后的草案允许验证者在交易到达时逐步比较并执行；若之后发现排序不符合要求，仍可将区块判定为无效。不过，在交易量较低时，要求出块者等到批次达到两个FEC集合的下限，可能增加广播延迟，现有材料没有给出延迟测量结果。
这项提案也不会阻止出块者通过向自己支付优先费来偏向自身交易。提案指出，优先费会回到出块者手中，而被销毁的基础费用部分仍构成成本。因此，批次内排序校验不能被视为防止偏袒、最大可提取价值（MEV）或滑点的保障。
SIMD-0649在9月25日关闭，后续是否推进取决于进一步讨论及客户端开发者的支持。对交易者而言，关键仍是有多少具有实际竞争关系的交易会落入同一批次，以及批次下限是否改变出块者行为。在这些数据补齐前，提案提供的是一种核查批次内相对排序的方法，其对实际交易执行的影响尚无法确定。