作者：Maven11；翻译：金色财经xiaozou
多重并发提议者（Multiple Concurrent Proposers，以下简称MCP）是指让多个提议者同时处于活跃状态的机制（需注意勿与多上下文协议Multi Context Protocol或安全多方计算MPC混淆，但它们之间的确存在某些相似性），它是解决审查问题的创新方案。本文将探讨为何让多个而非单一提议者负责区块提议成为改进区块链机制设计的关键要素，包括其运作原理与实施意义。
虽然MCP的核心概念相对容易理解，但目前几乎没有区块链实际采用该机制。不过从某种程度上看，比特币的矿池运作模式与多重并发提议者存在相似性——任何运行比特币全节点的人都能让交易被打包上链。
另一方面，Solana的多重并发构建者机制与完整MCP的实现形态有部分共通点，至少体现了多个不同参与者共同参与区块构建（但非区块提议）的理念。而在以太坊上，约95%的区块通过MEV-Boost构建。虽然同时存在多个活跃的构建者，但每次拍卖只能有一个获胜者，因此Solana通过多重并发构建者实现的优势在此并不成立。事实上，目前没有任何一条链能实现多个提议者随时拥有区块提议权。
理解MCP最直观的方式是将其拆解为两个层面：多个提议者同时提供区块，以及这些子区块的最终合并。
这些提议者群体很可能采用子委员会形式（类似以太坊现有机制），因为让全部验证者参与并不现实。这也意味着必须确保单个子委员会不被某个质押池垄断，否则可能引发审查与共谋问题。此外需注意，传说中的家庭质押者通常技术能力有限——MCP将显著增加系统复杂度。
以下是MCP值得被采纳的核心优势：
支持多重并发提议者的理由：
--增强抗审查性（在当前瓶颈下尤为重要）
--在基础协议层面扩展而非依赖外部方案
--分散MEV（不再由单一提议者或构建者决定交易打包）
实施MCP将直接暴露的问题：
--交易排序（打包与顺序）的竞争激化（可能导致PGA现象涌现？）
--无效交易带来的模拟挑战
--硬件需求提升
--无效交易的数据可用性问题
--需引入最终性工具
让我们逐项分析这些特性，首先从优势开始，再评估潜在问题是否会对技术负担较重的公链构成实施障碍。
1、MCP的优势
（1）增强抗审查性
当前多数采用确定性终局机制的区块链，其共识过程依赖于单一leader决定区块内容（存在细微差异）。区块广播后，多数验证者达成共识并将其纳入规范链。以太坊通过子委员会机制加速出块（但完整验证者集达成共识需要更长时间）。在MCP框架下，多个提议者各自构建本地区块并最终合并，这意味着区块入口从单一主体（提议者/构建者/中继器，理想情况下MCP应摒弃这些角色）转变为多通道模式。这使得审查难度大幅提升。当存在多个打包主体时，系统的抗审查性将显著强化。
当前瓶颈（需注意Flashbots等团队正在改进现状）的核心在于：单一构建者通过拍卖获得单一提议者的区块构建权，而作为拍卖方的（可信）中继器进一步加剧了中心化。虽然以太坊核心协议是去中心化的，但现有交易上链流程并非如此。Solana同样面临Jito中继/构建者的中心化问题，正试图通过再质押方案解决（首个真实收益的再质押"AVS"！）。比特币用户可通过运行全节点自主解决（成本较低），但这以牺牲终局性为代价——比特币采用概率终局性且缺乏MCP实现所需的"最终性工具"，其依赖最长链规则。
（2）在基础协议层面扩展
通常为解决核心协议问题，大量开发被外包给第三方团队来修补L1的固有设计缺陷（不仅限于以太坊）。实施MCP意味着直接处理那些原本由链外方案解决/引发的问题。这会提高硬件要求（同时增强抗审查性），根据协议用户对去中心化的需求，可能是值得的权衡。Solana尤其可能采用此方案来应对Jito的中心化问题。此外，由于区块构建工作被分配给多方，最终将提升整体网络带宽需求。
（3）分散MEV
MCP最独特的效果在于：通过让特定区块的MEV由多个活跃提议者分摊（而非由单一提议者或构建者垄断），改变了原有"MEV彩票"模式。验证者（多数是企业实体）更倾向于获得稳定收益流，这种机制也能有效防止单方通过交易重排榨取MEV（现状）。该特性与抗审查目标具有协同效应。
注：如果你曾读过我们过去的文章，可能会熟悉CAP定理这个术语：这是分布式系统正常运作必须满足的三项基本特性。
C：代表一致性（consistency），即用户体验应在所有用户间保持统一，每次使用系统时都应感觉像是在与单一数据库交互。
A：代表可用性（availability），也就是我们常说的活跃性（liveness），指所有消息都需被系统节点处理并反映在后续区块/查询中，所有指令必须得到执行。
P：代表分区容错性（partition tolerance，或抗审查性），意味着系统即使在遭受攻击或节点网络分裂时，仍需保持一致性与可用性。
MCP是实现CAP定理关键要素（特别是抗审查性）的最佳途径之一——这些要素常被简单归为博弈论问题。请记住：要信任协议本身，而非博弈论。
然而优势必然伴随着代价，CAP定理的运作规律表明：伟大成就总伴随着相应缺陷——几乎不可能完全兼顾所有特性。因此让我们审视实施MCP可能引发的问题。
2、MCP需解决的难题
主要问题在于：MCP在某种程度上会引发区块内的双重竞争阶段。首先是交易打包费，其次是排序费。排序费的处理尤为棘手，因为在第一阶段，本地生产者仅掌握局部区块视图而非全局视图。这意味着要精确计算特定区块位置的最优竞价是项艰巨任务。
这不仅操作困难，更关键的是（在拍卖机制下）这将使我们重回优先Gas拍卖（PGA）时代。虽然抗审查性得到更强保障，但本质上复活了MEV-Boost试图解决的问题——竞争性区块的高位Gas费中位数、打包阶段的排他性定价等现象。
除排序问题外（包括本地与全局视图），还存在其他交易相关挑战。这里特指区块的局部-全局视图传播过程中，无效交易所引发的问题。考虑到在阶段初期（子区块合并为多提议者共建区块前），无法预知状态变更对其他提议者交易的影响，可能出现提议者相互传递无效交易的情况（若这些交易作为数据可用性内容上链，问题会更严重）。也可能出现当前MCP集合中的验证者违反参数限制（如突破最大Gas值）。虽然通过引入仲裁者（或协议内置规则）可在数据可用性披露后，按手续费筛选相同状态变更的低价交易来解决，但这又让我们回到已解决的PGA困境。但若完全不采用拍卖等机制让搜索者/构建者控制区块位置，则会导致垃圾交易泛滥和延迟博弈恶化——这些都将破坏预确认（preconfs）的可能性。以太坊（Pectra升级后）和Solana还需额外考虑：以太坊的7702提案使交易不再因nonce失效，而Solana本就无交易nonce（账户nonce仍存在）。这导致判断交易有效性的难度陡增——本质上需要模拟所有组合才能确定正确排序，可能给网络带来巨大带宽压力。Solana凭借较高的硬件门槛可能更易处理，但以太坊无疑需要硬件升级。不过以太坊的潜在解决方案是：在子区块合并阶段，由执行客户端（而非构建者 中继器）实际计算排序——这再次印证了硬件升级的必要性。
在数据可用性（DA）方面，如前所述，另一个重要问题是这些无效交易可能被泄露到链上（实质上变成免费交易）。这进一步加剧了共识前阶段提到的模拟计算负担——尽管你可以在合并阶段过滤无效交易。FOCIL（发送地址而非完整交易）的一些现有实施方案可能被复用（除非完全依赖模拟验证，但若存在人为干预而非协议规则，可能通过使其他交易失效来干扰模拟过程）。
如前所述，实施MCP很可能需要配备处理同步问题的最终性工具——这也正是前文在共识前排序模拟部分所暗示的。这同时会引发延迟区块提议的时间博弈问题（MEV-Boost拍卖中已可见此类现象），其影响包括：提议者可能先观察其他区块再构建自己的区块，从而故意发送使他人交易失效的交易（对搜索者尤其有利）。若制定过于严格的反时间博弈规则，又会导致性能较差的验证者被淘汰（意味着更多漏块情况）。
应对时间博弈的可能方案可借鉴Monad等链的改进措施，该链采用异步执行（延迟执行）机制。例如可设定规则：单个时段内所有活跃提议者的交易集合完整效果，必须等到全部集合构建完成才能确定。这会显著限制吞吐量，因为多个提议者包含相同交易的概率较高。延迟执行还意味着即使交易被"包含"在子区块中，仍有可能无法进入最终合并区块，导致出现"已包含却回滚"的交易（这与开头提到的双重包含问题相呼应）。需注意这可能需要特定最终性工具来执行此类操作（包括执行、传播和最终确认区块）。
虽然我们主要聚焦以太坊，但值得注意的是Solana正在积极推进MCP。随着Max Resnick加入Anza以及Anatoly公开表态支持实施，这一趋势愈发明显。Anatoly近期发布的文章提及以下关键关注点：
--若来自不同验证者的区块到达时间不同怎么办（这也可能是时间博弈）
--如何合并交易（前文已探讨过）
--如何在验证者间分配区块容量（最大Gas限制）以实现带宽最大化
--资源浪费问题（相同交易被多个子区块包含，前文亦提及此问题）
在Solana上实施MCP的诸多问题通常与以太坊面临的问题相呼应。不过Solana更注重带宽和性能优化，这意味着在确保共识稳健的同时，区块资源管理与区块合并显得更为重要。
我们在文章开头提到的另一个关键点是：MCP不仅能强化协议，还可用于扩展协议。它甚至能通过排序机制将应用专用序列化（ASS）纳入协议层。未来可能会出现这种场景：不再是XYZ交易的提议者，而是由应用自身作为提议者，按照自身需求排序交易集合（这正是Delta项目努力的方向）——或者反过来，应用向提议者提供交易排序规则。值得注意的是，将MEV税赋转移至应用方（交易发起者）与MCP结合的方案也正在探索中（由于不再由单一提议者控制打包，实施会更简单）。
在Max和Anatoly最近的发文中，他们认为MCP能通过应用专用序列化实现更窄的买卖价差（去中心化纳斯达克理念）。当前环境下，如前所述只有单一leader能提议区块。这意味着当价格波动时，订单簿中的报价方会试图撤销某些报价。在Solana的单一提议者模式下，由于提议者垄断权力，只能通过Jito拍卖进行。理想情况（如Hyperliquid所示）应优先处理撤单请求，让做市商维持更窄价差。因此希望通过ASS为应用实现这一目标——单一leader模式下他们垄断了拍卖权，而采用MPC后可以消除这种垄断。不过这种ASS方案很可能仅限于状态隔离场景。该提案本质是让应用开发者能定义特定账户的优先操作（例如撤单），对指定账户优先执行最高优先级交易（不一定是最高小费交易，而是对流动性命脉攸关的撤单操作）。其核心思路是对常规交易设置手续费门槛，同时允许特定优先交易突破限制。
前文讨论过的打包费与排序费问题，Solana似乎已有应对方案。打包费归入交易验证者，排序费则支付给协议（销毁）。当从多个子区块合并时，只需按预设排序费对合并后的交易集合进行排序并执行。
上述机制与Solana的区块传播机制Turbine紧密配合。Leaders（MCP）使用数据分片（shreds），将其发送至Turbine树状结构中的中继节点——这些中继应包含来自所有leader的分片。中继节点向单一共识leader发送分片确认信息，该leader必须收集足够多的消息片段后进行广播并达成共识。
随着Alpenglow的发布，考虑到单层中继节点架构及链上投票机制的取消（现改为完全链上），具体实现可能有所调整。这些改动有望降低验证者运营成本，从而增加验证者数量并吸引技术实力较弱的参与者。这对去中心化固然有益，但可能影响链的性能。值得探讨的是，在Solana实施MCP后，他们将如何应对验证者故障问题。
3、其他生态中的MCP实践
Cosmos生态也在推进MCP实施，知名机构Informal Systems刚发布了BFT共识模型下的多提议者规范。他们采用安全广播协议，通过投票扩展机制要求每个验证者的子区块必须获得其他验证者确认。Tendermint/CometBFT的区块构建模块随后对这些子区块集合达成共识，这意味着特定验证者会产生大量子区块。
Sei正通过Sei Giga项目研发MCP（力争成为首个落地项目），其部分设计灵感来源于Autobahn一文（强烈推荐阅读）。核心思路是将数据可用性与排序解耦，通过多条并行通道加速数据可用性，最后再排序至全局链。这与以太坊的MCP构想略有不同——验证者并非在固定时段同步出块，而是持续生产区块再合并为全局视图。
Commonware的Patrick OGrady也在探索相关方案。
最后，Delta项目设计了一个兼具抗审查公告板功能的底层，同时每个应用运行自己的并发排序器，产生的区块最终结算至全局状态层。
评论(0)