原文：https://www.parity.io/blog/scalability-tradeoffs-polkadot-web3

作者：Andrei Sandu

编译：OneBlock+

在区块链不断追求更高效率的今天，一个关键问题逐渐显现：扩展性能的同时，是否必须牺牲安全性与系统弹性？

这不仅是技术层面的挑战，更是架构设计的深层抉择。尤其对于 Web3 生态而言，一个更快的系统如果建立在牺牲信任和安全性的基础上，往往难以支撑真正可持续的创新。

作为 Web3 可扩展性的重要推动者，Polkadot 是否也在高吞吐、低延迟的目标下作出了某些牺牲？其 rollup 模型是否在去中心化、安全性或网络互操作性上做出了让步？

本文将围绕这些问题展开，深入剖析 Polkadot 在扩展性设计中的取舍与权衡，并与其他主流公链的解决方案进行对比，探讨它们在性能、安全与去中心化三者之间的不同路径选择。

🧬Polkadot 扩展设计面临的挑战

弹性与去中心化的平衡

Polkadot 的架构依赖于验证者网络以及中心化的中继链（Relay Chain），这是否可能在某些方面引入中心化风险？是否可能形成单点故障或控制，从而影响其去中心化特性？

Rollup 的运行依赖于连接中继链的排序器（sequencer），其通信使用一种称为collator 协议的机制。该协议完全无需许可、无需信任，任何有网络连接的人都可以使用它，连接少量中继链节点，并提交 rollup 的状态转换请求。这些请求会通过中继链的某个 core 验证，只需满足一个前提：必须是有效的状态转换，否则该 rollup 的状态将不会被推进。

垂直扩展的权衡

Rollup 可以通过利用 Polkadot 的多 core 架构来实现垂直扩展。这项新能力由「弹性扩展」（Elastic Scaling）功能引入。在设计过程中我们发现，由于 rollup 区块验证并不固定在某一个 core 上执行，这可能会影响其弹性。

由于向中继链提交区块的协议是无需许可、无需信任的，任何人都可以将区块提交到 rollup 所被分配的任一 core 上进行验证。攻击者可能会利用这一点，将之前已经验证过的合法区块反复提交到不同 core 上，恶意消耗资源，从而降低 rollup 的整体吞吐量和效率。

Polkadot 的目标是在不影响系统关键特性的前提下，维持 rollup 的弹性以及中继链资源的有效利用。

Sequencer 值得信任吗？

一种简单的解决方法是将协议设置为 “有许可的”：例如采用白名单机制，或默认信任排序器不会恶意行为，从而保障 rollup 的活性。

然而，在 Polkadot 的设计理念中，我们不能对 sequencer 做任何信任假设，因为要保持系统的「无需信任」和「无需许可」特性。任何人都应该可以使用 collator 协议提交 rollup 的状态转换请求。

🏄Polkadot: 不妥协的解决方案

Polkadot 最终选择的方案是：将问题完全交由 rollup 的状态转换函数（Runtime）解决。Runtime 是所有共识信息的唯一可信来源，因此必须在输出中明确声明应在哪个 Polkadot core 上执行验证。

这种设计实现了弹性与安全性的双重保障。Polkadot 会在可用性流程中重执行 rollup 的状态转换，并通过 ELVES 加密经济协议确保 core 分配的正确性。

在任何 rollup 区块写入 Polkadot 的数据可用性层（DA）前，由约 5 位验证者组成的小组会先验证其合法性。他们接收排序器提交的候选回执（candidate receipt）和有效性证明（PoV），其中包含 rollup 区块及相应的存储证明。这些信息将交由平行链验证函数处理，由中继链上的验证人重执行。

验证结果中包含一个 core selector，用于指定应在哪个 core 上验证区块。验证人会比对该索引是否与自己负责的 core 一致；若不一致，该区块将被丢弃。

这种机制确保系统始终保持无需信任和无需许可的属性，避免排序器等恶意行为者操控验证位置，确保即使 rollup 使用多个 core 也能保持弹性。

安全性

在追求扩展性的过程中，Polkadot 并未在安全性上妥协。rollup 的安全由中继链保障，只需一个诚实排序器即可维持存活性。

借助 ELVES 协议，Polkadot 将其安全性完整扩展到所有 rollup，验证所有 core 上的计算，无需对使用核心数量做任何限制或假设。

因此，Polkadot 的 rollup 可以在不牺牲安全性的前提下实现真正的扩展。

通用性

弹性扩展不会限制 rollup 的可编程性。Polkadot 的 rollup 模型支持在 WebAssembly 环境中执行图灵完备的计算，只要单次执行在 2 秒内完成。借助弹性扩展，每 6 秒周期内可执行的总计算量得以提升，但计算类型不受影响。

复杂性

更高的吞吐量和更低的延迟不可避免地引入复杂性，这是系统设计中唯一可接受的权衡方式。

Rollup 可通过 Agile Coretime 接口动态调整资源，以维持一致的安全水平。它们还需实现部分 RFC103 要求，以适应不同使用场景。

具体的复杂性取决于 rollup 的资源管理策略，这些策略可能依赖链上或链下变量。例如：

  • 简单策略：始终使用固定数量的 core，或通过链下手动调整；

  • 轻量策略：在节点 mempool 中监控特定交易负载；

  • 自动化策略：通过历史数据和 XCM 接口提前调用 coretime 服务配置资源。

自动化方式虽然更高效，但实现与测试成本也显著上升。

互操作性

Polkadot 支持不同 rollup 间的互操作性，而弹性扩展并不会影响消息传递的吞吐量。

跨 rollup 的消息通信由底层传输层实现，每个 rollup 的通信区块空间是固定的，与其分配的核心数量无关。

未来，Polkadot 还将支持链下消息传递（off-chain messaging），由中继链作为控制面，而非数据面。该升级将使 rollup 间通信能力随弹性扩展一同提升，进一步增强系统的纵向扩展能力。

🧩其他协议做出了哪些权衡？

众所周知，性能提升往往以牺牲去中心化与安全性为代价。但从 Nakamoto 系数来看，即便一些 Polkadot 竞争对手的去中心化程度较低，其性能表现也并不如人意。

Solana

Solana 不采用 Polkadot 或以太坊的分片架构，而是以单层高吞吐架构实现扩展性，依赖历史证明（PoH）、CPU 并行处理和基于领导者的共识机制，理论 TPS 可达 65,000。

一个关键设计是其预先公开且可验证的领导者调度机制：

  • 每个 epoch（约两天或 432,000 个 slot）开始时，按质押量分配 slot；

  • 质押越多，分配越多。例如质押 1% 的验证人将获得约 1% 的出块机会；

  • 所有出块者提前公布，增加了网络遭受定向 DDoS 攻击、频繁宕机的风险。

PoH 与并行处理对硬件要求极高，导致验证节点集中化。质押越多的节点出块机会越大，小节点几乎无 slot，进一步加剧中心化，也增加了被攻击后系统瘫痪的风险。

Solana 为追求 TPS，牺牲了去中心化和抗攻击能力，其 Nakamoto 系数仅为20，远低于 Polkadot 的172。

TON

TON 宣称 TPS 可达 104,715，但这一数字是在私有测试网、256 个节点、理想网络与硬件条件下实现的。而 Polkadot 在去中心化公网上已达128K TPS。

TON 的共识机制存在安全隐患：分片验证节点的身份会提前暴露。TON 白皮书也明确指出，这虽能优化带宽，但也可能被恶意利用。由于缺乏 “赌徒破产” 机制，攻击者可等待某个分片被其完全控制，或通过 DDoS 攻击阻断诚实验证者，从而篡改状态。

相比之下，Polkadot 的验证人是随机分配、延迟揭示的，攻击者无法提前得知验证人身份，攻击需赌全部控制成功，只要有一个诚实验证者发起争议，攻击就会失败并导致攻击者损失质押。

Avalanche

Avalanche 采用主网 + 子网架构进行扩展，主网由 X-Chain（转账，~4,500 TPS）、C-Chain（智能合约，~100–200 TPS）、P-Chain（管理验证者与子网）组成。

每个子网理论 TPS 可达 ~5,000，类似 Polkadot 的思路：减少单个 shard 的负载以实现扩展。但 Avalanche允许验证者自由选择参与子网，且子网可设置地理、KYC 等额外要求，牺牲了去中心化与安全性。

在 Polkadot，所有 rollup 共享统一安全保障；而 Avalanche 的子网没有默认的安全保证，部分甚至可完全中心化。若想提高安全性，仍需在性能上妥协，且难以提供确定性的安全承诺。

Ethereum

以太坊的扩展策略是押注于 rollup 层的可扩展性，而不是在基础层直接解决问题。这种方式本质上并没有解决问题，而是将问题传递到了堆栈的上一层。

Optimistic Rollup

目前大多数 Optimistic rollup 都是中心化的（有些甚至只有一个 sequencer），存在安全性不足、彼此孤立、延迟高（需等待欺诈证明期，通常几天）等问题。

ZK Rollup

ZK rollup 的实现受到单笔交易可处理数据量的限制。生成零知识证明的计算需求极高，且 “赢者通吃” 机制易导致系统中心化。为保证 TPS，ZK rollup 往往限制每批次交易量，在高需求时会引发网络拥堵、gas 上涨，影响用户体验。

相比之下，图灵完备 ZK rollup 的成本大约是 Polkadot 核心加密经济安全协议的 2x10^6 倍。

此外，ZK rollup 的数据可用性问题也会加剧其劣势。为了确保任何人都能验证交易，仍需提供完整交易数据。这通常依赖额外的数据可用性解决方案，进一步推高成本和用户费用。

🎈结语

可扩展性的尽头，不应该是妥协。

与其他公链相比，Polkadot 并未走上以中心化换性能、以预设信任换效率的道路，而是通过弹性扩展、无需许可的协议设计、统一的安全层和灵活的资源管理机制，实现了安全性、去中心化与高性能的多维度平衡。

在追求更大规模应用落地的今天，Polkadot 所坚持的“零信任扩展性”，或许才是真正能支撑 Web3 长远发展的解决方案。