摘要

我们发现，将基于Solidity构建的高价值应用迁移至PolkaVM面临一些挑战。因此，我们考虑在Hub上推出以太坊兼容的PolkaVM堆栈预览版后，尽快在Polkadot Hub上部署EVM堆栈，以便Parity、Web3基金会和业务发展（BD）合作伙伴能够尽快提升吸引力（即流动性、用户和开发者数量）。之后，Parity将重新聚焦于开发功能完备、高性能的PolkaVM技术栈，并借助届时已形成的生态吸引力，推动仅能在波卡实现的创新。

背景

随着以太坊兼容PolkaVM第一阶段版本已开放测试并收到初步反馈，我们在路线图上迎来了决策节点。目前，Parity和Web3基金会正在讨论如何最好地平衡以下两个方面：

创新层面：利用PolkaVM为Solidity智能合约提供更强算力支持；
生态吸引力提升层面（如总锁仓量TVL等）：轻松迁移高价值的以太坊dApps，尤其是在DeFi市场领域。

面临的问题

在PolkaVM上构建以太坊兼容层（上周在Kusama上发布了预览版的第一部分）的过程中，借助波卡BD生态的反馈，我们发现了一些阻碍以太坊dApp移植的问题：

1.EVM与PolkaVM之间的不兼容性（详情请参见：

https://docs.polkadot.com/polkadot-protocol/smart-contract-basics/evm-vs-polkavm/#solidity-and-yul-ir-translation-incompatibilities）；

2.DOT与ETH在Gas估算和小数位数方面的差异；

3.字节码大小的差异。

对于第一个问题，特别是Solidity和YUL的翻译兼容性问题（详情请参见：

https://docs.polkadot.com/polkadot-protocol/smart-contract-basics/evm-vs-polkavm/#solidity-and-yul-ir-translation-incompatibilities），我们认为可以通过逐步简化应用迁移流程来解决，包括使用Hardhat和Foundry等工具。针对第二个问题，我们已有设计方案。

然而，第三个问题需要更多考量。虽然我们已在推进缓解措施（如新型内存分配器和其他易于实现的优化方案）以支持更大字节码合约的执行，但我们认为，要显著减小最终生成的字节码大小，需长期投入优化编译器。

这意味着，智能合约字节码大小的增大（平均达8至10倍）在中短期内对以太坊dApp移植构成风险，因为部分合约可能因过大而无法部署。也就是说，我们目前的方法在迁移以太坊dApps方面存在上市时间风险。

如开篇所述，我们正努力在创新（开发新技术）和提升吸引力之间寻求平衡。而且，如果你在推动创新，就像我们在PolkaVM上所做的，推动创新过程中总会有新的认知，基于这些认知，我们认为有必要调整计划。

拟议方案

我们正研讨如何缩短轻松迁移以太坊dApps的上市时间。当前思路如下：

1.完成PolkaVM预览版的开发（包括ERC20、基本的跨共识消息（XCM）预编译、燃气映射、DOT与ETH之间小数位数差异的修正、内存分配器及其他支持更大合约的优化）

a. 至少在Kusama Hub上完成，

b. 在Polkadot Hub上完成，但前提是我们能找到有价值的用例。

2.将重点转向尽快为Polkadot Hub推出100% EVM兼容的解决方案（以消除轻松迁移以太坊dApps的障碍）

3.然后重新聚焦于PolkaVM堆栈的开发，重点包括：

a. 实现即时编译（JIT），这将解锁超越EVM的更强算力

b. 改进Solidity编译器，以减小生成的字节码大小。

对于第1点，我们仍可以在9月下旬推出ERC20和基本的XCM预编译，并预计在10月底或11月初推出其余部分（新的内存分配器和其他优化）。

第1点b中提到的高价值应用场景例如：让平行链能够更广泛地交易其代币。易其代币。但这一价值的实现依赖于快速落地，否则，聚焦第二点比推进第一点b更有价值。我们正在谨慎考虑这种方法，因为虽然Kusama更具 “期待混乱”，但在波卡上我们只部署足够可靠、稳定的功能。

对于第1点和第2点，我们均需解决至少两个问题：（a）Gas估算；（b）DOT与ETH之间小数位数差异的修正问题（设计方案已接近完成）。此外，我们正在积极探索如何尽快在Polkadot Hub上部署100% EVM兼容的解决方案，具体时间线确定后将另行公布。

开发者可在EVM和PolkaVM之间选择

基于上述方案，去中心化应用开发者将可选择其Polkadot Hub上的Solidity合约运行在EVM还是PolkaVM上。因此，现有以太坊dApp的开发者最初可以选择EVM，实现零门槛移植；而随着我们通过工具逐步消除兼容性问题，并通过波卡解锁更强算力，这些开发者可选择转向PolkaVM，为用户降低成本并节省基础设施投入（例如将零知识证明等算力密集型任务从链下迁移至链上执行）