什么是 Constellation？Solana 上的 Multiple Concurrent Proposers

Constellation：关于 Solana 上 MCP 的提案

非常感谢 Matt、Nick、Alessandro、Brennan 和 Max 对本文早期版本的审阅。

核心见解

• Constellation 是第一个在生产级区块链上大规模实现多并发提案者 (MCP) 的正式协议级提案。
• Constellation 引入了两个新角色（即 Proposer 和 Attester），以限制 Leader 在区块构建过程中的自由裁量权。大约 16 个 Proposer 以 50ms 为周期并发运行，将交易组装成纠删码化的 pslice，并分发给 256 个 Attester。Attestation 记录在加密层面将 Leader 与其包含的交易集绑定。如果一个 pslice 得到了足够数量 Attester 的见证，那么 Leader 就无法排除该交易，否则将产生一个会被网络拒绝的无效区块。
• Constellation 具有选择性抗审查属性：在任何给定的周期中，要么包含所有具有费用竞争力的交易，要么一个都不包含。
• 内容可见的排序和时间操纵攻击仍未解决。在 Constellation 下，交易在提交时对接收该交易的所有 Proposer 都是可见的。由于 MCP 的多提案者架构，这实际上可能会扩大而非缩小这些攻击面。在当前设计下，基于时间的延迟博弈被认为是不可惩罚的。
• Constellation 重构了现有费用——包含费对应于今天的 Base Fee，排序费对应于现有的 Priority Fee。更重大的经济转变在于，目前通过协议外落地服务和链下费用安排流动的活动应该回归协议。权益权重的角色选择意味着现有的中心化动态将会延续，在 Constellation 最终的 SIMD 发布之前，无法建模对单个验证者的净影响。
• MCP 增加了序列延迟 (Sequence Latency)，但降低了包含延迟 (Inclusion Latency)。相对于今天的 TPU 直接提交路径，Attester 轮次、50ms 周期窗口和批处理组装都增加了时间。目前，对于立即打包 TPU 交易的验证者来说，延迟较高，而对于延迟打包的验证者来说，延迟较低。在 Constellation 下，有效的交易现在拥有有界的、协议强制执行的包含保证。
• Constellation 明确与提案者-构建者分离 (PBS) 模型不兼容。一旦 Attestation 记录限制了 Leader 的裁量权，专业构建者就失去了可出售的内容。这种方法代表了与以太坊当前处理 MEV 方式根本不同的理念。
• 在现实网络条件下的实证基准测试尚不存在。Anza 能提供的唯一最重要的数学据是，当前协议下 200ms Slot 与 Constellation 下 200ms Slot 的对比延迟预测。在这些数据可用之前，社区讨论的只是无法量化的权衡。
• Constellation 构建在 Alpenglow 之上，后者的目标是 2006 年第三季度上线主网。

简介

尽管严重缺乏龙舌兰植物，Anza 首席执行官 Brennan Watt 还是前往加利福尼亚沙漠揭晓了 Constellation——一个为 Solana 带来多并发提案者 (MCP) 的提案。这是目前任何生产级区块链提出的结构上最雄心勃勃、也可能是影响最深远的协议级 MCP 提案。它旨在解决 Leader 对交易排序的临时垄断及其创造的可提取价值。Constellation 是 Solana 区块空间的民主化。

本文是对 Constellation 的批判性分析：它解决了什么，它有意推迟了什么，以及哪些问题仍然没有真正解决。我们引入了一个评估抗审查性的三层框架，将 Constellation 与当前的 MCP 领域进行对比，并检查它引入的权衡是否与 Solana 建立的性能特性相兼容。

本文假设读者已具备 Alpenglow 的先验知识。

Constellation 解决的问题

交易是 Solana 的生命线。它们被分组并以区块的形式永久写入网络。但是，决定哪些交易进入这些区块以及以何种顺序进入的过程并不是一个中立的过程。

Leader 对区块生产的垄断

区块生产根据 Leader 调度表轮换，其中每次由一个验证者负责在给定窗口内生产区块。在此期间，交易被直接转发到 Leader 的交易处理单元 (TPU)，Leader 通常比任何人都先收到这些交易。Leader 占据着一个拥有非凡权力的位置。即，他们可以在交易公开可见之前观察到进入的交易。Leader 可以决定不包含某些交易，任意重新排序，或者引入自己的交易。这是当前单 Leader 共识运作方式的一个结构性特征，并在当今几乎所有生产环境中的 权益证明 (Proof of Stake) 区块链中都有不同程度的体现。

Solana 缺乏公共 Mempool 进一步加剧了这种不对称性，而非减少。以太坊的公共 Mempool 为参与者提供了对待处理交易的一定可见性，从而在竞争利用交易排序的高级参与者之间创造了一个相对公平的竞争环境。在 Solana 上，考虑到交易转发的性质，Leader 的信息优势更难被挑战。

最大可提取价值 (MEV)

在正常条件下和面对诚实验证者时，这种权力在很大程度上未被利用。然而，问题在于验证者是理性的经济行为者。随着 Solana 的成熟和金融活动的持续增长，利用 Leader 临时垄断所能获得的利润也随之增加。一个选择不利用这个位置的验证者就是在白白丢钱。表现正确的节点在经济上处于劣势——这种劣势会激励他们去破坏他们所参与的系统本身的质量。

这种可提取的利润被称为 最大可提取价值 (MEV)，这个术语最早由 Daian 等人在 Flash Boys 2.0 中正式提出（原为矿工可提取价值），之后被应用于权益证明网络。它涵盖了从套利和抢跑（frontrunning）到三明治攻击、选择性审查，以及任何利用 Leader 相对于其处理交易的用户所拥有的信息和位置优势的策略。

行业对 MEV 的主要反应是提案者-构建者分离 (PBS) 模型，通过 MEV-Boost 在以太坊上实现。在 PBS 下，专业构建者竞相构建使可提取价值最大化的区块，而 Proposer 只需选择产出最丰厚的区块即可。这是对问题的一种务实重构，旨在使 MEV 的获取民主化，并在整个验证者集中重新分配收益，而不是集中在最高级的参与者手中，因为该模型假设 MEV 提取是不可避免的。

这种构想的问题在于 PBS 并未减少对用户的伤害——提取行为仍然存在，只是受益者发生了变化。PBS 解决了 MEV 对网络节点的一些负面影响，但并未减少对网络用户的伤害。

Solana 与 MEV 的关系也在不断演变。快速的区块时间、直接的 TPU 提交以及竞争激烈的验证者集，共同产生了一个以垃圾邮件、Priority Fee 拍卖和验证者层级交易重新排序为特征的独特 MEV 格局。Jito 的区块引擎在某种程度上可以类比为 MEV-Boost，因为它提供了一种链下拍卖机制，搜索者（searcher）在其中竞拍交易排序，所得收益由验证者和质押者共享。也就是说，与 PBS 一样，Jito 以一种更民主的方式管理和重新分配 MEV，而不是彻底消除它。

Constellation 旨在纠正这一点。它不接受 Leader 的垄断并管理其后果，而是寻求从结构上限制这种垄断，使最有害的 MEV 形式在设计上变得不可能实现。Constellation 的白皮书将这一雄心描述为“互联网资本市场的基石，一个经济活动的通用场所，用户可以信任其市场结构是公平的。”

传统金融市场尝试通过监管和司法监督来实施类似的保护。这些保护是被动的且不均衡的，并已被反复证明是不充分的。Constellation 的野心是在协议层面强制执行公平，使其无法被规避或选择性应用。Constellation 寻求通过在 Solana 上实现 多并发提案者 (MCP) 来实现这一目标。

多并发提案者 (MCP)

在传统的单 Leader 区块链中，一个验证者负责生产每个区块。这个验证者（即 Leader）暂时拥有对交易包含和排序的排他性控制权。虽然该验证者被授权生产区块，但网络中的所有其他参与者在该窗口期间都是被动观察者。Leader 最终决定包含哪些交易以及按什么顺序。

这种设计因其简单性而具有吸引力。单一验证者监督区块生产意味着没有协作开销，没有冲突的提案需要解决，以及一个清晰的问责模型。然而，这也意味着一个单一的剥削点。Leader 的临时垄断是 MEV 的根源，到目前为止，所有主要的缓解措施都接受了这种结构，并试图管理其后果。

多并发提案者 (MCP) 是一类从结构层面打破这种垄断的协议设计。MCP 不再轮换到一个拥有排他性区块生产权的单一 Leader，而是允许多个节点同时提出交易。没有任何一个 Proposer 能控制完整的交易集。相反，他们的提案通常由受约束的组装者角色根据协议规则进行合并。

同时向多个 Proposer 提交交易的用户不再依赖于单个节点，因为他们现在拥有多条独立的包含路径。一个试图排除其交易的 Leader 必须面对这样一个事实：其他 Proposer 已经看到了该交易，并且 Attester 已经为其提供了见证。虽然由单个 Leader 组装最终区块，但其自由裁量权受到了严格限制。

MCP 的主要权衡是协作复杂性。允许多个节点同时提出交易引发了单 Leader 设计完全避免的问题。当两个 Proposer 包含相同的交易时，冲突交易如何解决？跨提案的排序如何确定？如何防止高级 Proposer 利用合并规则进行博弈？这增加了相当大的协议复杂度——团队必须处理涉及新节点角色、调度逻辑、加密假设和故障模式的协作挑战，所有这些都需要严格的测试。

这里需要准确一些，因为行业中经常松散地使用 MCP 来指代具有显著不同属性的一系列设计。在低端，MCP 提供概率性的抗审查性——提交给多个 Proposer 的交易更难被审查，因为这样做需要多个节点之间的协调。在高端，MCP 可以提供结构性的抗审查性——如果 Leader 产生了一个审查由足够法定人数见证的交易的区块，这在数学上将是不可能的。这就是 Constellation 的目标，而这种差异对于需要硬性保证的金融应用来说至关重要。

Constellation：工作原理

Constellation 是一个在 Solana 上实现 MCP 的协议。它是 Alpenglow 的补充：Alpenglow 处理共识（即安全性、活跃性和终局性），而 Constellation 处理市场结构——谁有权提出交易，这些提案如何被确认，以及 Leader 被允许如何处理它们。Constellation 生成 Payload，由 Alpenglow 最终确定。

架构

Constellation 为 Solana 的协议栈引入了两个新角色，每个角色都有明确的职责，同时修改了 Leader 和验证者的角色。

Proposer 是交易的入口。在任何给定时间，大约有 16 个 Proposer 同时活跃，由 Stake 随机选择并每 32 个周期（约 1.6 秒）轮换一次。用户直接向他们选择的一个或多个 Proposer 提交交易。Proposer 可以自由接受或拒绝任何交易，前提是接受的交易必须有效。在此阶段没有强制执行交易包含的协议规则；抗审查保证在流程的后续阶段体现。每个 Proposer 以 50 毫秒为一个周期运行。在每个周期内，Proposer 将其接受的交易组装成一个称为 pslice 的结构——“p”前缀不发音，仅用于将其与 Alpenglow 的 slice 区分开来。pslice 被纠删码化为 256 个较小的片段，称为 pshred，并分发给 256 个活跃的 Attester，每个 Attester 收到一个 pshred。纠删码使用 64 的恢复阈值，这意味着 256 个 pshred 中的任何 64 个都足以重建完整的 pslice。每个 pshred 都包含对完整交易列表的加密哈希承诺，确保 Leader 在 Attester 签署后无法替换不同的交易或更改 pslice 内的排序。

Attester 从 Proposer 处接收 pshred，并立即将其转发给接下来的约 2 个 Leader（以应对任何故障或缺席），并记录他们收到的 pslice 的承诺哈希。在每个周期结束时，Attester 签署一份 Attestation——一份加密绑定的声明，列出了它在该周期观察到的每个 pslice 承诺哈希。这份 Attestation 被发送给 Leader，并作为限制 Leader 可以包含哪些交易的证据记录。该记录是权益权重的且经过签名的，这意味着它无法被伪造或被默默忽略。

Constellation 中的 Leader 与 Alpenglow 的 Leader 相同——负责生产进入共识的最终区块的节点。在 Constellation 下的不同之处在于，Leader 的自由裁量权受到 Attestation 记录的严格限制。Constellation 强制执行两个截然不同的阈值。为了使聚合的 Attestation 有效，必须有至少 60% 的 Attester 参与。如果未达到此阈值，则整个区块将被跳过。在此范围内，任何已被至少 40% 的 Attester 见证的 pslice 都必须由 Leader 包含。如果不这样做，将产生一个无效区块，网络将拒绝该区块。这种双阈值设计将区块级有效性与每个 Proposer 的包含情况分开。即，即使某些 Proposer 的数据未到达足够多的 Attester，Leader 仍可产生有效区块，但不能选择性地排除数据已送达的 Proposer。一旦 Leader 将所有经过见证的 pslice 编译成一个批次（Batch），它就会通过 Alpenglow 的 Rotor 将该批次传输给验证者。

验证者通过 Rotor 从 Leader 接收 Batch，并在 Batch 到达时执行流水线化执行。一旦收到完整区块，验证者会根据 Attestation 记录对其进行检查，以确认每个经过见证的 pslice 在区块中都有相应的提交。只有通过所有检查，验证者才会投票最终确定该区块；如果检查失败，验证者将通过 TrySkipWindow 调用投票跳过 Leader 的整个窗口。

周期 (Cycles) 与 Slot

周期是 Constellation 的基本时间单位。它是一个 50 毫秒的窗口，通过将 Unix 纳秒时间戳除以 50,000,000，从 UTC 挂钟时间衍生而来。关键在于，周期不是与 Alpenglow 的 Slot 对齐的。一个 Slot 包含多个周期，而跨这些周期产生的 Batch 构成了 Leader 区块的 Payload。这种区别很重要，因为 50ms 周期是经济跳动（即强制执行抗审查的窗口），而 Slot 仍然是 Alpenglow 的共识单位。

白皮书指定了 Proposer 和 Attester 之间时钟偏移的容差，并相应调整了 Attestation 窗口。为了说明其重要性，假设一个 Proposer 的时钟比 Attester 集快 5ms。该 Proposer 的 pshred 可能会比预期的周期边界更早到达 Attester，从而使该 pslice 中的交易有稍大的窗口来积累见证。相反，时钟落后的 Proposer 可能会发现其 pshred 到达得太晚，以至于完全落出 Attestation 窗口，即使该 Proposer 是“准时”提交的。在利用 chrony 或 GPS 接收器等工具的数据中心环境中，时钟同步是常规操作，偏移通常在亚毫秒级，远在 Constellation 的容差范围内。令人担忧的是，Constellation 引入了一个在 Alpenglow 的纯逻辑时间模型下不存在的新变量，并且 Constellation 最终的 SIMD 应该为其指定监控边界。

当 Constellation 接近 Epoch 结束时，Proposer 和 Attester 可能会短暂地不确定下一个 Epoch 是否已经开始。在此窗口期间，Constellation 在两个 Epoch 中并发运行，两组 Proposer 和 Attester 同时活跃。Alpenglow 的共识自然会解决哪些周期属于哪个 Epoch。

交易生命周期与费用

一笔交易在执行前必须通过四个关卡：

• 它必须被 Proposer 接受并包含在 pslice 中。
• 该 pslice 必须积累足够的 Attestation 才能被包含在 Leader 的 Batch 中。
• 该交易必须有足够高的出价，才能在 Batch 的计算限制内被选中执行。
• 包含该 Batch 的区块必须得到 Alpenglow 共识的确认。

每笔交易都带有一个出价（即每个计算单位的执行费用），该出价决定了其在同一 Batch 内的排序。出价越高，越先执行。

Constellation 将交易成本分为两个截然不同的部分：

• 包含费 (Inclusion Fee)。
• 排序费 (Ordering Fee)。

包含费是根据交易大小和签名数量收取的少量固定费用。它支付给将交易包含在其 pslice 中的 Proposer，并从交易跨过 Attestation 阈值的时刻起收取，无论其最终是否执行。这类似于 Solana 当前系统的 Base Fee，但有一个重要的注意事项：如果用户为了冗余将同一笔交易提交给三个 Proposer，由于每个 Proposer 都独立完成了将其包含在内的核算工作，用户将支付三次包含费（即每个 Proposer 一次）。因此，如果用户向 n 个不同的 Proposer 提交同一笔交易以实现冗余，他们将支付 n 次包含费。

排序费是较大的、基于优先级的组成部分，即交易的总计算单位乘以其出价。这只有一次会被收取，因为无论有多少个 Proposer 包含该交易，它只能被执行一次。例如，一笔请求 200,000 个计算单位、出价为每计算单位 0.00001 SOL 的交易，支付 2 SOL 的排序费。如果这笔交易为了冗余被提交给四个 Proposer，用户将支付四次包含费加上一次 2 SOL 的排序费。排序费按节点 Stake 比例返还给生态系统——白皮书将该机制的设计留给了其最终的 SIMD。

每个付费账户必须维持约 0.001 SOL 的最低储备余额，以防止并发 Proposer 之间的费用操纵。这确保了即使多个并发 Proposer 包含涉及同一账户的交易，包含费也总能得到支付。

Constellation 与 Alpenglow

Alpenglow 是 Solana 的共识协议。它决定哪些区块有效、它们的最终确定顺序，以及网络如何从故障中恢复。它的 Votor 和 Rotor 组件取代了 Tower BFT 和基于 Gossip 的投票传播，显著降低了终局性时间。Alpenglow 对谁提出交易或区块内排序如何确定只字未提。

Constellation 是一个市场结构层，它限制了 Alpenglow Leader 被允许对其组装的区块进行的操作——它定义了谁提出交易以及每个区块内的排序如何确定。Constellation 产生的 Batch 成为 Alpenglow 区块的 Payload。随后，Alpenglow 的 Votor 根据其预定义的投票规则对这些区块进行公证。这两个协议结合在一起，使得 Alpenglow 提供安全性和活跃性，而 Constellation 提供排序公平性。

这种可组合性意味着 Constellation 也继承了 Alpenglow 的安全假设，而没有削弱它们。Constellation 不会触碰 Alpenglow 的保证。相反，它在其新的基于周期的计时模型中，为新的 Proposer 和 Attester 角色以及 UTC 挂钟同步引入了新的保证和假设。

Constellation 是在可扩展的生产级区块链上实现 MCP 的第一个正式协议级提案。它是为 Solana 引入抗审查性的重要补充——也是 Alpenglow 开启的协议路线图的下一章。

抗审查性到底需要什么

MEV 文献历来通过几个不同的维度来处理该问题，这些维度结合在一起，勾勒出任何抗审查提案实际需要解决的更统一图景。借鉴 Eskandari 等人基础的抢跑攻击分类学、Garimidi 等人正式的 MCP 协议双属性框架，以及 Landers 和 Marsh 对 MCP 特定 MEV 渠道的分析，我们建议将攻击面组织成三个不同的层级，每一层都需要不同类别的解决方案。这个框架是我们自己的综合，在此引入以评估 Constellation 的设计。

第一层：硬审查 (Hard Censorship)

硬审查是指 Leader 或 Proposer 拒绝包含他们已识别出的交易的能力。这是操纵中最易察觉的形式，Constellation 从结构上解决了这一问题。在 Constellation 下，如果 Leader 产生了一个排除掉由足够法定人数见证的费用竞争性交易的有效区块，这在加密层面上是不可能的。由于这种执行是架构性的，因此不需要 Slashing（罚没）。

第二层：内容可见排序 (Content-Visible Ordering)

第二层更难解决。虽然 Proposer 无法直接审查，但他们仍然可以在最终排序之前观察交易内容，并试图利用这种可见性（例如，夹击大额交易）。这就是 Garimidi 等人所形式化的隐藏属性（Hiding Property）——在确认之前，对手绝不能看到交易内容。Constellation 实现了部分隐藏。即，交易仅对接收该交易的 Proposer 可见，而不是对所有 Proposer 可见，且 Leader 只有在周期截止日期过后才能看到交易内容。这比完全可见要好，但并未完全满足 Garimidi 等人的隐藏属性，该属性要求在确认前，交易内容对所有各方都是不可见的。接收交易的 Proposer 仍然可以观察并利用它收到的交易内容。

Constellation 更深层的担忧在于，具有公共交易提交功能的 MCP 可能会放大内容可见的剥削。这引入了一个系统，其中每个 Proposer 观察其收到的交易，并可以在其自己的 pslice 内利用该可见性。攻击面与单 Leader 模型不同，因为多个实体可以各自看到一部分交易。向单个 Proposer 提交交易的用户仅向该 Proposer 暴露其交易。但为了冗余向多个 Proposer 提交交易的用户会成比例地扩大其暴露面。Landers 和 Marsh 形式化了这种动态：并发区块生产创造了时间博弈、同周期（Same-tick）复制机会，以及结构上缺乏单一构建者瓶颈，而这一瓶颈目前限制了每笔受害者交易可落地的提取尝试次数。在不解决内容可见性的情况下分散 Proposer 集，会成倍增加 MEV 攻击面而非减少它。

Landers 和 Marsh 对 MCP 特定 MEV 渠道的分析假设了比 Constellation 提供的更广泛的内容可见性。在 Constellation 的部分隐藏机制下，内容可见剥削的放大是用户提交策略的函数，而非架构上的必然。向单个受信任 Proposer 提交交易的用户的內容暴露概况与今天的单 Leader 模型大致相同。权衡在于，向单个 Proposer 提交牺牲了抗审查性所依赖的冗余。

第三层：时间与延迟操纵

最微妙且最难惩罚的层级涉及时间和延迟操纵。在 Constellation 下，Proposer 可能会延迟向 Attester 转发 pshred，延迟时间恰好使竞争对手的交易落出见证窗口，或者利用 UTC 时钟偏移来操纵哪些交易能积累足够的见证。这一差距在 Constellation 白皮书中被直接承认：消息延迟交付“无法被惩罚”，因为它与真实的传输延迟无法区分。这是 Slashing 可能变得相关的层级，也是 Constellation 最终 SIMD 需要解决的主要悬而未决的问题。

Constellation 设计的一个基本假设是，Proposer 与用户之间的关系不是匿名的——这是一种重复的互动，其中信任是可衡量的，声誉是重要的。在任何给定时间大约有 16 个活跃的 Proposer，如果用户经历了一个 Proposer 持续的糟糕对待，他们可以开始向其他 15 个中的一个提交。虽然这不会产生任何可用于直接惩罚坏人的链上证据，但它会为剥削其地位的 Proposer 带来经济后果。这种声誉压力与 Slashing 等解决方案相比，是否足以威慑时间操纵，是一个开放性问题，可能取决于随着时间的推移，Proposer 的行为对用户变得多么透明。

对验证者和用户的影响

验证者

Constellation 重新分配了验证者之间的 MEV 机会，而不是完全消除它们。设计上，今天 Leader 可获得的最清晰且可直接提取的收入来源（即硬审查）已变得不可能。然而，取而代之的是一系列更微妙、更难惩罚的时间渠道，这些渠道有利于具有延迟优势、精确时钟同步以及能够持续利用 pshred 转发窗口的验证者。净效应是验证者提取价值方式的转变，而非总提取面的减少。唯一的注意事项是提取变得明显更加困难。

Constellation 并未引入根本上的新费用流，而是重构了现有费用流。包含费类似于今天的 Base Fee，排序费对应现有的 Priority Fee。预计分配比例与验证者今天的收益相似。区别主要在运营方面。即，优秀的运营商作为 Proposer 应该赢得更多包含费，在现有经济体系中创造一个基于性能的梯度，而不是一个单独的收入类别。在当前设计中，Attester 角色没有单独的补偿。其理由是，就像目前参与 Turbine 一样，该角色预计会被执行，因为它对网络有净收益。更重大的经济转变是目前通过协议外落地服务、基于市场的拍卖和链下费用安排流动的活动，这些活动应该回到协议内，更直接地惠及验证者。然而，在 SIMD 指定确切机制之前，对单个验证者的净经济影响——特别是小型验证者，因为权益权重选择减少了 Proposer 频率，且基础设施开销提高了成本底线——仍然是一个悬而未决的问题。

Proposer 和 Attester 是根据权益权重选择的，这意味着塑造验证者经济的中心化动态也会塑造这些角色的参与情况。如果少数高权益验证者主导了 Proposer 的选择，抗审查保证在形式上保持完整，但在实践中，Proposer 集的实际多样性会缩小，尽管仍比 Solana 今天的现状有所改善（即 n 选 1 对比 n 选 16）。即使在理论上成立，独立性假设在实践中也会开始减弱。鉴于 验证者即服务 (VaaS) 产品的出现，这反映了一个值得注意的担忧，即单个实体可能会运营多个高权益验证者。SIMD 是否会引入任何反中心化机制或 Proposer 选择激励，是一个与 Constellation 所宣传的保证强度直接相关的设计问题。

用户

对于用户而言，向足够数量的 Proposer 提交的具有费用竞争力的交易，第一次受到了针对选择性排除的硬性协议保护。现在可以利用前所未有的保证来构建金融应用，改变了 Solana 的可能性边界。

高频且对价格敏感的用户现在必须向多个 Proposer 提交交易以实现冗余。令人担忧的是，在不解决内容可见性的情况下分散 Proposer 集可能会增加遭受三明治攻击的风险——每个 Proposer 都可以观察并处理提交给它的交易，这意味着为了冗余而向多个 Proposer 提交交易的用户，按比例增加了看到其交易内容的人数。这样做本质上移除了单 Leader 瓶颈，转而将交易意图广播给更广泛的潜在对手。实际的影响是，更高级的用户将需要开发新的提交策略来平衡冗余与暴露风险，可能涉及根据声誉或 Stake 选择性地针对 Proposer，例如，而不是采用广泛的多重提交策略。

特别是对于做市商而言，Constellation 的包含保证消除了基础设施决定执行质量的对抗性风险。剩下的只是纯粹的信息不对称，这与做市商在当今最好的传统交易场所面临的风险概况相同。这种趋同使支持包含延迟降低的论点变得具体而非空谈。这种趋同在我们的“悬而未决的问题”部分有更详尽的讨论。

普通用户感知到的体验净变化可能很微小，但包含保证是可靠性方面的重大改进。在未来的基准测试出来之前，对序列延迟的净影响仍是一个开放的实证问题。

景观：Constellation 的对比

Sei Giga

在当前的 MCP 领域中，Sei Giga 是最接近 Constellation 的类比。也就是说，它是一个将 MCP 作为首要架构优先级而非未来研究目标的生产级区块链。对比两者是有启发意义的，因为它们在同一层级做出了不同的权衡。

Giga 的共识基础被称为 Autobahn，这是一种多提案者 BFT 协议，其中每个验证者在并行中持续运营自己的提案“车道”（Lane）。Autobahn 不依赖于单个 Leader，而是每个节点持续在独立车道中传播自己的数据提案流，共识层定期提交一个“Tip Cut”，这是一个汇总所有车道最新提案的紧凑快照。这在架构上与 Constellation 模型不同，后者大约有 16 个选定的 Proposer 在固定的 50ms 周期内运行。Autobahn 的车道模型允许任何验证者维持持续的提案车道，而不是从轮换的、权益权重的子集中选择，从而大大拓宽了区块生产的参与度。

最重要的区别在于内容可见排序。Autobahn 通过将交易排序与执行解耦来实现异步执行，这是 Constellation 推迟做出的设计选择。如后续章节所述，异步执行通过防止 Proposer 在排序时针对已知的最终状态模拟执行结果，缩小了内容可见排序的攻击面。

Giga 提供概率性的抗审查性，而 Constellation 提供结构性保证。Giga 背后的信念是，提交给多个 Proposer 的交易更难被审查，因为每个 Proposer 的信息都是不完整的，如果另一个 Proposer 在同一个 Tick 中包含了该交易，审查的效用可能会丧失。相比之下，在 Constellation 下，排除已充分见证交易的 Leader 会产生无效区块。概率性抵抗提高了审查成本，而结构性抵抗使审查在加密上变得不可能。对于两个协议都试图实现的金融应用来说，这种差异至关重要。

应当坦诚对待这两种设计在野心上的差异。Constellation 是一份证明正确性、定义故障条件、指定法定人数阈值的协议规范，旨在作为一份正式提案提交给拥有数十亿质押价值的可扩展生产网络。Sei Giga 的白皮书读起来则有所不同，它更倾向于吞吐量声明和 EVM 兼容性，将 MEV 和抗审查性视为多提案者架构的衍生收益，而非正式指定的保证。异步执行在方向上是正确的，但 Giga 在排序约束、Attester 法定人数或故障条件方面并未提供与 Constellation 同等水平的正式保证。这并不是对 Giga 排序选择的批评，更多是反映了背景的不同——Constellation 是在世界上吞吐量最高的生产级区块链之上提出的，这要求并提供了相应更高标准的规范。

学术理想

MCP 设计的理论基准是 a16z Crypto Research 的 Garimidi 和 Neu 以及 Anza 的 Max Resnick 撰写的 多并发提案者：原因与方法 (2025)。该论文提出了一种 MCP 协议，它提供了抗审查设计必须满足的两个属性：选择性抗审查和隐藏。前者保证对手无法选择性地延迟交易，而后者保证交易内容在确认前保持不可见。这是当前文献中唯一同时正式实现这两点的 MCP 设计。

实现隐藏的机制是 HECC——隐藏纠删码（Hiding Erasure-Correcting Code）。它的参数设置使得任何 T 个 Shred 都不会泄露有关底层交易批次的任何信息，而 K + T 个 Shred 即可实现完全重建。关键细节在于，中继只有在共识确认包含哪些批次后才广播其存储的 Shred。这防止了任何确认前对交易内容的观察，从信息论保证的角度完全封闭了内容可见排序的攻击面。

根据早前开发的框架，该协议设计是唯一一个通过结构性抗审查解决第一层、通过隐藏解决第二层、并因隐藏提供的抗审查保证而限制了第三层的设计。Constellation 和 Giga 都没有完全实现这一点。

让这一对比特别有趣的是，理论理想的共同作者 Resnick 也是 Constellation 的共同作者，而 Constellation 协议却有意偏离了这一理想。这反映了一种深思熟虑的判断：完全基于 HECC 的设计尚未能在 Solana 这种规模的生产网络上部署，结构性抗审查是更迫切需要首先解决的问题。该论文充当了 Constellation 的北极星：一份关于协议建设目标的正式规范，即使目前无法一次性交付。

以太坊 Braid

Braid 是以太坊主要的 MCP 提案，由 Max Resnick 引入，目前正作为以太坊 Scourge 路线图的一部分，与竞争对手 FOCIL 包含列表设计一起被考虑。将其列入此处较少是为了技术对比，更多是为了背景说明；整个行业都在尝试从不同的起点解决相同的结构性问题。

Braid 实现 MCP 的方式是允许多个 Proposer 在同一个 Slot 内同时跨并行链构建区块，执行层根据预定规则对交易进行聚合、去重和排序。它没有引入额外的协议角色。最显著的区别在于，Braid 的安全性在很大程度上依赖于加密 Mempool，这使得隐藏成为了前提条件而非推迟项。Braid 目前仍是一个未部署的研究提案，以太坊社区尚未就选择它还是 FOCIL 达成共识。

Braid 最终确认的是，MCP 的结构性论点超越了任何单一链。同样值得注意的是，Resnick 参与了本节四项内容中的三项，这或许是 Constellation 是对一个棘手问题进行持续、跨背景、学术严谨思考的产物之最清晰信号。

关于 PBS 的说明

提案者-构建者分离 (PBS) 在这里值得作为衬托而非对比设计来提及。在本节中，每项内容都试图从结构上限制 Leader 的临时垄断，而 PBS 接受并围绕它进行优化，以重新分配 MEV 收益。Constellation 明确与 PBS 不兼容——一旦 Leader 的裁量权受到 Attestation 记录的限制，专业构建者就失去了可出售的内容。PBS 已成为以太坊上主流的 MEV 缓解措施，尽管它在减少对用户伤害方面毫无作为，但这恰恰是 MCP 旨在避免的失败模式。

协议外先例

在 Constellation 发布之前，Solana 的生态系统已经在协议外模拟 MCP 的某些方面。例如，Harmonic 是一个开放的区块构建聚合层，它持续收集和评估来自多个独立构建者的区块提案，并实时将其呈献给验证者进行竞争性选择。这并不是形式意义上的 MCP，因为没有协议强制执行的抗审查、Attestation 法定人数或对 Leader 裁量权的加密限制。然而，运行 Harmonic 的验证者已经在多个并发区块提案之间进行选择，这是 MCP 寻求确立的核心机制。与 BAM 一起，两者代表了生态系统在不等待协议级强制执行的情况下解决市场结构问题的尝试。这些协议外系统证明，对类似 MCP 属性的需求是真实存在的，以至于构建者们不愿坐等 Constellation 上线。

悬而未决的问题

Constellation 的白皮书是一份协议规范。它证明了所述假设下的正确性属性，并正确地推迟了其他一切工作，这对于 0.9 版本的提案是合适的。接下来的内容不是 Constellation 失败清单，而是其最终 SIMD 和未来迭代需要解决的问题图景，以便有效地将 MCP 引入 Solana。

这些问题的难度并不均等。有些是规范工作；Anza 可以且应该通过正常的 SIMD 流程解决的设计决策。其他一些则是更广泛的 MCP 研究社区尚未解决的真正开放性问题，但当我们作为第一个在大规模上实现 MCP 的区块链而开辟道路时，必须意识到这些问题。没有任何单一的 SIMD 能解决这些问题。这种区分很重要，因为混淆两者可能会夸大 Constellation 的差距，或者低估剩余的工作量。

简单的 SIMD 工作包括：

• 费用分配：描述了 Priority Fee 如何在 Proposer、Attester 和更广泛的验证者集之间分配，但尚未完全概述。白皮书指出，Priority Fee 按 Stake 比例返还给生态系统，但 Proposer、Attester 和验证者之间的确切分配机制尚未定义。
• 验证者奖励结构：Proposer 相对于现有验证者奖励如何获得补偿，以及在 Alpenglow 下移除投票交易费是否会改变小型验证者的计算方式。
• 部署顺序：Constellation 依赖于 Alpenglow，后者计划于 2026 年第三季度上线。SIMD 需要明确指定依赖关系，并解决从原生 Alpenglow 向 Constellation+Alpenglow 过渡窗口期间会发生什么。是否有任何先决条件的 SIMD 应该首先上线主网？
• 角色参数治理：白皮书中表 1 给出的 Proposer 数量 (p ≈ 16)、Attester 数量 (q ≈ 256)、周期持续时间 (△cycle = 50ms) 及其他参数仅作为建议提出。SIMD 需要指定这些参数应如何设置、治理以及随时间推移可能进行的更改。

较难的问题（如异步执行、Slashing、提交层隐私）将在以下小节中讨论。这些是 MCP 研究社区正在积极处理的问题，我们必须予以考虑，因为 Constellation 的设计选择可能会缩小或拓宽通往某些最终解决方案的路径。

异步执行

在同步执行下，以明文形式接收交易或可以在朴素提交模型下提前解码交易的 Proposer 知道交易内容，并可以模拟其结果。Proposer 可以针对当前状态运行交易，以计算出准确的执行结果，包括兑换价格、账户余额变化以及下游套利机会。这就是三明治攻击在机械层面上精确执行的原因。攻击者可以看到大额兑换，并计算出需要抢跑多少才能使利润最大化。

异步执行移除了后半部分的优势，但前提是必须与 MCP 结合。如果共识在执行前就确定了交易排序，那么能够看到交易内容的 Proposer 就无法针对已知的最终状态模拟执行结果，因为在排序时该状态并不存在。信息优势实际上从“我知道这笔交易做什么以及按什么顺序执行”缩小到了“我知道这笔交易是什么，但不知道它相对于最终排序集的具体表现”。这种收益取决于 Proposer 不控制最终排序。在单 Leader 模型下，仅凭异步执行无法提供这种保护，因为 Leader 仍然可以完全控制排序，并且无论执行何时发生，都可以有利地放置自己的交易。正是排序受限和延迟执行的结合缩小了攻击面。

请注意，异步执行并不能完全封闭第二层。高级 Proposer 仍然可以进行类别推断。也就是说，Proposer 仍然可以看到一笔交易涉及特定的流动性池，例如，并可能推断出可能的方向而不知道确切结果。这有意义地提高了针对最机械和最有利可图的剥削形式的门槛，并代表了在不需要共识层加密隐藏的情况下缩小第二层的最清晰架构路径。值得注意的是，这正是 Sei Giga 选择的方法，将异步执行与 MCP 一起作为首要架构优先级。

这自然引出了一个值得深思的问题：为什么不先追求异步执行？ 它缩小了第二层，并且原则上可以作为一种受限的执行层变更来追求，而无需引入 MCP 额外的协议复杂性（即新节点角色、UTC 时钟同步要求、未解决的 Slashing 设计以及翻倍的 Shred 分发开销）。

这种排序最强有力的理由是异步执行和 MCP 解决的是不同的问题。MCP 提供了异步执行本身无法提供的结构性排序约束——一个无法模拟执行结果但仍能看到交易内容的验证者，仍然可以在协议允许的窗口内行使对排序的裁量权。优先追求 MCP 的理由是，它在结构层面限制了第一层，而第一层是更清晰且在经济上更迫切的威胁。考虑到 Solana 的可组合性假设和程序架构，将异步执行改造成其现有的同步执行模型，是一个比从零开始在链中构建它更困难的工程问题。Sei Giga 拥有从第一天起就为异步执行进行设计的奢侈，而 Solana 则没有。这种实际的不对称性对于解释为何先追求 MCP 可能与理论上的优先级争论同样重要。Alpenglow 的架构也使得 MCP 比在 Tower BFT 下更具可行性，我们将在后续关于协议复杂性的章节中探讨这一点。

这种排序是否正确是一个合理的开放性问题。Constellation 完整保留了第二层，鉴于 MCP 在第三层引入的新攻击向量，这可能会有问题。反过来，这可能会使第二层攻击更有利可图，因为这两个攻击面是互补的。例如，看到大额 DEX 交易的 Proposer 可能会延迟其 pshred，将其推离当前 Batch 窗口，同时在同一窗口内用自己的交易进行抢跑。第二层的可见性和第三层的时间博弈是同一攻击面中不可或缺的武器，并随着 Solana 的成熟只会变得更加复杂。

Slashing (罚没)

当行为者的错误行为产生可验证的证据（如冲突签名、有效性检查失败、可证明的错误承诺）时，加密强制执行效果良好。Constellation 之所以能如此清晰地解决第一层的抗审查问题，是因为排除已见证交易的 Leader 会产生无效区块，而这种无效性在数学上是可以证明的。时间博弈和延迟操纵则不产生此类证据。困难在于，从单次行为的层面上看，此类不当行为与诚实网络延迟是无法区分的。这种不当行为以一种缺失的形式存在，而这是无法通过加密手段证明的。唯一可用的杠杆是经济威慑，这需要 Slashing。

Slashing 面临的挑战在于，它传统上需要一个可证明的罪证。Constellation 的故障证人（Fault Witness）机制处理了签署两个冲突 pshred 的 Proposer 可以被识别并排除的情况。然而，策略性延迟操纵不会产生故障证人。没有模棱两可，没有双重签名，没有链上指纹。一个只是在几毫秒内一直且有选择性地延迟转发 pshred 的 Proposer，没有留下任何可以 Slashing 的证据。

如果一个 Proposer 的 pshred 总是持续在周期窗口的最后几毫秒到达 Attester——跨越许多个周期，且这些交易恰好是该 Proposer 自身提交交易的竞争对手——一个定义明确的 Slashing 机制可以将这种模式视为系统性操纵的证据，而无需单个可证明的恶意行为。传统的 Slashing 无法直接解决这个问题。规范形式的 Slashing 需要一个明确、自洽的证据，而对于仅仅将转发延迟了几毫秒的 Proposer 来说，并不存在这种证据。不同之处在于模式。

在监管机构处理基于延迟的操纵的方法上，传统金融对去中心化金融可能具有启发意义。例如，Dodd-Frank Act 下对虚假报价（Spoofing）的执法，依赖于检测统计模式（如成交取消比、取消时间分布、价格影响相关性），而不是证明任何单个订单的意图。没有任何单个案例是可证明有意的。然而，这种模式是。同样的逻辑也适用，因为即使个体行为不具有客观性，统计规律也是客观的。此外，许可制 Proposer 集中操纵的经济动机与传统金融中高频交易员所面临的一样。类比失效的地方在于执行。也就是说，Dodd-Frank 依赖于拥有传票权的监管机构，而无信任背景要求检测和惩罚机制本身必须铭刻在协议中。

我们建议改编 Fisherman 节点作为候选机制来弥补这一差距。最初由 Vitalik 在数据可用性研究中引入，Fisherman 节点可以被改造为一类观察者，它们监视跨多个周期的 Attestation 数据，并向内置的仲裁协议提交统计欺诈证明。单次延迟到达是主观的。然而，跨 n 个周期确定性计算出的模式是客观的。这与乐观回滚（Optimistic Rollups）中欺诈证明背后的洞察力是一致的，只不过应用于计时行为而非状态转换。此外，用于统计欺诈证明的内置仲裁协议，在本质上与目前正在开发的新治理工具并没有区别，这些工具将允许质押者在未来的治理提案中覆盖其验证者的投票。如果 Solana 准备好为质押者投票覆盖建立基础设施，那么基于 Fisherman 的仲裁系统的技术基础可能比看起来更近。

这种对 Fisherman 节点的探索，代表了一个比将规范 Slashing 扩展到覆盖未留下单个链上指纹的行为更可靠的方向，并且协议当前治理基础设施的开发可能已经为此做好了准备。

话虽如此，任何具体的规范都需要解决三个局限性。首先，对成千上万个周期的 Attestation 计时数据进行统计分析是非平凡的，很容易提高验证者的硬件要求。这增加了运营成本，并可能导致欺诈检测角色集中在少数高级参与者手中。其次，任何阈值规范必须足够鲁棒，以区分真正的网络波动与策略性操纵，同时不能过于保守而产生假阳性。第三，仲裁协议本身引入了一个新的攻击面，这种新的基于 Fisherman 的系统可能会通过协调报告而被操纵。任何仲裁协议的设计都需要考虑到这一点，可能通过激励机制使小型参与者运行 Fisherman 变得可行，或者通过聚合方案在 Fisherman 集之间分配计算。

我们要提出的具体研究问题是：能否指定一个统计欺诈证明框架——定义阈值参数、考虑网络波动以及惩罚如何定标——该框架既足够强大以阻止系统性延迟操纵，又足够保守以避免惩罚诚实波动，且足够简单以抵抗高级运营商的对抗性博弈？这是 MCP 文献中技术要求最高的开放性问题之一，也是更广泛的研究社区尚未解决的问题。

隐藏 (Hiding)

Slashing 并不是时间和延迟操纵博弈的唯一解决方案。隐藏机制同时解决了内容可见排序以及时间与延迟操纵问题，而异步执行或 Slashing 本身都无法解决这些问题。Constellation 实现了部分隐藏（即交易内容仅对接收 Proposer 可见，并在周期截止日期后对 Leader 可见），但未达到完全隐藏属性。攻击面随用户选择提交的 Proposer 数量而扩大。虽然这种部分隐藏相对于完全可见缩小了攻击面，但并未封闭它。在确认前没有任何一方能观察到交易内容的完全隐藏，对于 Constellation 来说仍是一个待解决的问题。

理论上的理想方案是 Garimidi 等人概述的方法，它使用隐藏纠删码 (HECC) 作为原语。与 Constellation 标准的 Reed-Solomon 不同，HECC 提供了一种信息论保证，即对手收集的 Shred 少于阈值时，无法获知任何有关交易内容的信息。Constellation 选择继续使用目前通过 Turbine 在 Solana 上运行的纠删码。

最近最相关的进展是 Jito 的 区块组装市场 (BAM)，它使用可信执行环境 (TEE) 创建了一个加密 Mempool，交易在执行前保持私密。BAM 证明了 Solana 上对内容隐私的实质性需求正在增长。然而，基于 TEE 的隐藏并非没有局限性，它将信任假设转移到了硬件制造商身上，这对于一个追求无信任运营的协议来说是一个重大限制。应该深入探索一条使用门限加密提供更规范替代方案的道路。

BAM 的重要性在于它代表了一种在协议外解决内容可见性问题的尝试，而 Constellation 推迟了这一点。在 Constellation 发布之前，Jito 在运营定位上已经能够通过 BAM 大规模提供交易隐私。这就引出了一个问题：如果应用层解决方案已经能提供隐私，协议级隐藏是否仍然紧迫。答案完全取决于信任假设，以及与协议理论上能提供的保证相比，硬件制造商是否“足够”被信任。尽管如此，这不能被视为永久的解决方案。可能的路径是 BAM 将提供近期隐私，而 Constellation 的最终迭代将探索门限加密作为更长期的替代方案。

对于一个渴望成为互联网资本市场基础设施的协议来说，部分隐藏是向前迈出的有意义的一步，但不是终点。剩下的差距是公平市场结构与仅仅比现状不公平程度稍低的市场结构之间的区别。

协议复杂度

Constellation 是 Solana 自诞生以来提出的结构上最雄心勃勃的升级。它引入了三个新的节点角色、一个依赖 UTC 挂钟同步的新计时模型、新的纠删码处理、新的消息类型和新的故障模式，所有这些都叠加在尚未在主网运行的 Alpenglow 之上。现在是否是承担这种复杂性的正确时机，这是一个严肃的问题，需要的不仅仅是乐观。

Solana 过去因其在 2021 年和 2022 年期间困扰网络的多次停机而臭名昭著。这些停机有一个共同的主题——它们是由在现实负载条件下推理新型高吞吐量协议中的极端情况的固有难度引起的。网络近期实现的两多年持续运行是一个真正的里程碑，这是在痛苦的迭代之火中锻造出来的。这一记录为 Solana 的成熟度提供了信心。

现在，任何具有 Constellation 这种量级的协议级变更都需要在 Agave 和 Firedancer 中同步实现。这需要两个独立的开发团队在对双方来说都是新颖的协议语义、极端情况和计时假设上达成一致。仅实现 Alpenglow 的复杂性就已经非常大，Constellation 只会使情况更加复杂。这并不是反对继续进行的理由。相反，它论证了 Constellation 最终的 SIMD 必须包含一个清晰的多客户端实现计划。

金融机构正开始进入链上。一次重大停机的代价在声誉和经济损失方面都比 2021 年高得多。作为一个社区，我们需要诚实面对 Constellation 引入的复杂性。最终的 SIMD 必须以全球金融体系应有的严谨态度来对待。

很自然地，为什么是现在的问题就出现了。我们真的想承担这样一次升级的风险吗？难道我们不能随着时间的推移进行增量升级来缓解这种变化吗？前述对异步执行和 Slashing 的探索表明，增量替代方案是可能的。一个生态系统可以从各种补充升级的阶段性部署中受益的 Constellation 路线图版本是可能的。这被视为审慎还是减速主义，既是一个价值观问题也是一个技术问题，理性的各方可以有不同的意见。我们既是在建立一个意义系统，也是在建立一个金融系统。

这已经在实践中发生。Anza 已确认 200ms Slot 和双 Slot Leader 窗口将在 Constellation 之前发布。这意味着 Solana 将看到有意义的性能改进，解决了社区提出的一些序列延迟担忧，这将在下一节中讨论，而无需 MCP 的完整复杂度。如果 200ms Slot 使 Solana 的确认路径足够接近 Constellation 预估的开销，从而使 MCP 的边际成本变小，那么政治上的理由就变得容易得多。然而，如果当前的交易参与者认为 200ms “足够好”，那么对 Constellation 的紧迫感就会减弱。展示 200ms Slot 与 200ms Slot 加 Constellation 的对比延迟预测，可以帮助社区权衡增量成本与增量保证。当然，我们需要等待 Constellation 最终的 SIMD 和提议的实现。

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

如果不是现在，那又待何时？

这种复杂性是合理的，但这种合理性需要通过严谨的规范、阶段性部署以及对目前社区仅基于理论讨论的延迟和带宽主张进行实证验证来赢得。

Constellation 是否符合 IBRL？

序列延迟与包含延迟

社区对 Constellation 的最初反应，婉转地说，是两极分化的。这种反应引发了一场重要的辩论，它需要一个精确的答案而不是圆滑的回答。最犀利的表述来自 Cavey 的推文，称“MCP 与 IBRL 根本不兼容”。他认为，为了改善市场结构，MCP 直接且毫无疑问地降低了带宽并增加了延迟。而 Toly 对此的回应同样直接：“你错了。不通过 MCP 根本无法减少包含延迟。”

两者在技术上都是正确的；他们衡量的是不同的东西。

MCP 降低了包含延迟，增加了序列延迟。它们不是同一个属性，混淆两者是当前辩论中大部分混乱的根源。

序列延迟（Sequence Latency）是从交易提交到执行的时间。在 MCP 下，这不可避免地会增加，因为 Attester 轮次、50ms 周期窗口和批处理组装步骤都增加了原本在与配合的 Leader 之间的 TPU 直接提交路径中不存在的时间。关于理性 Agent 发送到多个 Proposer 会消耗更多带宽的批评是正确的。合并窗口增加延迟也是正确的。在移除硬审查的权衡中，这些都是应该被衡量并呈现给社区的真实成本。

包含延迟（Inclusion Latency）是有效的、具有费用竞争力的交易被包含在内的保证时间窗口。在今天的单 Leader 模型下，这种保证基本上是无界的。也就是说，想要延迟或排除特定交易的 Leader 可以这样做，且没有协议机制来阻止。用户已经体验到的延迟包括来自持仓、调度和计时博弈的所有摩擦，以及 Leader 强加的选择性排序。现实世界的确认时间包括来自这些博弈的延迟，因此净用户体验可能会得到改善的说法在这种框架下方向是正确的，并得到了目前 X 上社区讨论的支持。

真正的问题是应该优化哪种延迟。

FIFO 对比 FCFS 对比 FBO

在研究优化哪种延迟之前，值得了解社区一直在同步进行的另一场辩论：MCP 是否与 FIFO 兼容。

FIFO（先进先出）是一种通用的排序原则，即按照交易到达的顺序进行处理。Umberto 曾详尽地论证过，答案本质上是微妙的。MCP 可以产生所谓的“概率性 FIFO”，但仅限于特定的基础设施条件下。简单来说，如果用户在地理位置上离足够多的 Proposer 足够近以避免审查，且这些 Proposer 离 Attester 足够近以迅速达到 40% 的见证阈值以确保被包含，那么用户在务实层面就体验到了 FIFO 包含。也就是说，他们的交易在任何竞争对手有时间观察并做出反应之前就被包含了。竞争在包含处结束，而非在执行处。在这些条件下，MCP 将 FIFO 作为一种衍生属性而非协议规则来逼近。

问题在于 Solana 当前的基础设施并不满足这些条件。Stake 集中在少数几个地区，这意味着法定人数的形成受限于触达密集 Stake 区域的需求。这种集中创造了一个窗口，让处于“地理优势”的观察者可以抢跑传输中的交易。Constellation 的部署是否伴随着概率性 FIFO 所要求的地理分布和 Attester 密度，与协议设计本身同样重要。如果一个保证抗审查但因基础设施分布稀疏而允许基于延迟的抢跑，这样的协议将无法兑现其白皮书承诺的市场公平性。

一个相关但不同的问题是，Constellation 是否本可以实现 FCFS 但选择了不实现。虽然 FIFO 是一种衍生的基础设施属性，但 FCFS（先到先得）是一条特定的协议规则，确保先到达的交易得到确定性的处理。值得注意的是，Constellation 确实进行确定性排序——交易在每个 Batch 中按 Priority Fee 排序——因此问题不在于排序是否由协议强制执行，而在于到达时间是否应该相对于 Priority Fee 支配该排序。

最近的辩论引出了比最初提出的更根本的异议——在无信任背景下，FCFS 可能完全无法强制执行。验证者可以简单地歪曲交易到达的顺序，而不会留下任何链上证据。这与使时间操纵在传统意义上不可 Slashing 的“证据缺失”问题是一样的，可能需要更具创造性的解决方案（例如，在 Slashing 小节中开发的统计模式检测方法）。诚实验证者会遵守而失信验证者可以默默忽略的协议规则并不是一种有意义的保证。这重构了 Constellation 对 FCFS 的忽略：从需要解释的设计偏好，转变为承认在许可验证者集中，FCFS 可能根本无法作为一种硬性的协议属性实现在 Solana 上，至少在目前的假设下是这样。如果 FCFS 在当前假设下的许可验证者集中确实无法强制执行，那么 SIMD 的任务就是明确说明这一限制，并证明 Priority Fee 排序是正确的默认设计。如果任由社区像讨论一个 Constellation 选择了不实现的可行方案那样讨论 FCFS，而不是将其描述为一个可能无法实现的属性，将会在社区内产生更多的摩擦。

在固定时间内的 Priority Fee 排序并不是什么新颖的折衷方案。这被称为频繁批量拍卖 (FBA)，是一种具有深厚学术支持的市场微观结构设计。例如，Budish、Cramton 和 Shim 在 高频交易军备竞赛：作为市场设计响应的频繁批量拍卖 (2015) 中论证，具有统一清算价格的离散时间批量拍卖消除了连续时间市场所产生的速度竞赛。这用价格竞争取代了延迟竞争。Constellation 借鉴了这一点，引入了基于 Priority Fee 的固定批量排序 (FBO)。因此，Constellation 的 50ms 周期实例化了这一点，交易在每个 Batch 中竞争的是费用而非到达时间，且同一 Batch 中的所有交易都获得相同的排序待遇。这正是前文确认为目前在 Solana 上尚未大规模存在的应用类别。

关于 FIFO、FCFS 和 FBO 的辩论在很大程度上都围绕着同一个潜在担忧：一旦抗审查性得到保证，谁来控制排序，以及 Constellation 寻求建立的市场结构是真正的公平，还是仅仅比现状稍微不那么不公平。Constellation 封闭了最显眼的操纵形式。取而代之的内容取决于白皮书推迟到 SIMD 去做的选择。

那么，我们要优化的是什么？

序列延迟对于现有的交易应用（即 AMM、自营交易平台、CLOB）最为重要。这些应用的设计假设是：谁最快且在费用上最具竞争力谁就赢，并已据此构建了基础设施。交易应该仅受物理定律约束，在 Solana 上提供无与伦比的用户体验。对于其中的一些用户来说，Constellation 在他们最看重的指标上是倒退了一步。令人担忧的是，Solana 可能会重蹈以太坊曾经犯下的致命错误。即，优先考虑市场结构而非性能，这可能会导致执行流失出链。这是一个值得讨论的合理风险。

对于 Constellation 旨在赋能的金融应用（即链上拍卖、具有可靠包含保证的订单簿、抗审查的 DeFi 协议）来说，包含延迟是正确的指标。与确认名义上多快无关，一个可以被抢跑或选择性延迟的限价单提供的保证比交易所式的订单更弱。Solana 现在可以支持具有统一清算价格的批量拍卖交易应用，在这种应用中，排序不应影响执行价格。这在很大程度上是 Solana 今天并不存在的一类应用，正是因为无法获得包含保证。Constellation 可以说过度索引了一个为尚未在 Solana 上大规模存在的用户而优化的设计，代价是牺牲了已存在的用户；核心贡献者已经提出了这一观点。

目前的背景是，Solana 正在永续合约交易方面被 Hyperliquid 抢占有意义的市场份额。Hyperliquid 是一个专用、中心化排序器的永续合约交易所，它不标榜去中心化，但提供了高级交易者和应用所需的极具吸引力的亚毫秒级执行体验。Hyperliquid 做出了一个深思熟虑的选择，去构建一款专业人士真正想使用的产品，牺牲了让加密货币真正成为“加密货币”的核心准则。Constellation 的隐含风险在于，在确认路径中增加通信开销和见证轮次，与 Hyperliquid 所做的权衡方向一致，但结果相反。批评者对牺牲任何目前让 Solana 与中心化交易应用相比具有竞争力的潜在性能优势表示反感，且呼声颇高，尤其是在目前还没有金融应用能证明这种权衡是合理的情况下。

这种担忧不应被草率地搁置。我们可以将早先关于是优化序列延迟还是包含延迟的问题，重构为：考虑到目前的竞争对手来自哪里，Solana 是否能承受这种权衡。

然而，这里还有一个更深层的问题。与 Hyperliquid 的对比阐明了 IBRL 的含义可能随着时间的推移而发生了变化。Toly 和 Raj 建立 Solana 的最初动机是抗审查性：“为了让 DeFi 产品能够吸引数十亿用户和设备，我们需要扩展抗审查性……这是需要解决的最重要的问题，也是我们建立 Solana 的全部动力。” IBRL 出现得更晚，它是这一使命的工程化表述：建立足够快的网络，使去中心化网络能在重要的指标上超越中心化基础设施。从那时起，IBRL 呈现出一种属于它自己的技术乐观主义含义，并在 Solana 的文化时代精神中无处不在。它既是工程指令、文化口号，也是一种世俗祈祷。对于许多人来说，它已成为目标而非手段，将最小化序列延迟视为目的本身，并脱离了它旨在服务的抗审查目标。

如果这种偏差已经发生（目前看来确实如此），Constellation 将面临坚定的文化阻力。这不是一种新的动态，鉴于社区曾拒绝了 SIMD-228——一个未能通过治理投票的、存在争议的通胀削减提案。即使是最广泛受益的提案，如果与根深蒂固的社区先验认知冲突，也可能会失败。Constellation 的情况更微妙，因为它的带宽和延迟成本是真实的，但它们对用户体验的净影响尚未量化。在没有数据的情况下，朝任何方向得出定论都为时过早。社区目前缺乏、且 Anza 为说服 SIMD 通过而需要提供的是，在现实网络条件下确认路径表现如何的实证数据。Alpenglow 没有遇到这种情况，因为它符合 IBRL：将交易终局性时间缩短 100 倍并简化了共识。Constellation 的理由在直觉上更难建立，但如果未来的基准测试能支持它，它同样是真实的。

目前看来，社区将通过一个抗审查升级从未旨在优化的性能指标来对其进行评判。更有意义的问题是，这种权衡是否值得。存在真实的、可衡量的成本：一些额外的序列延迟和带宽，以换取一个硬性的、协议强制执行的保证，即没有任何 Leader 可以选择性地排除交易。这是 Solana 目前试图吸引的金融应用的前提。

我们的观点是，在对 IBRL 始终旨在瞄准的目标的正确解读下，Constellation 是符合 IBRL 的。社区是否会得出同样的结论，在很大程度上不取决于技术优势，而取决于实证案例是否得以建立以及设计选择是否得到解释。

结论

Constellation 是第一个在大规模生产级区块链上引入 MCP 的正式协议级提案。它从结构上解决了硬审查问题，使得由足够法定人数见证的费用竞争性交易无法被排除在有效区块之外。这种加密保证改变了在 Solana 上可以构建的内容。

Constellation 有意推迟的内容同样重要。内容可见排序通过 Constellation 的提交模型得到部分缓解，即只有接收交易的 Proposer 能看到交易内容，但残余的攻击面随用户提交交易的 Proposer 数量而扩大。时间与延迟操纵仍然是目前设计下不可惩罚的最大未解决问题。已识别出潜在的路径（即异步执行、Slashing、隐藏），但尚未详细说明，每条路径都会引入各自的复杂性。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

• 原文链接： helius.dev/blog/constell...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～