# 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](https://github.com/polkadot-evm/frontier) and instead would be based on [pallet-contracts](https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/contracts), [PolkaVM](https://github.com/koute/polkavm) ([\[1\]](https://forum.polkadot.network/t/exploring-alternatives-to-wasm-for-smart-contracts/2434), [\[2\]](https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811)) and an [EVM to PolkaVM recompiler](https://github.com/xermicus/revive) ([\[3\]](https://forum.polkadot.network/t/contracts-update-solidity-on-polkavm/6949)) 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](https://hackmd.io/@XXX9CM1uSSCWVNFRYaSB5g/HJarTUhJA) 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](https://github.com/xermicus/revive) 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](https://github.com/xermicus/revive) 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](https://hardhat.org/), 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.