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.
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.
In both cases:
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 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.
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.
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.
Adding a major piece of software to any system chain will increase its complexity and maintenance burden.
Developing this solution will naturally bind development resources that can’t be used to develop other things.
Parachains already offering a full fledged smart contract execution environment may experience competitive pressure due to Asset Hub’s ability to host smart contracts.
Parity will only provide the core technology:
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:
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.
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.
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.
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.
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.
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.
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.
Threshold
Why is contracts on system chains a problem then?
In general seeing contracts as second class citizens, which may exist on some "private" chain or not has proven to be detrimental to Polkadot's success. The easiest way to get started, is contracts! We need to provide this entry point as ubiquitous as possible, on any parachain, system or not.
Polkadot provides the means to go above contracts, but we fail to attract the large pool of projects, for which contracts suffice. They all go elsewhere.
Why would they? Attracting more users and developers to Polkadot will be beneficial to them as well. If they offer things asset hub does not provide, their service is only an XCM away. The reason why teams move elsewhere is precisely because we fall short in attracting users/developers and capital. This initiative is meant to help fixing this.
Moving elsewhere, likely means becoming a contract somewhere else, but if your parachain can be written as a contract, then in fact you are also benefiting from contracts on asset hub - you can launch your application there at lower cost, but have the ability to become a parachain again if adoption goes through the roof. If you go elsewhere, you are stuck being a contract forever.