波卡2.0的关键功能之一，弹性扩展（Elastic Scaling）功能即将在第二季度上线。目前还剩下最后一些需要整合的部分：
- 基于Polkadot SDK2412-1的“协会（Fellowship）”运行时正在准备中（详情请参见：
https://github.com/polkadot-fellows/runtimes/pull/606）。一旦实施，我们距离启用RFC103安全特性就只差一次公投了。
- 波卡稳定版2503将于3月底发布。它包含了基于插槽的Collator技术，该技术支持弹性扩展，并且为验证者提供了动态异步备份参数。
弹性扩展是波卡2.0的最后一块拼图，同时它也将改变游戏规则。简而言之，它显著提升了Rollup的垂直可扩展性，增加了吞吐量并降低了延迟。
弹性扩展将带来什么？
它使单个Rollup能够利用波卡的多核架构。Rollup（平行链）可以通过Agile Coretime接口实时调整其使用的核心数量。Layer2网络可以增加其吞吐量并降低延迟，以匹配负载或达到预期的终端用户体验。
下图展示了其工作原理。
只有一条规则：Rollup仍然创建一系列在中继链上并行验证的区块。
Rollup创建这些区块的速度越快，每6秒就可以在中继链上使用的核心就越多。请记住，每个核心有2秒的执行时间和5MB的可用空间（很快将提升至10MB）。
何时需要它？
根据正在构建的项目，可能会更关心以下三个方面的提升：
- 计算能力（CPU权重）
- 带宽（证明大小）
- 延迟（区块时间）
只想要非常低的延迟？
如果你只关心延迟，并且愿意使用一个核心所提供计算能力的25%以下时，那么我们已经为你准备好了。
12个核心
这可以实现非常快速的交易确认，500毫秒的区块时间和高达12MB/s的动态可用性（DA）带宽。很不错吧！
想要高吞吐量（TPS）和较低延迟？
如果你正在构建一个CPU密集型应用，那么你的Rollup需要最大化核心的计算使用率，同时实现较低的延迟。
3个核心
你能在延迟和吞吐量之间取得良好的平衡。这为Rollup提供了长达6秒的执行时间，3MB/s的DA带宽，以及仅2秒的区块时间。
想要不错的吞吐量，但更需要更多带宽？
可能你的应用并不需要太多计算能力，比如说使用一个核心计算能力的50%以下。但与此同时，它对带宽的需求很大。
6个核心
这将为你提供长达6秒的计算时间，6MB/s的DA带宽，并且你还将免费获得1秒的区块时间。
每个证明验证（PoV）包含多个区块
从长远来看，使用12个核心仅仅为了获得500毫秒的区块时间，在资源使用效率方面可能不是最佳选择，但在我们找到更高效的方法之前，它目前运行良好。
更好的方案即将推出，它将允许在一个单独的PoV中包含多达4个平行链区块（如果使250毫秒出块，甚至可以达到8个）。这样将有可能在保持500毫秒延迟的同时，将所需核心数量减少到3个，并最大化核心的计算使用率。对于这一方案，我无法给出具体的时间安排，也不能做出任何承诺，但我知道bkchr（详情请参见：
https://forum.polkadot.network/u/bkchr）正在致力于此。
为了更全面地了解波卡的可扩展性情况，可以阅读这篇博客文章。详情请参见：
https://www.parity.io/blog/polkadot-web3-cloud
权衡取舍
通常情况下，我们需要在计算能力和延迟之间进行权衡。较低的延迟意味着更频繁地出块，这会增加开销，从而减少在6秒内可以执行的计算量。
同时，每个核心可使用的计算量取决于你的Collator之间的网络延迟以及他们的出块速度。更快的Collator使你能够充分利用中继链的计算资源。
在Parity，我们正努力简化和优化区块生成过程，以便让运行参考硬件的Collator能够最大限度地使用核心资源。相关的想法、讨论甚至概念验证（PoC）已经存在。你可以在GitHub上的这个议题中了解更多信息：
Elastic Scaling：简化的区块生产。详情请参见：
https://github.com/paritytech/polkadot-sdk/issues/5190
这一切听起来怎么样？你会使用弹性扩展吗？
我很乐意听取大家的反馈并解答任何疑问。
想参与到本文的讨论，欢迎到这里发表自己的意见：
https://forum.polkadot.network/t/elastic-scaling-wen-500ms-blocks/11971
关于如何参与到论坛的讨论中，请参看我们推出的波卡论坛使用指南：
