Constellation：Solana 上 MCP 的提案

可执行的要点

• Constellation 是首个正式的协议层提案，旨在大规模生产区块链上实现多并发提议者（MCP）。
• Constellation 引入了两个新角色（即提议者和证明者），限制领导者在区块构建方面的自由裁量权。约 16 个提议者以 50ms 为周期并发运行，将交易组装成经过纠删码编码的 pslice，并分发给 256 个证明者。证明记录通过密码学方式约束领导者必须遵循其所包含的交易集合。如果某个 pslice 获得足够数量证明者的证明，领导者就无法排除其中的交易，否则会生成一个被网络拒绝的无效区块。
• Constellation 具备选择性抗审查属性：在任何给定周期内，要么纳入所有费用具有竞争力的交易，要么全部不纳入。
• 内容可见情况下的排序攻击和时序操纵攻击仍未解决。在 Constellation 下，所有在交易提交时收到该交易的提议者都能看到它。由于 MCP 的多提议者架构，这实际上可能扩大而非缩小这些攻击面。当前设计也承认，基于时间的延迟博弈无法惩罚。
• Constellation 重构了现有费用：纳入费对应如今的基础费，排序费对应现有的优先费。更显著的经济变化是，目前通过协议外交易落地服务和链下费用安排流转的活动应当回归协议。按质押权重选择角色意味着现有的集中化趋势会延续，而在 Constellation 最终的 SIMD 发布前，无法对其对单个验证者的净影响进行建模。
• MCP 会增加排序延迟，但会降低纳入延迟。与如今直接提交至 TPU 的路径相比，证明者轮次、50ms 周期窗口和批次组装都会增加耗时。目前，对立即打包 TPU 交易的验证者而言，延迟较高；而对延迟打包的验证者而言，延迟较低。在 Constellation 下，有效交易现在能够获得有明确上限、由协议强制保障的纳入承诺。
• Constellation 明确不兼容提议者与构建者分离（PBS）模型。一旦证明记录限制了领导者的自由裁量权，专业构建者就没有任何可出售的内容。这种方法所代表的理念与 Ethereum 当前处理 MEV 的方式截然不同。
• 目前尚无真实网络条件下的实证基准测试。Anza 能提供的最重要数据，是当前协议的 200ms slot 与 Constellation 下的 200ms slot 之间的延迟预测对比。在获得这些数据之前，社区只能讨论无法量化的取舍。 
• Constellation 构建于 Alpenglow 之上，后者计划于 2026 年第三季度在主网上线。

简介

尽管那里连一株龙舌兰都很难见到，Anza CEO Brennan Watt 还是前往加州沙漠发布了 Constellation。该提案旨在将多并发提议者（MCP）引入 Solana。这是迄今结构上最具雄心的升级，也可以说是所有生产区块链提出的最具影响力的协议层 MCP 提案。它试图解决领导者对交易排序的暂时垄断，以及这种垄断产生的可提取价值。Constellation 将实现 Solana 区块空间的民主化。

本文将对 Constellation 进行批判性分析：它解决了什么、刻意推迟了什么，以及哪些问题仍真正悬而未决。我们将介绍一个用于评估抗审查能力的三层框架，将 Constellation 与当前的 MCP 格局进行比较，并探讨它引入的取舍是否符合 Solana 已建立的性能定位。

本文假定你已了解 Alpenglow。 

Constellation 解决的问题

交易是 Solana 的命脉。它们被组合在一起，以区块形式永久写入网络。但决定哪些交易能进入这些区块及其排列顺序，并不是一个中立的过程。 

领导者对区块生产的垄断

区块生产按照领导者调度表轮换，每次由一个验证者负责在给定时间窗口内生成区块。

在此期间，交易会被直接转发给领导者的交易处理单元（TPU），领导者通常会先于其他所有人收到这些交易。

领导者处于权力非同寻常的位置。也就是说，他们可以在传入交易公开可见之前观察到这些交易。

领导者可以决定不纳入某些交易、任意重新排序，或加入自己的交易。

这是单领导者共识当前运行方式的结构性特征，如今几乎所有生产环境中的权益证明区块链都不同程度地存在这一特征。

Solana 没有公共内存池，这非但没有缓解这种不对称，反而使其更加突出。Ethereum 的公共内存池让参与者能够在一定程度上看到待处理交易，从而为争夺交易排序利用机会的专业参与者创造了一种相对公平的竞争环境。

在 Solana 上，由于交易转发机制的特性，领导者的信息优势更难受到挑战。 

最大可提取价值（MEV）

在正常情况下以及验证者诚实时，这种权力基本不会被利用。但问题在于，验证者是理性的经济参与者。随着 Solana 日趋成熟、金融活动持续增长，利用领导者暂时垄断地位所能获得的利润也会相应增加。选择不利用这一地位的验证者，无异于放弃唾手可得的收益。行为正确的节点反而处于经济劣势，而这种劣势会激励它们破坏自己所参与系统的质量。

这种可提取利润称为最大可提取价值（MEV）。Daian 等人最初在 Flash Boys 2.0 中将其正式定义为矿工可提取价值，之后这一概念才被应用于权益证明网络。它涵盖从套利、抢跑到三明治攻击、选择性审查，以及任何利用领导者相对于其所处理交易用户的信息和位置优势的策略。

行业应对 MEV 的主要方案是提议者与构建者分离（PBS）模型，Ethereum 通过 MEV-Boost 实现了该模型。在 PBS 下，专业构建者竞相构建可将可提取价值最大化的区块，而提议者只需选择最有利可图的区块进行生产。该模型假设 MEV 提取不可避免，因此务实地重新界定了问题：让 MEV 的获取更加民主化，并将收益重新分配给整个验证者集合，而不是集中到最专业的参与者手中。

这种框架的问题在于，PBS 并未减少对用户的伤害——提取仍然存在，只是受益者发生了变化。PBS 解决了 MEV 对网络节点的部分负面影响，却没有减少对网络用户的伤害。

Solana 与 MEV 的关系也在不断演变。快速出块时间、直接提交至 TPU 以及竞争激烈的验证者集合，共同形成了一种独特的 MEV 格局，其特征包括垃圾交易、优先费竞价以及验证者层面的交易重排。Jito 的区块引擎在一定程度上可视为类似 MEV-Boost：它提供一种链下拍卖机制，搜索者在其中对交易排序进行竞价，收益由验证者和质押者分享。也就是说，与 PBS 类似，Jito 并未彻底消除 MEV，而是以更民主的方式管理并重新分配 MEV。

Constellation 试图解决这个问题。它不接受领导者的垄断并管理其后果，而是尝试从结构上遏制这种垄断，通过设计让危害最大的 MEV 形式无法存在。Constellation 白皮书将这一愿景描述为“互联网资本市场的基础设施，一个承载经济活动的通用场所，用户可以相信其市场结构是公平的。”

传统金融市场试图通过监管和司法管辖监督来实施类似的保护。这些保护具有被动性且并不均衡，实践也一再证明它们并不充分。Constellation 的目标是在协议层强制保障公平，使其无法被规避或选择性实施。Constellation 试图通过在 Solana 上实现*多并发提议者（MCP）*来达成这一目标。

多并发提议者

在传统的单领导者区块链中，每个区块由一个验证者负责生成。该验证者（即领导者）暂时独占交易纳入和排序的控制权。在该验证者获准生成区块期间，网络中的所有其他参与者都只是被动观察者。最终由领导者决定纳入哪些交易以及它们的顺序。

这种设计因简单而具有吸引力。由单个验证者负责区块生产，意味着不存在协调开销、无需解决相互冲突的提案，并且问责模型清晰。然而，这也意味着存在单一的可利用点。领导者的暂时垄断是 MEV 的根本原因，而迄今所有主要缓解措施都接受了这一结构，只求管理其后果。

多并发提议者（MCP）是一类从结构层面打破这种垄断的协议设计。MCP 不再轮换到独占区块生产权的单一领导者，而是允许多个节点同时提出交易。没有任何单一提议者能够控制完整交易集合。相反，它们的提案通常由一个权限受限的组装者角色按照协议规则进行合并。

当用户同时向多个提议者提交交易时，就不再依赖单一节点，因为此时有多条相互独立的纳入路径。如果领导者试图排除该交易，就必须面对其他提议者已经看到它、证明者也已经为它提供证明这一事实。最终区块仍由单个领导者组装，但其自由裁量权受到严格限制。

MCP 的主要取舍是协调复杂性。允许多个节点同时提出交易，会带来单领导者设计完全无需面对的问题。当两个提议者纳入同一笔交易时，如何解决冲突？如何确定不同提案之间的排序？如何防止专业提议者操纵合并规则？这显著增加了协议复杂性——团队必须应对涉及新节点角色、调度逻辑、密码学假设和故障模式的协调挑战，而所有这些都需要严格测试。

这里有必要准确区分，因为行业常常宽泛地使用 MCP 来指代一系列性质明显不同的设计。在较低层面，MCP 提供概率性的抗审查能力：提交给多个提议者的交易更难被审查，因为这需要多个节点相互协调。在更高层面，MCP 可以提供结构性的抗审查能力：如果一笔交易获得足够法定数量的证明者证明，领导者就不可能在数学意义上生成审查该交易的区块。这正是 Constellation 的目标；对于需要硬性保障的金融应用而言，这一区别极其重要。

Constellation：工作原理

Constellation 是在 Solana 上实现 MCP 的协议。它与 Alpenglow 相辅相成：Alpenglow 负责共识（即安全性、活性和最终性），Constellation 则负责市场结构——谁可以提出交易、如何确认这些提案，以及领导者获准如何处理它们。Constellation 生成由 Alpenglow 最终确认的有效载荷。

架构

Constellation 在修改领导者和验证者角色的同时，为 Solana 的协议栈引入了两个新角色，每个角色各司其职。

提议者是交易的入口。在任何给定时刻，约有 16 个提议者并发活跃，它们按质押权重随机选出，并每 32 个周期（即 ~1.6 秒）轮换一次。用户将交易直接提交给自己选择的一个或多个提议者。提议者可以自由接受或拒绝任何交易，但接受的交易必须有效。在这一阶段，协议没有强制纳入交易的规则；抗审查保障出现在流程后续。每个提议者以 50 毫秒为周期运行。在每个周期内，提议者会将已接受的交易组装成一种名为 pslice 的结构——“p”前缀不发音，仅用于将其与 Alpenglow 的 slice 区分开来。pslice 通过纠删码编码为 256 个较小的片段，称为 pshred，并向 256 个活跃证明者各分发一个 pshred。该纠删码采用 64 的恢复阈值，即 256 个 pshred 中任意 64 个就足以重建完整 pslice。每个 pshred 都包含对完整交易列表的密码学哈希承诺，确保在证明者签署确认后，领导者无法替换为不同交易或更改 pslice 内的排序。

证明者从提议者处收到 pshred 后，会立即将其转发给接下来的 ~2 个领导者，以应对任何故障或缺席，并记录所收到 pslice 的承诺哈希。在每个周期结束时，证明者会签署一份证明，即一份具有密码学约束力的声明，其中列出它在该周期内观察到的每个 pslice 承诺哈希。该证明会发送给领导者，并作为证据记录，限制领导者可以纳入哪些交易。该记录按质押权重计算并带有签名，因此无法伪造，也无法被悄然忽略。 

Constellation 中的领导者与 Alpenglow 的领导者相同，即负责生成进入共识流程的最终区块的节点。不同之处在于，在 Constellation 下，领导者的自由裁量权受到证明记录的严格限制。Constellation 强制执行两个不同的阈值。要使聚合证明有效，必须有至少 60% 的证明者参与。如果未达到该阈值，整个区块将被跳过。在此基础上，任何获得至少 40% 证明者证明的 pslice，都必须由领导者纳入。否则会生成被网络拒绝的无效区块。这种双阈值设计将区块级有效性与每个提议者的纳入情况分开。也就是说，即使某些提议者的数据未能到达足够多的证明者，领导者仍可生成有效区块，但无法选择性排除那些数据已到达足够证明者的提议者。领导者将所有已获证明的 pslice 编译成一个批次后，会通过 Alpenglow 的 Rotor 将该批次传输给验证者。 

验证者通过 Rotor 接收领导者发来的批次，并在批次到达时进行流水线执行。收到完整区块后，验证者会将其与证明记录进行核对，确认每个已获证明的 pslice 在区块中都有对应的提交。只有全部检查通过，验证者才会投票最终确认该区块；如果检查失败，验证者则会通过 TrySkipWindow 调用投票跳过领导者的整个窗口。 

周期与区块

周期是 Constellation 的基本时间单位。它是一个 50 毫秒的窗口，通过将 Unix 纳秒时间戳除以 50,000,000，从 UTC 实时时钟推导得出。关键在于，周期与 Alpenglow 的 slot 并不对齐。一个 slot 包含多个周期，而这些周期内生成的批次构成领导者区块的有效载荷。这一区别非常重要，因为 50ms 周期是经济节拍（即执行抗审查保障的窗口），而 slot 仍是 Alpenglow 的共识单位。

白皮书规定了提议者与证明者之间可容忍的时钟偏差，并据此调整证明窗口。为说明其重要性，假设某个提议者的时钟比证明者集合快 5ms。相对于周期边界，该提议者的 pshred 可能比预期更早到达证明者，使该 pslice 中的交易拥有稍长的窗口来累积证明。相反，如果提议者的时钟较慢，其 pshred 可能因到达过晚而完全错过证明窗口，即使提议者是“按时”提交的。在使用 chrony 或 GPS 接收器等工具的数据中心环境中，时钟同步是常规操作，偏差通常小于一毫秒，完全处于 Constellation 的容差范围内。值得关注的是，Constellation 引入了一个 Alpenglow 纯逻辑时间模型中不存在的新变量，而 Constellation 最终的 SIMD 应当明确规定该变量的监控边界。

当 Constellation 接近一个 epoch 的末尾时，提议者和证明者可能会短暂无法确定下一个 epoch 是否已开始。在此窗口期间，Constellation 会同时在两个 epoch 中运行，两组提议者和证明者同时保持活跃。Alpenglow 的共识会自然判定哪些周期属于哪个 epoch。

交易生命周期与费用

一笔交易必须通过四道关卡才能执行：

• 它必须被提议者接受并纳入某个 pslice。
• 该 pslice 必须累积足够的证明，才能被纳入领导者的批次。
• 该交易的出价必须足够高，才能在批次的计算量限制内获选执行。
• 包含该批次的区块必须由 Alpenglow 的共识确认。

每笔交易都带有一个出价（即每计算单元的执行费），它决定交易在同一批次中的排序。出价越高，执行越早。

Constellation 将交易成本拆分为两种不同的费用：

• 纳入费。
• 排序费。

纳入费是一笔金额较小的固定费用，根据交易大小和签名数量计算。该费用支付给将交易纳入其 pslice 的提议者，并从交易跨过证明阈值的那一刻开始收取，无论交易最终是否执行。这类似于 Solana 当前系统中的基础费，但有一点需要特别注意：如果用户为实现冗余而将同一笔交易提交给三个提议者，则需支付三次纳入费（即每个提议者一次），因为每个提议者都独立完成了纳入工作。因此，如果用户为实现冗余而将同一笔交易提交给 n 个不同的提议者，就需支付 n 次纳入费。

排序费是金额更高、基于优先级的费用部分，等于交易的总计算单元数乘以其出价。该费用只收取一次，因为无论多少提议者纳入该交易，它都只能执行一次。例如，一笔请求 200,000 个计算单元、每计算单元出价 0.00001 SOL 的交易，需要支付 2 SOL 的排序费。如果为实现冗余而将同一笔交易提交给四个提议者，用户将支付四笔纳入费，外加一笔 2 SOL 的排序费。排序费将按节点质押权重的比例返还给生态系统——白皮书将该机制的设计留待最终的 SIMD。

每个费用支付账户都必须维持约 0.001 SOL 的最低储备余额，以防止并发提议者之间的费用操纵。这可以确保即使多个提议者同时纳入涉及同一账户的交易，也始终能够支付纳入费。

Constellation 与 Alpenglow

Alpenglow 是 Solana 的共识协议。它决定哪些区块有效、区块最终确认的顺序，以及网络如何从故障中恢复。其 Votor 和 Rotor 组件取代了 Tower BFT 和基于 gossip 的投票传播，显著缩短了达到最终性所需的时间。Alpenglow 并不规定谁提出交易，也不规定区块内的排序方式。

Constellation 是一个市场结构层，它限制 Alpenglow 领导者可以如何处理自己组装的区块——它定义谁提出交易，以及每个区块内的排序方式。Constellation 生成的批次会成为 Alpenglow 区块的有效载荷。随后，Alpenglow 的 Votor 按照预先定义的投票规则对这些区块进行公证。这两个协议以组合方式运行：Alpenglow 提供安全性和活性，Constellation 则提供排序公平性。

这种可组合性意味着 Constellation 也会继承 Alpenglow 的安全假设，而不会削弱它们。Constellation 不会改变 Alpenglow 的保障。相反，它在基于周期的新计时模型中，为新的提议者和证明者角色以及 UTC 实时时钟同步引入了新的保障和假设。

Constellation 是首个在可扩展生产区块链上实现 MCP 的正式协议层提案。它为 Solana 引入抗审查能力，是 Alpenglow 开启的协议路线图中的重要新篇章。

抗审查究竟需要什么

过去，MEV 文献通常从几个不同视角研究这一问题。将这些视角结合起来，可以更完整地勾勒出任何抗审查提案真正需要解决的问题。基于 Eskandari 等人对抢跑攻击的基础分类、Garimidi 等人为 MCP 协议提出的正式双属性框架，以及 Landers 和 Marsh 对 MCP 特有 MEV 渠道的分析，我们建议将攻击面划分为三个不同层级，每一层都需要不同类型的解决方案。该框架是我们自己的综合分析，在此用于评估 Constellation 的设计。

第 1 层：硬审查

硬审查是指领导者或提议者能够拒绝纳入其已识别的某笔交易。这是最直观的操纵形式，也是 Constellation 从结构上解决的问题。在 Constellation 下，如果一笔具有费用竞争力的交易获得足够多证明者的证明，领导者就不可能生成一个排除该交易的有效区块。这不需要罚没，因为约束由架构直接执行。

第 2 层：内容可见排序

第二层更难解决。尽管提议者无法直接审查交易，但仍可在最终排序前看到交易内容，并试图利用这种可见性获利（例如，对一笔大额交易实施三明治攻击）。Garimidi 等人将此形式化为隐藏属性——对手在交易确认前不得看到交易内容。Constellation 实现了部分隐藏。也就是说，交易仅对接收它的提议者可见，而非对所有提议者可见；领导者也只有在周期截止时间过后才能看到交易内容。这优于完全可见，但并未完全满足 Garimidi 等人提出的隐藏属性，因为该属性要求交易内容在确认前对所有参与方都不可见。接收交易的提议者仍可观察并利用其收到的交易内容。

Constellation 更深层的隐忧在于，采用公开交易提交的 MCP 可能会放大内容可见型利用行为。在这一系统中，每个提议者都能观察自己收到的交易，并利用这种可见性在自己的 pslice 内获利。其攻击面不同于单领导者模型，因为多个实体各自都能看到一个交易子集。用户若只向单个提议者提交交易，就只会向该提议者暴露交易。但用户若为提高冗余性而向多个提议者提交，暴露范围也会按比例扩大。Landers 和 Marsh 对这一动态进行了形式化分析：并发区块生产会产生时序博弈、同一 tick 内的重复机会，并在结构上消除单一构建者这一瓶颈；目前正是该瓶颈限制了每笔受害者交易可能遭遇并成功落地的价值提取尝试次数。如果只去中心化提议者集合，却不解决内容可见性问题，MEV 攻击面将被放大，而非缩小。

Landers 和 Marsh 对 MCP 特有 MEV 渠道的分析，假设内容可见范围比 Constellation 实际提供的更广。在 Constellation 的部分隐藏机制下，内容可见型利用被放大的程度取决于用户的提交策略，而非架构上的必然结果。只向单个可信提议者提交交易的用户，其内容暴露情况与当前的单领导者模型大致相同。代价在于，只向单个提议者提交会牺牲抗审查所依赖的冗余性。 

第 3 层：时序与延迟操纵

最隐蔽且最难惩罚的一层涉及时序与延迟操纵。在 Constellation 下，提议者可以略微延迟向证明者转发 pshreds，使竞争对手的交易刚好落在证明窗口之外；也可以利用 UTC 时钟偏差，操纵哪些交易能够累积足够的证明。Constellation 白皮书直接承认了这一缺口：消息延迟送达“无法受到惩罚”，因为它与真实的网络延迟无法区分。这一层可能需要引入罚没，也是 Constellation 最终 SIMD 需要解决的首要开放问题。 

Constellation 的设计建立在一项基本假设之上：提议者与用户之间并非匿名关系，而是可衡量信任、重视声誉的重复博弈。在任意时间大约有 16 个活跃提议者，因此，如果某个提议者持续给用户带来糟糕体验，用户可以转向另外 15 个提议者之一。虽然这不会生成任何可用于直接惩罚恶意参与者的链上记录，但会让滥用自身地位的提议者承担经济后果。与罚没等解决方案相比，这种声誉压力能否充分遏制时序操纵，仍是一个开放问题，答案很可能取决于提议者行为随时间推移对用户变得多么透明。 

对验证者和用户的影响

验证者

Constellation 并没有彻底消除 MEV 机会，而是在验证者之间重新分配这些机会。如今领导者最直观、最容易直接提取的收入来源（即硬审查）在设计上已无法实现。但取而代之的是一组更隐蔽、更难惩罚的时序渠道，它们有利于具备延迟优势、精确时钟同步能力，以及能够持续利用 pshred 转发窗口的高水平验证者。最终结果是验证者提取价值的方式发生变化，而非整体提取攻击面缩小。唯一需要补充的是，价值提取会变得困难得多。

与其说 Constellation 引入了全新的费用流，不如说它重构了现有费用流。纳入费类似于当前的基础费用，排序费则对应现有的优先费。预计费用分配方式将与验证者目前的收益类似。差异主要体现在运营层面。也就是说，优秀运营者作为提议者应该能获得更多纳入费，从而在现有经济体系内形成基于性能的收益梯度，而不是新增一种独立收入类别。当前设计不会单独补偿证明者角色。其理由是，与目前参与 Turbine 类似，证明工作预计会因为对网络整体有利而得到执行。更重要的经济变化来自目前流经协议外交易落地服务、市场化拍卖和链下费用安排的活动；这些活动应回归协议内部，更直接地惠及验证者。然而，在 SIMD 明确具体机制之前，它对单个验证者的净经济影响仍是开放问题，尤其是对小型验证者而言，按质押权重选择会降低其成为提议者的频率，而基础设施开销又会抬高最低成本。

提议者和证明者按质押权重选出，这意味着塑造验证者经济格局的集中化动态也会影响这些角色的参与情况。如果少数高质押验证者主导提议者选择，抗审查保证在形式上仍然成立，但提议者集合在实践中的多样性会降低，尽管相比 Solana 当前的状况仍有改善（即从 n 中选 1 与从 n 中选 16 的区别）。即使独立性假设在理论上成立，实践中也会开始弱化。随着 Validator-as-a-Service (VaaS) 服务兴起，这一点值得关注，因为单个实体可能运营多个高质押验证者。SIMD 是否会引入任何反集中机制或提议者选择激励，是一个直接影响 Constellation 所宣传保证强度的设计问题。 

用户

对于用户而言，只要将一笔具有费用竞争力的交易提交给足够多的提议者，这笔交易就首次获得了协议层面的硬性保证，不会遭到选择性排除。金融应用如今可以基于过去根本不存在的保证进行构建，从而改变 Solana 上原本受限的可能性边界。 

高频用户和价格敏感型用户现在必须向多个提议者提交交易，以获得冗余保障。问题在于，如果只去中心化提议者集合，却不解决内容可见性，用户遭受三明治攻击的风险可能增加——每个提议者都能观察并利用提交给自己的交易，因此，为冗余而向多个提议者提交交易的用户，会按比例增加能看到其交易内容的参与方数量。这样做本质上消除了单领导者这一瓶颈，将交易意图广播给更广泛的潜在对手。实际影响是，更成熟的用户需要制定新的提交策略，在冗余与暴露之间取得平衡。例如，他们可能会根据声誉或质押量有选择地指定提议者，而不是采用广泛的多重提交策略。

尤其对做市商而言，Constellation 的纳入保证消除了由基础设施决定执行质量的对抗性风险。剩下的只有纯粹的信息不对称，这与做市商目前在最优秀传统交易场所面临的风险状况相同。正是这种趋同，让支持纳入和降低延迟的论点从愿景变成了具体事实。我们会在“开放问题”一节中更深入地讨论这种趋同。

普通用户感知到的体验净变化可能很小，但纳入保证确实显著提升了可靠性。在未来基准测试公布前，它对排序延迟的净影响仍是一个有待实证回答的问题。

格局：Constellation 与其他方案的比较

Sei Giga

在当前 MCP 格局中，Sei Giga 是与 Constellation 最接近的方案。也就是说，它是一条生产级区块链，将 MCP 视为首要架构优先事项，而不是未来研究目标。两者在同一层面作出了不同权衡，因此比较它们很有启发性。

Giga 的共识基础称为 Autobahn，这是一种多提议者 BFT 协议，每个验证者都并行运行自己的连续提议“通道”。它不依赖单个领导者，而是让每个节点持续通过独立通道传播自己的数据提议。共识层会定期提交一个“tip cut”，即聚合每条通道最新提议的紧凑快照。这在架构上不同于 Constellation 的模型，后者由大约 16 个选定提议者按固定的 50ms 周期运行。Autobahn 基于通道的模型允许任何验证者维护连续的提议通道，而不必从轮换的质押权重子集中选出，因此大幅扩大了区块生产的参与范围。

最重要的区别在于内容可见排序。Autobahn 通过将交易排序与执行解耦来支持异步执行，而 Constellation 暂时推迟了这一设计选择。正如下一节所述，异步执行可以防止提议者在排序时基于已知的最终状态模拟执行结果，从而缩小内容可见排序的攻击面。

Giga 提供概率性的抗审查能力，而 Constellation 提供结构性保证。Giga 背后的理念是，提交给多个提议者的交易更难被审查，因为每个提议者掌握的信息都不完整；如果另一个提议者在同一 tick 中纳入了该交易，审查行为就可能失去意义。相比之下，在 Constellation 下，如果领导者排除一笔获得充分证明的交易，就会生成无效区块。概率性抵抗会提高审查成本，而结构性抵抗会让审查在密码学上无法实现。对于两种协议都希望支持的金融应用而言，这种差异至关重要。 

我们有必要坦诚看待两种设计在目标上的差异。Constellation 是一份协议规范，它证明正确性属性、定义故障条件、规定法定人数阈值，并计划作为正式提案提交给一个可扩展的生产网络，而该网络承载着数十亿美元的质押价值。Sei Giga 白皮书的侧重点不同，更关注吞吐量主张和 EVM 兼容性，将 MEV 和抗审查视为多提议者架构自然产生的收益，而非正式定义的保证。异步执行的方向是正确的，但在排序约束、证明者法定人数或故障条件方面，Giga 并未提供与 Constellation 同等程度的正式保证。这并非批评 Giga 的排序选择，而是反映了二者所处环境不同——Constellation 是为全球吞吐量最高的生产级区块链提出的方案，因此需要并提供相应更高标准的规范。

学术理想方案

MCP 设计的理论基准是 a16z Crypto Research 的 Garimidi 和 Neu，以及 Anza 的 Max Resnick 于 2025 年发表的 Multiple Concurrent Proposers: Why and How。该论文提出了一种 MCP 协议，并主张任何抗审查设计都必须满足两种属性：抵抗选择性审查和隐藏。前者保证对手无法选择性延迟交易，后者保证交易内容在确认前保持不可见。这是当前文献中唯一在形式上同时实现两者的 MCP 设计。

实现隐藏的机制是 HECC，即隐藏型纠删码。其参数配置确保任意 T 个 shreds 都不会泄露底层交易批次的任何信息，而 K + T 个 shreds 则可完整重建数据。关键细节在于，中继只有在共识确认要纳入哪些批次后，才会广播其存储的 shreds。这能阻止任何人在确认前观察交易内容，以信息论保证的方式彻底封闭内容可见排序的攻击面。 

对应到前文提出的框架，这一协议设计是唯一通过结构性抗审查解决第 1 层、通过隐藏解决第 2 层，并借助隐藏提供的抗审查保证限制第 3 层的方案。Constellation 和 Giga 都未能完整实现这些目标。

这项比较格外有趣，因为理论理想方案的共同作者 Resnick 也是 Constellation 的共同作者，而后者有意偏离了前者。这反映出一种审慎判断：完整的 HECC 设计目前尚无法在 Solana 规模的生产网络上部署，而结构性抗审查是更紧迫、应优先解决的问题。该论文是 Constellation 的北极星，为协议的长期建设目标提供了正式规范，即便它无法一次性实现全部目标。 

Ethereum Braid

Braid 是 Ethereum 的主要 MCP 提案，由 Max Resnick 提出。目前，Ethereum 正考虑将其作为 Scourge 路线图的一部分，并与竞争方案 FOCIL 纳入列表设计进行比较。这里纳入 Braid，与其说是为了技术对比，不如说是为了补充背景：整个行业都在尝试解决相同的结构性问题，只是出发点各不相同。

Braid 允许多个提议者在同一 slot 内跨多条并行链同时构建区块，由执行层按照预定规则聚合、去重和排序交易，以此实现 MCP。它没有引入额外的协议角色。最关键的区别是，Braid 的安全性高度依赖加密内存池，因此隐藏是前提，而不是可以推迟的事项。Braid 仍是一项尚未部署的研究提案，Ethereum 社区也尚未就选择 Braid 还是 FOCIL 达成共识。

Braid 最终证明，支持 MCP 的结构性论点并不局限于任何单条链。还值得注意的是，本节四个方案中有三个都有 Resnick 的参与。这或许是最明确的信号，表明 Constellation 源于长期、跨场景且具有学术严谨性的深入思考，所针对的是一个始终没有简单解决方案的问题。

关于 PBS 的说明

这里值得提及提议者-构建者分离（PBS），但应把它作为反例，而不是可比设计。本节中的其他方案都试图从结构上限制领导者的临时垄断，而 PBS 接受这种垄断，并围绕它进行优化，以重新分配 MEV 收益。Constellation 明确与 PBS 不兼容——一旦领导者的自主权受到证明记录约束，专业构建者就没有任何东西可以出售。尽管 PBS 完全没有减少对用户的伤害，却已成为 Ethereum 上主流的 MEV 缓解方案；而这正是 MCP 旨在避免的失败模式。

协议外先例

在 Constellation 上线前，Solana 生态系统已经开始在协议外模拟 MCP 的部分特征。例如，Harmonic 是一个开放的区块构建聚合层，会持续收集和评估多个独立构建者的区块提议，并实时提交给验证者进行竞争性选择。严格来说，这并非 MCP，因为没有协议强制执行的抗审查机制、证明法定人数或对领导者自主权的密码学约束。但运行 Harmonic 的验证者已经在多个并发区块提议之间进行选择，而这正是 MCP 希望写入协议的核心机制。Harmonic 与 BAM 共同代表了生态系统在不等待协议层强制执行的情况下解决市场结构问题的尝试。这些协议外系统表明，市场对类似 MCP 属性的需求真实存在，构建者并不打算坐等 Constellation 上线。

开放问题

Constellation 白皮书是一份协议规范。它在既定假设下证明正确性属性，并恰当地推迟了其他所有问题，这对于一份 v0.9 提案来说是合理的。以下内容不是 Constellation 的失败清单，而是一张路线图，说明其最终 SIMD 和未来迭代需要解决哪些问题，才能有效地将 MCP 引入 Solana。 

这些问题的难度并不相同。其中一些属于规范工作，是 Anza 能够且应该通过正常 SIMD 流程解决的设计决策。另一些则是真正的开放问题，整个 MCP 研究社区尚未找到答案；但当我们开辟道路，力争成为首个大规模实施 MCP 的区块链时，必须充分意识到这些问题。任何单一 SIMD 都无法独自解决它们。区分两者很重要，因为混为一谈要么会夸大 Constellation 的缺口，要么会低估剩余工作量。

相对直接的 SIMD 工作包括：

• 费用分配：文档描述了如何在提议者、证明者和更广泛的验证者集合之间分配优先费，但尚未完整阐明。白皮书指出，优先费将按质押比例返还给生态系统，但并未定义提议者、证明者和验证者之间的具体分配机制。
• 验证者奖励结构：如何相对于现有验证者奖励补偿提议者，以及 Alpenglow 取消投票交易费后，是否会改变小型验证者的经济账。
• 部署顺序：Constellation 依赖计划于 2026 年第三季度推出的 Alpenglow。SIMD 需要明确说明这一依赖关系，并解决从原始 Alpenglow 过渡到 Constellation+Alpenglow 期间的问题。是否有任何前置 SIMD 应该先在主网上线？
• 角色参数治理：Constellation 白皮书表 1 中的提议者数量（p ≈ 16）、证明者数量（q ≈ 256）、周期时长（△cycle = 50ms）和其他参数目前仅作为建议提出。SIMD 需要说明应如何设置和治理这些参数，以及未来可能如何调整。

更困难的问题（例如异步执行、罚没和提交层隐私）将在以下小节讨论。MCP 研究社区正在积极研究这些问题，而我们必须认真考虑它们，因为 Constellation 的设计选择既可能缩窄，也可能拓宽通往某些最终解决方案的道路。

异步执行

在同步执行模式下，如果提议者收到明文交易，或能在简单的提交模型下提前解码交易，就会知道交易内容并可模拟其结果。提议者可以根据当前状态运行交易，精确计算执行结果，包括兑换价格、账户余额变化和后续套利机会。这正是三明治攻击能够实现机械化精确操作的原因。攻击者可以看到大额兑换，并计算需要投入多少资金进行抢跑，才能最大化利润。

异步执行 可以消除这种优势的后半部分，但前提是与 MCP 结合。如果共识在执行前就确定交易排序，那么，即使提议者能看到交易内容，也无法针对已知最终状态模拟执行结果，因为排序时该状态尚不存在。信息优势实际上会从“我知道这笔交易会做什么，也知道它按什么顺序执行”收窄为“我知道这是什么交易，但不知道它相对于最终排序集合会产生什么结果”。这一优势取决于提议者无法控制最终排序。在单领导者模型下，仅靠异步执行无法提供这种保护，因为无论何时执行，领导者仍对排序拥有完全自主权，并可将自己的交易放在有利位置。只有将受约束的排序与延迟执行结合起来，才能缩小攻击面。

需要注意的是，异步执行无法彻底封闭第 2 层。成熟的提议者仍可进行类别推断。例如，提议者仍能看到某笔交易会触及特定流动性池，并可能在不知道确切结果的情况下推断交易方向。这显著提高了最机械化、利润最高的利用行为的门槛，也是无需在共识层采用密码学隐藏就能缩小第 2 层攻击面的最清晰架构路径。值得注意的是，Sei Giga 正是选择了这一方法，将异步执行与 MCP 一同视为首要架构优先事项。

这自然引出了一个值得深思的问题：为什么不先推进异步执行？它能缩小第 2 层，原则上也可以作为一项独立的执行层改动推进，而无需引入 MCP 额外的协议复杂性（即新节点角色、UTC 时钟同步要求、尚未解决的罚没设计，以及翻倍的 shredding 开销）。 

支持这一实施顺序的最有力理由是，异步执行和 MCP 解决的是不同问题。MCP 提供异步执行自身无法实现的结构性排序约束——即使验证者无法模拟执行结果，只要仍能看到交易内容，就仍可在协议允许的窗口内自行决定排序。优先推进 MCP 的理由是，它从结构层面限制了第 1 层，而第 1 层是更直观、经济影响也更直接的威胁。鉴于 Solana 现有同步执行模型的可组合性假设和程序架构，将异步执行改造进现有系统，比从零开始将它构建到一条新链中更具工程挑战。Sei Giga 可以从第一天起围绕异步执行进行设计，而 Solana 没有这种条件。在解释为什么优先推进 MCP 时，这种现实层面的不对称可能与理论优先级同样重要。Alpenglow 的架构也使 MCP 比在 Tower BFT 下更易实现，我们将在下一小节有关协议复杂性的讨论中进一步说明。

这一实施顺序是否正确，是一个合理的开放问题。Constellation 保留了第 2 层攻击面，而考虑到 MCP 在第 3 层引入的新攻击向量，这会带来问题。反过来，它可能提高第 2 层攻击的利润，因为两种攻击面可以相互配合。例如，看到一笔大型 DEX 交易的提议者，可以延迟该交易的 pshreds，将其挤出当前批次窗口，同时在同一窗口内用自己的交易对其抢跑。第 2 层的可见性与第 3 层的时序博弈，是同一攻击面中不可分割的武器，并且只会随着 Solana 日趋成熟而变得更加复杂。

罚没

当参与者的作恶行为会生成可验证记录时（例如冲突签名、有效性检查失败或可证明畸形的承诺），密码学强制执行效果很好。Constellation 能如此彻底地解决第 1 层抗审查问题，是因为排除已获证明交易的领导者会生成无效区块，而这种无效性可通过数学方式证明。时序博弈和延迟操纵不会产生此类记录。难点在于，从单次行为来看，这类作恶与正常网络延迟无法区分。作恶以某种“缺失”的形式存在，无法通过密码学手段证明。唯一可用的杠杆是经济威慑，而这需要罚没。 

罚没的难点在于，它通常要求存在可证明的违规行为。Constellation 的故障见证机制能够处理提议者签署两个冲突 pshreds 的情况，并识别和排除该提议者。然而，策略性延迟操纵不会产生故障见证。没有等价冲突，没有双重签名，也没有链上痕迹。如果提议者只是持续且有选择地将 pshreds 的转发延迟几毫秒，就不会留下任何可供罚没的证据。 

如果某个提议者的 pshreds 在许多个周期内总是于周期窗口的最后几毫秒抵达证明者，而且恰好涉及与提议者自身提交交易竞争的交易，那么，一套定义完善的罚没机制可以将这种模式视为系统性操纵的证据，即使不存在任何一次可证明的恶意行为。传统罚没无法直接处理这一问题。标准形式的罚没要求存在明确且自包含的证明，但对一个仅仅将转发延迟几毫秒的提议者来说，这种证明并不存在。真正不同的是行为模式。

在基于延迟的操纵方面，传统金融对监管机构执法方式的探索可能确实能为去中心化金融提供启发。例如，Dodd-Frank Act 下对虚假挂单的执法，依赖于检测统计模式（例如撤单成交比、撤单时间分布和价格影响相关性），而不是证明每一笔订单的主观意图。任何单一实例都无法被证明是故意的，但其模式可以。同样的逻辑也适用，因为即使单个行为不具备客观性，统计规律也是客观的。此外，无许可提议者集合中的操纵经济激励，与传统金融高频交易者面临的激励同样真实。这一类比在执法方式上失效。也就是说，Dodd-Frank 依赖拥有传票权的监管机构，而在无需信任的环境中，检测和处罚机制必须写入协议本身。

我们建议调整 fisherman 节点，将其作为填补这一缺口的候选机制。fisherman 节点最初出现在 Vitalik 关于数据可用性的研究中，可以将其改造为一类观察者，跨多个周期监控证明数据，并向协议内置仲裁机制提交统计欺诈证明。单次延迟到达具有主观性，但以确定性方式跨 n 个周期计算出的模式是客观的。这与乐观 rollup 中欺诈证明的底层思想相同，只不过应用对象从状态转换变成了时序行为。此外，用于统计欺诈证明的协议内置仲裁机制，与目前正在开发的新治理工具在类别上并无根本差异；这些工具将允许质押者在未来的治理提案中推翻其验证者的投票。如果 Solana 准备建设质押者投票覆盖基础设施，那么基于 fisherman 的仲裁系统所需技术基础可能比看上去更接近现实。

与其扩展标准罚没来覆盖那些不会留下单一链上痕迹的行为，探索 fisherman 节点是一条更可信的方向，而且协议当前对治理基础设施的开发可能已经为支持该方案做好了准备。 尽管如此，任何具体规范都需要解决三项限制。第一，跨数千个周期对证明时序数据进行统计分析并非易事，很可能会提高验证者的硬件要求。这会增加运营成本，并可能使欺诈检测角色集中到少数成熟参与者手中。第二，任何阈值规范都必须足够稳健，既能区分真实网络波动与策略性操纵，又不能过于激进而产生误报。第三，仲裁协议本身会引入新的攻击面，攻击者可能通过协同报告来操纵这一基于 fisherman 的新系统。任何仲裁协议的设计都需要考虑这一点，例如通过激励机制让较小参与者也能运营 fisherman，或采用聚合方案，将计算任务分散到整个 fisherman 集合。

我们提出的具体研究问题是：能否制定一套统计欺诈证明框架，定义阈值参数、考虑网络波动并规定处罚如何递增，使其既足以稳健地遏制系统性延迟操纵，又足够保守以避免惩罚正常波动，同时足够简单，能够抵御成熟运营者的对抗性操纵？这是 MCP 文献中技术难度最高的开放问题之一，整个研究社区尚未解决。

隐藏

罚没并不是解决时序和延迟操纵博弈的唯一方案。隐藏可以同时解决内容可见排序与时序延迟操纵问题，而异步执行和罚没单独使用时都无法做到这一点。Constellation 实现了部分隐藏（即交易内容仅对接收交易的提议者以及周期截止时间后的领导者可见），但并未实现完整的隐藏属性。攻击面会随着用户选择提交的提议者数量扩大。虽然这种部分隐藏相比完全可见缩小了攻击面，但并未彻底封闭它。完整隐藏要求任何参与方在确认前都无法看到交易内容，对 Constellation 而言，这仍是一个开放问题。

理论上的理想方案是 Garimidi 等人提出的方法，它使用隐藏型纠删码（HECC）作为基础组件。与 Constellation 的标准 Reed-Solomon 不同，HECC 提供信息论保证：收集的 shreds 数量未达到阈值的对手无法获知任何交易内容。Constellation 选择继续使用目前已通过 Turbine 在 Solana 上运行的纠删码。

近期最相关的进展是 Jito 的 Block Assembly Marketplace (BAM)。它使用可信执行环境（TEE）创建加密内存池，让交易在执行前保持私密。BAM 表明，Solana 上对内容隐私的实质性需求正在增长。但基于 TEE 的隐藏并非没有局限，它会将信任假设转移到硬件制造商，而对于希望实现无需信任运行的协议而言，这是一个重要约束。应充分探索使用门限加密提供更符合原则的替代方案。

BAM 的重要性在于，它代表了一种协议外尝试，旨在解决 Constellation 暂时推迟处理的内容可见性问题。Jito 具备通过 BAM 大规模提供交易隐私的运营能力，甚至可以赶在 Constellation 上线前实现。这引出了一个问题：如果应用层解决方案已经能够提供隐藏，协议层隐藏是否仍然紧迫？答案完全取决于信任假设，以及与协议理论上可以提供的保证相比，硬件制造商是否“足够”值得信任。尽管如此，这不能被视为永久解决方案。可能的路径是，BAM 在短期内提供隐私，而 Constellation 的后续迭代将探索门限加密，将其作为长期替代方案。

对于一个立志成为互联网资本市场基础设施的协议而言，部分隐藏是重要进步，但不是终点。剩余差距在于，市场结构究竟是真正公平，还是仅仅比当前结构不那么不公平。 

协议复杂性

Constellation 是 Solana 诞生以来提出的最具结构性雄心的升级。它引入三个新节点角色、一种依赖 UTC 挂钟同步的新时序模型、新的纠删码处理流程、新消息类型和新故障模式，而且这些都构建在尚未在主网上线的 Alpenglow 之上。现在是否是承担这种复杂性的正确时机，是一个严肃问题，不能仅靠乐观态度回答。

Solana 过去曾因 2021 年和 2022 年困扰网络的多次宕机而声名狼藉。这些宕机有一个共同主题：在真实负载条件下，要推理一种新型高吞吐量协议的边界情况本身就极其困难。此后，网络最近实现了超过两年的持续正常运行，这是一项真正的里程碑，也是在痛苦的迭代淬炼中取得的成果。这一记录让我们有理由相信 Solana 已经更加成熟。 

如今，任何像 Constellation 这样规模的协议层变更，都需要同时在 Agave 和 Firedancer 中实现。这要求两个独立开发团队就协议语义、边界情况和双方都不熟悉的时序假设达成一致。仅为 Alpenglow 实现这种协调就已经非常复杂，而 Constellation 只会进一步增加难度。这并不是反对推进，而是主张 Constellation 最终的 SIMD 必须包含明确的多客户端实施计划。

金融机构正开始上链。与 2021 年相比，如今发生重大宕机所造成的声誉和经济损失都要高得多。作为一个社区，我们需要坦诚面对 Constellation 引入的复杂性。对待最终 SIMD 时，必须具备构建全球金融系统所要求的严谨性。 

自然，这会引出为什么要现在实施的问题。我们真的愿意承担如此重大升级的风险吗？难道不能随着时间推移逐步升级，从而缓和这项变更吗？例如，前文对异步执行和罚没的探索表明，渐进式替代方案是可能的。Constellation 可以采用一种分阶段部署各种互补升级的路线图，让生态系统逐步受益。将其视为审慎还是反加速主义，不仅是技术问题，也是价值观问题，理性的人完全可以持不同意见。我们不仅在构建一个金融系统，也在构建一个意义系统。

实践中，这已经开始发生。Anza 已确认，200ms slots 和双 slot 领导者窗口将在 Constellation 之前上线。这意味着 Solana 无需承担 MCP 的全部复杂性，就能获得显著性能提升，并解决社区提出的部分排序延迟问题，我们将在下一节对此进行讨论。如果 200ms slots 能让 Solana 的确认路径足够接近 Constellation 的预计开销，使 MCP 的边际成本较小，那么在政治层面推动它就会容易得多。但如果现有交易参与者认为 200ms 已经“足够好”，Constellation 的紧迫性就会降低。对比展示 200ms slots 与 200ms slots 加 Constellation 的延迟预测，可以帮助社区权衡增量成本与增量保证。当然，我们仍需等待 Constellation 最终的 SIMD 和拟议实现方案。

支持继续推进的最有力理由，是 Alpenglow 创造的机会窗口。Constellation 继承 Alpenglow 的安全模型，使用 Rotor 作为数据传播层，并受益于 Tower BFT 复杂性的移除。在 Alpenglow 上增加 MCP 的边际成本，低于未来基于新共识设计从零开始的成本。等待也并非没有代价，因为竞争对手正在探索将 MCP 引入链上，而将抗审查推迟到未来升级周期，也必然会带来自身的复杂性和政治阻力。

如果不是现在，那要等到什么时候？

这种复杂性是合理的，但必须通过严谨的规范、分阶段部署，以及对社区目前仅依据理论展开争论的延迟和带宽主张进行实证验证，才能真正证明其合理性。 

Constellation 是否与 IBRL 一致？

排序延迟与纳入延迟

保守地说，Solana 社区对 Constellation 的最初反应呈现两极分化。这种反应引出了一场重要争论，需要精确而非外交式的回答。最尖锐的表述来自 Cavey 的推文，其中称“MCP 与 IBRL 从根本上不兼容”。他认为，MCP 为改善市场结构，会直接且毫无疑问地降低带宽并增加延迟。Toly 的回应同样直接：“你错了。没有 MCP，就不可能降低纳入延迟。”

从技术上看，两者都正确；他们衡量的是不同指标。

MCP 会降低纳入延迟，同时增加排序延迟。两者不是同一属性，混淆它们正是当前争论中大多数困惑的根源。

排序延迟是从交易提交到执行所需的时间。在 MCP 下，这一时间必然增加，因为证明者轮次、50ms 周期窗口和批次组装步骤都会增加当前通过 TPU 向合作领导者提交交易的路径中不存在的耗时。关于理性参与者向多个提议者发送交易会消耗更多带宽的批评是正确的。合并窗口会增加延迟也是正确的。这些都是真实成本，应向社区进行衡量和展示，作为消除硬审查所需的权衡。

纳入延迟是指一笔有效且具有费用竞争力的交易得到纳入的保证时间窗口。在当前的单领导者模型下，这一保证实际上没有上限。也就是说，如果领导者希望延迟或排除某笔交易，便可直接这样做，而协议没有任何机制可以阻止。用户已经感受到的延迟，包括持有、调度和时序博弈产生的全部摩擦，以及领导者施加的选择性排序。在这一框架下，有人反驳称现实世界的确认时间已经包含这些博弈造成的延迟，因此用户的净体验可能改善；这一判断方向上是正确的，也得到了目前正在 X 上展开的社区讨论支持。 

真正的问题是，我们应该优化哪一种延迟。

FIFO、FCFS 与 FBO

在分析应优化哪一种延迟前，有必要先理解社区同时在讨论的另一个相关问题：MCP 是否与 FIFO 兼容。

FIFO（先进先出）是一种通用排序原则，即交易按到达顺序处理。Umberto 曾详细论证，这个问题的答案本质上需要具体分析。MCP 可以实现所谓的“概率性 FIFO”，但仅限于特定的基础设施条件。简单来说，如果用户在地理位置上足够接近足够多的提议者，从而避免审查，并且这些提议者与证明者距离足够近，能够迅速达到保证纳入所需的 40% 证明阈值，那么从实际体验来看，用户就能获得 FIFO 式纳入。也就是说，他们的交易会在任何竞争者有时间观察并做出反应之前被纳入。竞争在纳入时结束，而不是在执行时结束。在这些条件下，MCP 以涌现属性而非协议规则的形式近似实现 FIFO。

问题在于，Solana 当前的基础设施并不满足这些条件。质押集中在少数几个地区，这意味着法定人数的形成受限于能否覆盖质押高度集中的区域。这种集中性创造了一个时间窗口，使“具有地理优势”的观察者可以抢跑正在传输的交易。Constellation 的部署是否同时具备概率性 FIFO 所需的地理分布和证明者密度，与协议设计本身同样重要。如果一个协议保证抗审查性，却因基础设施分布稀疏而允许基于延迟的抢跑，那么它将无法实现白皮书所承诺的市场公平性。

另一个相关但不同的问题是：Constellation 是否本可以实现 FCFS，却选择不这样做。FIFO 是一种涌现的基础设施属性，而 FCFS（先到先服务）是一项明确的协议规则，确保最先到达的交易以确定性方式得到处理。值得注意的是，Constellation 确实采用确定性排序——每个批次内的交易按优先费排序——因此问题并不在于排序是否由协议强制执行，而在于相对于优先费，到达时间是否应当决定这种排序。

近期的争论提出了一个比最初质疑更根本的反对意见——在无需信任的环境中，FCFS 可能根本无法执行。验证者可以直接虚报交易到达顺序，而不留下任何链上痕迹。这与时间操纵无法按传统方式受到罚没所面临的“缺乏证据”问题相同，可能需要更具创造性的解决方案（例如罚没小节中提出的统计模式检测方法）。如果一项协议规则只有诚实验证者会遵守，而不诚实的验证者可以悄无声息地忽略，它就算不上有意义的保证。这让我们需要重新理解 Constellation 未采用 FCFS 的原因：它不再只是一个需要解释的设计偏好，而是承认在无需许可的验证者集合中，至少基于当前假设，FCFS 可能还根本无法作为 Solana 的强制协议属性实现。如果在当前假设下，FCFS 确实无法在无需许可的验证者集合中执行，那么 SIMD 的任务就是明确说明这一限制，并论证为何按优先费排序才是正确的默认设计。如果不将 FCFS 描述为一种可能无法实现的属性，而是任由社区争论，仿佛它是一个可行但被 Constellation 放弃的替代方案，只会在社区内部引发更多摩擦。

在固定时间窗口内按优先费排序并不是什么新颖的折中方案。这种机制称为频繁批量拍卖（FBA），是一种获得大量学术研究支持的市场微观结构设计。例如，Budish、Cramton 和 Shim 在 高频交易军备竞赛：以频繁批量拍卖作为市场设计应对方案（2015）中指出，采用统一清算价格的离散时间批量拍卖可以消除连续时间市场造成的速度军备竞赛。这会以价格竞争取代基于延迟的竞争。Constellation 借鉴这一理念，基于优先费引入固定批次排序（FBO）。因此，Constellation 的 50ms 周期正是这一设计的实例：在每个批次内，交易依据费用而非到达时间竞争，同一批次中的所有交易都获得相同的排序待遇。这正是前文所说的、尚未在 Solana 上大规模存在的应用类别。 

围绕 FIFO、FCFS 和 FBO 的争论，主要都指向同一个根本问题：在抗审查性得到保证后，谁来控制排序，以及 Constellation 试图建立的市场结构究竟是真正公平，还是仅仅没有当今现有结构那么不公平。Constellation 消除了最直观的一种操纵形式。取而代之的机制将取决于白皮书留待 SIMD 决定的选择。     

那么，我们究竟在优化什么？

对于现有交易应用（即 AMM、自营交易台、CLOB）来说，排序延迟最为重要。这些应用基于一个假设而设计：速度最快且费用最具竞争力的一方获胜，并已据此构建了基础设施。交易只应受物理定律约束，从而在 Solana 上提供无与伦比的用户体验。对其中一些用户而言，Constellation 在他们最看重的指标上是一种倒退。令人担忧的是，Solana 可能会重蹈 Ethereum 曾经犯下的致命错误：将市场结构置于性能之上，最终导致执行离开这条链。这是一个值得讨论的现实风险。

对于 Constellation 旨在支持的金融应用（即链上拍卖、具有可靠纳入保证的订单簿、抗审查的 DeFi 协议），纳入延迟才是正确的衡量指标。无论名义上的确认速度有多快，如果一个限价单可以被抢跑或选择性延迟，它提供的保证都弱于交易所式订单。Solana 现在可以支持采用统一清算价格的批量拍卖交易应用，其中排序不应影响执行价格。这类应用目前在 Solana 上基本不存在，原因恰恰是缺少纳入保证。可以说，Constellation 过度侧重于为尚未在 Solana 上形成规模的用户优化设计，却让已经存在的用户承担代价；核心贡献者已经提出了这一观点。   

理解排序延迟问题时，需要考虑这样一个背景：Solana 目前在永续合约交易领域正明显落后于 Hyperliquid——一个专为永续合约打造、采用中心化排序器的交易所。它并不标榜去中心化，却能提供专业交易者和应用所需、极具吸引力的亚毫秒级执行体验。Hyperliquid 有意选择打造专业人士真正愿意使用的产品，为此牺牲了真正让加密行业之所以成为“加密行业”的核心原则。Constellation 的隐含风险在于，在确认路径中增加通信开销和多轮证明，与 Hyperliquid 所做的是同一种取舍，只是方向相反。批评者认为，在尚无金融应用足以证明这种取舍合理的情况下，牺牲目前让 Solana 能与中心化交易应用竞争的任何潜在性能优势，是一个负面选择；他们也非常直言不讳。

这个问题不应如此轻易地被忽视。我们可以重新表述之前关于应优化排序延迟还是纳入延迟的问题：考虑到 Solana 当前竞争对手的性质，它是否承受得起这种取舍？

不过，这里还有一个更深层的问题。与 Hyperliquid 的对比表明，IBRL 的含义可能已经随时间发生变化。Toly 和 Raj 最初构建 Solana 的动机是抗审查性：“为了让 DeFi 产品吸引数十亿用户和设备，我们需要扩展抗审查能力……这是最重要、最需要解决的单一问题，也是我们构建 Solana 的全部动力。”很久之后，IBRL 才成为这一使命在工程层面的表达：将速度提升到足以让去中心化网络在关键指标上战胜中心化基础设施。此后，IBRL 逐渐拥有了自身的技术乐观主义含义，并渗透进 Solana 的文化思潮。它既是工程命令，也是文化暗语，还是世俗祈祷。对许多人来说，它已经从手段变成目标；最小化排序延迟本身成了目的，并与其原本服务的抗审查目标脱钩。

如果这种偏移确实已经发生——看起来的确如此——Constellation 将面临强烈的文化阻力。鉴于社区曾否决 SIMD-228，这并不是什么新现象。SIMD-228 是一项颇具争议的通胀削减提案，未能通过治理投票。即使是普遍有益的提案，在与社区根深蒂固的既有认知冲突时也可能失败。Constellation 的情况更为复杂，因为它确实会带来带宽和延迟成本，但这些成本对用户体验的净影响尚未量化。在获得数据之前，无论支持还是反对，仓促得出确定结论都为时过早。社区目前缺少、Anza 也必须为一份有说服力的 SIMD 提供的，是关于真实网络条件下确认路径表现的实证数据。Alpenglow 并未遇到这个问题，因为它与 IBRL 高度一致：将交易达到最终确定性的时间缩短 100 倍，并简化共识流程。Constellation 的价值很难凭直觉说明，但如果未来的基准测试能够支持，其价值同样真实。

看起来，社区将用一个抗审查升级从未打算优化的性能指标来评判它。更有建设性的问题是，这种取舍是否值得。它确实存在真实且可衡量的成本：以额外的排序延迟和带宽为代价，换取由协议强制执行的可靠保证，确保任何领导者都无法选择性排除某笔交易。这是 Solana 目前试图吸引的金融应用所必需的前提。

我们的观点是，如果正确理解 IBRL 一直以来的目标，Constellation 就与 IBRL 一致。社区最终是否会得出相同结论，与其说取决于技术优势，不如说取决于是否提出了充分的实证依据，以及是否清楚解释了设计选择。  

结论

Constellation 是首个在正式协议层面提出、旨在将 MCP 大规模引入生产级区块链的方案。它从结构上解决了硬性审查问题：只要费用具有竞争力的交易获得足够法定人数的证明，就不能被排除在有效区块之外。这种密码学保证改变了 Solana 上可构建的应用类型。 

Constellation 有意留待后续解决的问题同样重要。Constellation 的提交模型在一定程度上缓解了内容可见情况下的排序问题，因为只有接收交易的提议者能看到交易内容；但剩余攻击面会随用户提交交易的提议者数量增加而扩大。时间和延迟操纵仍是目前最大的未解决问题，在当前设计下也无法受到惩罚。可能的前进路径（即异步执行、罚没、隐藏）已被指出，但尚未具体定义，而且每种方案都会引入各自的复杂性。Constellation 的白皮书坦率地说明了这些边界，其最终 SIMD 也应同样坦率。

Constellation 提出的最棘手问题是，Solana 是否承受得起它所引入的取舍。排序延迟和带宽方面确实存在尚未量化的真实成本。同样，纳入保证也会带来真实但尚未衡量的收益，只是目前还没有足够的应用基础证明其大规模部署的合理性。社区被要求为如今在 Solana 上基本不存在的金融应用投资基础设施，而代价可能由已经存在的交易应用承担。此举究竟是高瞻远瞩还是为时过早，取决于社区目前尚未掌握的数据。

Constellation 最终成败将取决于未来在真实条件下进行的实证基准测试。仅使用 200ms slot 时的确认路径，与 Constellation 下使用 200ms slot 时的确认路径相比表现如何，是 Anza 能够提供的最重要数据。在此之前，社区所争论的是无法量化的取舍。

我们的观点是，Constellation 是 Alpenglow 所开启的协议路线图中正确的下一步。按照 Solana 最初构建时所服务的 IBRL 定义，它与 IBRL 一致。不过，这一观点有一个前提：SIMD 必须在规范、分阶段部署、测试以及向需要采纳它的社区提供的实证依据方面，达到全球金融系统应有的严谨标准。

其他资源

• Budish, E., Cramton, P., and Shim, J. (2015). 高频交易军备竞赛：以频繁批量拍卖作为市场设计应对方案。 https://doi.org/10.1093/qje/qjv027
• Daian, P., Goldfeder, S., Kell, T., et al. (2019). Flash Boys 2.0：去中心化交易所中的抢跑、交易重排序与共识不稳定性。 https://arxiv.org/abs/1904.05234
• Eskandari, S., Moosavi, S., and Clark, J. (2019). SoK：透明的不诚实行为：区块链上的抢跑攻击。 https://arxiv.org/abs/1902.05164
• Garimidi, P., Neu, J., and Resnick, M. (2025). 多个并发提议者：为何采用以及如何实现。 https://arxiv.org/abs/2509.23984
• Kniep, Q., Resnick, M., Sliwinski, J., and Wattenhofer, R. (2026). Solana Constellation：互联网资本市场. https://drive.google.com/file/d/1MiGlZ_OORdnq6znkVQ5LrenBF3kyBIWf/view
• Landers, S. and Marsh, B. (2025). 多个并发提议者区块链中的 MEV。 https://arxiv.org/abs/2511.13080
• Yakovenko, T., and Gokal, R. 区块链开发者关注了错误的问题. CoinDesk, 2020. https://www.coindesk.com/markets/2020/12/30/blockchain-developers-are-focused-on-the-wrong-problem