本文介绍了Solana上的交易排序问题,以及提出的解决方案:区块构建市场(BAM)。BAM通过引入BAM节点和插件,在不改变Solana核心协议的前提下,实现了可编程的排序逻辑、交易隐私和可验证的排序保证,从而提高市场效率和执行完整性。
Solana 上的交易排序目前由各个验证者处理,他们对其区块槽内的交易排序方式拥有完全的自由裁量权。这种缺乏透明性和可验证性带来了几个挑战:验证者的行为难以审计,执行质量不一致,应用程序无法定义其交易应如何优先排序。
区块构建市场(Block Assembly Marketplace, BAM)是一项拟议的升级,旨在解决这些限制,而无需更改 Solana 的核心协议。它引入了一个新角色——BAM 节点——它使用安全 enclave 和可编程插件来私下对交易进行排序,并生成排序的加密证明。然后,验证者根据此预定义的逻辑执行区块,从而创建每个区块构建方式的公开审计跟踪。
广泛采用 BAM 将在整个网络中实现可编程、可审计和与应用程序对齐的执行。它将开启新的协议设计空间,提高市场效率,并提高执行完整性的标准——将 Solana 定位为第一个大规模拥有可验证和可定制区块空间的链。
Solana 使用一种基于领导者的区块生产模型,其中验证者轮流以快速、可预测的时间间隔(通常每 400 到 800 毫秒)提议和执行区块。当一个验证者成为领导者时,它负责通过管理完整的交易管道来生产下一个区块。
交易通过各种渠道(RPC 端点、转发器、机器人或应用程序)直接提交给当前领导者。Solana 不使用全局 mempool ——只有领导者在其 slot 期间才能看到完整的交易集。
领导者对其交易的排序方式拥有完全的自由裁量权。只要生成的区块有效,它可以重新排序、批量处理、延迟甚至排除交易。协议不强制执行全局排序规则或可验证的逻辑。
一旦排序完成,领导者就会执行交易,组装区块,并在网络中传播它。验证者验证最终状态转换,但不验证交易顺序的内部推理或公平性。
区块通过 Solana 的历史证明(Proof-of-History)和 Turbine 协议进行确认。虽然最终状态转换在整个网络中得到验证,但领导者最初做出的排序决策是不透明且无法验证的。
在 Solana 上,验证者领导者在其 slot 期间对交易排序拥有完全的控制权,并且没有强制执行的排序规则或意图的加密证明。唯一可观察的输出是区块本身——一个最终确定的交易列表,没有伴随如何或为什么选择该顺序的解释。
这意味着评估验证者行为的唯一方法是手动分析他们生成的区块,寻找诸如一致的抢先交易(front-running)、夹三明治交易(sandwiching)或选择性包含之类的模式。但是这种分析是不完整且充满噪音的——无法知道看到了哪些交易、扣留了哪些交易、重新排序了哪些交易或删除了哪些交易。缺乏结构化的、可验证的排序数据使得难以得出可靠的结论或追究验证者的责任。
因此,用户和 staker 无法有意义地评估验证者是否在促进或降低执行质量。委托决策主要限于正常运行时间、费用和品牌——而不是行为。
由于验证者可以自由地重新排序交易,因此用户被迫将风险纳入定价,即他们的交易可能在区块内最差的位置执行。这种不确定性为每个链上动作增加了一种看不见的溢价。
例如,提交大额 swap 的交易者无法保证它不会被战略性地定时买入,从而恶化他们的成交量。清算机器人可能会根据 oracle 数据提交交易,但最终会被验证者抢先交易或延迟,因为验证者看到了获利的机会。这种不可预测性降低了执行质量,并使得难以构建高效的市场和协议。
Solana 的架构不允许应用程序影响其交易在区块内的排序方式。所有排序决策均由验证者领导者做出,开发者无法插入逻辑来优先排序或相对于其他交易对自己的交易进行排序。
这种限制在许多类型的应用程序中造成了设计摩擦。做市商无法保证在传入交易之前处理取消订单。像 Pyth 这样的 oracle 提供商必须提交持续的更新,因为无法将 oracle 刷新与交易执行对齐。DEX 无法将用户的 swap 及其路由逻辑共置到单个原子性的、排序的流程中。这些不是理论上的极端情况——它们是定义金融系统性能的核心行为。无法访问排序层,开发者被迫构建外部系统或接受降低的功能。
区块构建市场(BAM)是一种新的 Solana 区块构建架构,它通过引入可编程排序逻辑、交易隐私和可验证的排序保证来解决这些结构性限制——所有这些都无需更改 Solana 的核心协议。
BAM 的核心是一个新的参与者:BAM 节点,它与验证者并排运行,并从用户、机器人和协议接收交易。BAM 节点不是依赖于验证者控制的排序,而是使用安全 enclave(可信执行环境)基于由 Plugins 定义的逻辑私下对交易进行排序——Plugins 是自定义程序,用于编码包含和排序的特定于应用程序的规则。这些 Plugins 可以优先处理取消、插入 oracle 更新或共置相关交易——这些功能以前在 Solana 上是不可能的。
每个排序的包都用一个加密证明密封,该证明精确地证明了排序是如何确定的。然后,验证者按照指示执行区块,返回一个匹配的证明以确认正确的执行。这创建了一个审计跟踪,使得交易排序透明、可重放和可问责——这在 Solana 上是第一次。
BAM 将交易排序从一个不透明的、验证者控制的过程转变为一个模块化的、可编程的层。它为更高效的市场、新的协议设计模式和更公平的执行环境打开了大门——而不会牺牲速度或规模。
如果 BAM 在 Solana 的验证者集中得到广泛采用,它将标志着网络处理执行方式的根本性转变——从验证者确定的排序转变为可编程的、可审计的和确定性的区块构建层。这种转变将对性能、协议设计和市场结构产生深远的影响。
随着每个验证者执行 Plugin 定义的排序逻辑,执行将变得可预测且与应用程序对齐。开发者可以依赖于所有区块上的一致排序行为——先取消后交易逻辑、oracle 共置和原子批量路由将不再需要外部的变通方法。这降低了协议的复杂性并开辟了新的设计空间,特别是对于需要定时精度和排序保证的高级金融基础设施。
可审计性也将成为链的固有属性。由于每个 BAM 节点和验证者都生成排序和执行的加密证明,外部观察者——研究人员、DAO 代表或用户——可以准确地验证区块是如何构建的。这使得验证者的行为可以实时观察,并解锁了目前不可行的新形式的治理、staking 和 MEV 监控。
最后,广泛采用 BAM 将提高整个网络的执行基线质量。通过在代码中定义的排序逻辑而不是验证者的自由裁量权,用户将面临较低的不确定性、更少的隐藏成本以及交易意图与实际结果之间更紧密的集成。
BAM 引入了 Solana 上区块空间处理方式的根本性转变。通过为交易排序带来隐私性、可编程性和可验证性,它将排序从不透明的验证者责任转变为开放的、可审计的和与应用程序对齐的系统。
这一点很重要,因为排序不仅仅是一个技术细节——它定义了价值如何在网络中流动。当协议无法控制排序并且用户无法信任执行顺序时,效率会受到影响,复杂性会上升。BAM 通过为开发者提供定义排序逻辑的机制,以及为用户提供验证它的方法,直接解决了这些问题。
广泛采用 BAM 不仅仅会改善执行——它还会重新定义 Solana 生态系统中的期望。它将提高区块构建中公平性、可组合性和透明度的基线。通过这样做,它使 Solana 能够支持新一代的应用程序,这些应用程序依赖于精确的、可编程的和可证明地负责任的区块空间访问。
- 原文链接: pineanalytics.substack.c...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!