官方论坛精选丨在PolkaVM上的Solidity

正如之前在论坛上讨论的，我们团队目前正在探索一种基于PolkaVM的替代合约运行时（runtime）。由于我们希望新的运行时与Solidity高度兼容，因此已经开始着手开发新的Solidity编译器。此前，我主要致力于Hyperledger Solang3的工作，并且实现了一个针对PolkaVM的实验性目标。

什么Solang？

你现在可能会问，为什么要启动这个新项目呢？原因主要有以下几点：

Solidity是一个持续发展的目标； 开发一个与以太坊Solidity完全兼容的编译器是一项庞大的任务； Solidity本身也存在一些不足（下面会详细解释）。

与最初开发Solang时相比，我们现在可以利用YUL，这是solc使用的中间表示(IR)。我们不是直接将Solidity编译为LLVM IR，而是让solc生成YUL IR，然后再将其编译为LLVM IR。作为IR，YUL比Solidity简单得多，也不像Solidity那样频繁变动；构建一个将YUL IR转换为LLVM IR的编译器所需的工作要少得多。ZKSync在他们的zksolc1Solidity编译器中采用的相同方法。通过重用他们代码库的一些部分，我们能够迅速地将一个重新编译的flipper合约作为pallet合约运行的原型证明(PoC)拼凑起来。简而言之：

使用solc处理Solidity源代码为我们节省了很多工作。 重新编译YUL（如果需要的话，还可以回退到EVM字节码）显著提高了PolkaVM上的Solidity兼容性。 使我们的运行时得到工具和钱包的支持变得更加简单。

新的RIS-V合约运行时：全面的基准测试

理想情况下，我们的RISC-V运行时在执行性能上要比Wasm和EVM运行时好得多，同时还能保持非常有竞争力的启动和编译时间。初步基准测试显示，对于计算密集型代码，RISC-V可能比Wasm合约快一个数量级以上——无论如何，EVM在这方面的表现更差。这使得一些迄今为止无法直接在智能合约中实现的令人兴奋的新应用成为可能（例如，验证STARK证明而不依赖于任何特定的宿主函数（host functions）——是的，这仍然会比使用宿主函数慢，但我们获得了更多的灵活性）。然而，传统的合约工作负载并不计算密集；它们每笔交易执行的代码很少。在这里，快速的启动和编译时间是关键：即使一个合约运行时在编译合约代码方面做了大量优化，但如果其执行性能接近原生代码，那么在平均情况下，它仍然可能输给就地解释器（in-place interpreters）。我们期望我们的合约运行时在这两个维度上都表现出色！为了实现这一目标，我们正在建立一个全面的基准测试套件，用以比较不同的Solidity兼容合约平台，如pallet-contracts和pallet-evm。我们将测量运行时和设置部分所消耗的实际时间（wall clock times）。我们计划使用多样化的合约集合进行测量：

合成的（例如，执行计算密集型工作的小型代码，执行非常少计算工作的大量代码等）； 经典的合约用例，如ERC20通证的转移或ERC721NFT铸造； ETH主网上最受欢迎的合约； RISC-V的新用例（例如，目前在EVM甚至Wasm上不可行的密码学计算）。

基于Wasm的运行时将能够运行ink!以及Solidity案例；与其他Wasm和EVM解释器甚至eBPF的交叉验证也是可能的。如果您认为有任何特定的合约或算法应该包含在这个基准测试套件中，请在这里告诉我们！

总结

这篇文章涵盖了我在Parity的衍生合约团队积极工作的新技术进展。我们希望在今年晚些时候交付第一个工作版本的编译器以及一个确定性的智能合约基准报告。请继续关注未来的更新！

想参与到本文的讨论，欢迎到论坛中发表自己的意见：https://forum.polkadot.network/t/contracts-update-solidity-on-polkavm/6949关于如何参与到论坛的讨论中，请参看我们推出的波卡论坛使用指南：《如何参与波卡的讨论：波卡官方论坛使用指南》