Should we allow EVM compatible contracts on Asset Hub?

Summary

This proposal aims to find out if there is token holder support for adding a smart contract execution environment to Polkadot’s Asset Hub system parachain.

If approved, we are targeting a deployment by the end of 2024: the proposed solution currently in development at Parity would not use the existing Frontier technology and instead would be based on pallet-contracts, PolkaVM ([1], [2]) and an EVM to PolkaVM recompiler ([3]) for Solidity/EVM compatibility. See below to understand why it matters.

Motivation

Allow for synchronous and permissionless interactions with assets

The Asset Hub parachain is the designated place to hold assets within the Polkadot ecosystem. Many blockchain applications rely on having ergonomic and secure access to those assets.

Today, there are two permissionless ways in which on-chain logic can be developed and deployed on Polkadot to engage with Asset Hub assets.

1. Develop functionality with Polkadot SDK and deploy as a parachain that transacts with Asset Hub via XCM in an asynchronous fashion.
2. Develop functionality with Solidity or ink! and deploy on a parachain with Frontier or pallet-contracts smart contract execution environment (e.g. Moonbeam, Astar, etc.) that transacts with Asset Hub via XCM in an asynchronous fashion.

In both cases:

• The communication and complexity overhead of dealing with assets on another chain has to be paid.
• Another token, governance system or at least brand is involved when developing an application.

Hence we suggest allowing deployment of contracts directly to Asset Hub. By allowing all assets in pallet_asset available to contracts, contracts then won’t have to deal with asynchronous operations. We will emulate one ERC20 contract for each asset within pallet_assets to make this operation ergonomic for Solidity developers.

Refer to the following table to compare the different ways of deploying to Polkadot:

	Composability w/ assets on AH	Permissionless deployment?	Ease of development	Subject to Governance system & brand	DOT as fee-paying asset
Adding a pallet to AH	Synchronous	No, requires approval of Polkadot governance	Hard	Only Polkadot governance & brand	Yes
Smart Contracts on non-system (“3rd party”) parachain (i.e. Moonbeam)	Asynchronous via XCM	Yes (generally)	Easy	Parachain governance & brand	Currently no
New non-system (“3rd party”) parachain	Asynchronous via XCM	Yes	Hard	Parachain governance & brand	Possible
Smart Contracts on dedicated Smart Contracts system parachain	Asynchronous via XCM	Yes	Easy	Only Polkadot governance & brand	Yes
Smart Contracts on AH	Synchronous	Yes	Easy	Only Polkadot governance & brand	Yes

Smart contracts are easier/cheaper to build & deploy than a parachain. Requiring businesses to learn a new technology (Rust + PolkadotSDK) is a significant hurdle, whereas

Solidity is the most widely adopted and supported smart contract language.

Solidity is the industry standard. Requiring businesses to learn a new technology (Rust + PolkadotSDK) is a big ask. If it doesn’t work out the investment is lost. By supporting Solidity we make sure that deploying to Polkadot is a low risk endeavor.

Frontier vs. PolkaVM

Frontier will never reach the near native execution speeds that we aim for. Early benchmarks show that the solution in development is capable of reaching those speeds. Additionally, by using PolkaVM, additional languages (like C or Rust) can be used to unlock even more performance when needed. For example, highly optimized cryptography written in C can be integrated into a Solidity contract.

PolkaVM & EVM to PolkaVM recompiler can provide significant performance improvements over existing Polkadot smart contract execution environments (Frontier and pallet-contracts)

Note that we can’t just deploy Frontier now and move to the new technology later. Minor differences prevent an automatic migration. This means we would need to support Frontier forever, which we would like to avoid.

The EVM to PolkaVM recompiler can be reused for JAM

We believe that we probably also want to run Solidity contracts directly on top of JAM. The technology developed as part of this effort can be re-used to accomplish this.

We can create a dedicated system chain later if required

Should availability of blockspace on Asset Hub become a bottleneck (good problem to have) Polkadot could decide to spawn a dedicated contracts system chain. In which case projects that have already deployed their smart contracts on Asset Hub would be incentivized to migrate their Dapp in order to save on transaction costs. Starting with a dedicated chain will just be an Asset Hub with contracts and hence driving fragmentation without providing value as we have enough block space right now.

Reasons not to

Increases the complexity of Asset Hub

Adding a major piece of software to any system chain will increase its complexity and maintenance burden.

Binds some of Parity’s development resources

Developing this solution will naturally bind development resources that can’t be used to develop other things.

Could lead to competition for existing smart contract parachains

Parachains already offering a full fledged smart contract execution environment may experience competitive pressure due to Asset Hub’s ability to host smart contracts.

We need the community as Partners

Parity will only provide the core technology:

1. A YUL to PolkaVM recompiler
2. An execution environment (a pallet + required host functions) targeted by said recompiler
3. A compatibility layer that translates Ethereum RPCs to Polkadot RPCs (similar to Frontier)
4. Integration of above into the Asset Hub runtime

This is why we need a community to provide all the rest that is needed for success. If an EVM instance is accepted into the Polkadot protocol via Asset Hub and/or another system chain, one would expect the Treasury or Fellowship to fund projects that contribute to its success. This is a non exhaustive things that we think we need:

Tooling and Integration

The Ethereum RPC compatibility layer will bring us 95% of the way of supporting existing EVM tooling and integrations. But making sure that things actually work with a good developer experience is another story. Somebody needs to make sure Polkadot pops up in Hardhat, make sure that block explorers work, and find out where we lack compatibility.

Marketing

We need people to spread the word and bring new users in. Being Ethereum but with fast code execution makes it a much simpler sales pitch.

Communication

We need people that handle the communication between core developers and builders, who find out which pieces are missing and where we need to improve.

Education

While the system will work mostly like Ethereum there will be minor differences in functionality and major differences in performance characteristics. We need people writing tutorials, doing bootcamps, and answering questions.

Liquidity from Ethereum

This system will only be useful for most people if there is enough liquidity available. We will make sure that existing liquidity on Asset Hub is available to contracts. However, we need people to come up with smart ways to bring in more.

FAQ

In which milestones will this be rolled out?

In two milestones: The first milestone is planned to be rolled out at the end of this year. This will include the fully functional products mentioned above but in an unoptimized form. This means that we will be executing contracts with an in-runtime PolkaVM interpreter. This is a huge simplification since it does not require any changes to the node.

As a second milestone we will allow contracts to be just in time compiled, unlocking all the performance benefits without any changes to already deployed contracts.

Can we deploy something quickly earlier (1-3 months) and then iterate?

The only Ethereum compatible software we have right now is pallet_evm and Acala’s EVM+. However, deploying them now means that we need to support both solutions forever since there is no automatic migration path. Contracts are immutable code, which means the execution environment needs to be backwards compatible forever. This means that the MVP needs to get all the fundamentals right which will take time.