-
Notifications
You must be signed in to change notification settings - Fork 55
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add EVM+ink! Contracts Pallets to Asset Hub for Polkadot
This RFC proposes to add the two dominant smart contract programming languages in the Polkadot ecosystem to AssetHub: EVM + ink!/Coreplay. The objective is to increase DOT Revenue by making AssetHub accessible to (1) Polkadot Rollups; (2) EVM smart contract programmers; (3) Coreplay programmers who wil; benefit from easier-to-use smart contract environments. These changes in AssetHub are enabled by key Polkadot 2.0 technologies: PolkaVM supporting Coreplay, hyper data availability in Blobs Chain.
- Loading branch information
1 parent
ade390b
commit b77c11b
Showing
1 changed file
with
191 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,191 @@ | ||
| # RFC-0066: Add EVM+ink! Contracts Pallets to Asset Hub for Polkadot | ||
|
|
||
| | | | | ||
| | --------------- | -------------------------------------------------------------------------------------------------- | | ||
| | **Start Date** | 14 January 2024 | | ||
| | **Description** | A proposal to add _EVM_+_ink!_ Contracts to Asset Hub for Polkadot to support **Polkadot Rollups** and larger numbers of _EVM/Coreplay_ smart contract developers and their users on **Polkadot Rollups** _and_ **AssetHub for Polkadot**. | | ||
| | **Authors** | [Sourabh Niyogi](https:/sourabhniyogi) | | ||
|
|
||
| ## Summary | ||
|
|
||
| This RFC proposes to add the two dominant smart contract programming languages in the Polkadot ecosystem to AssetHub: | ||
| EVM + ink!/Coreplay. The objective is to increase DOT Revenue by making AssetHub accessible to | ||
| (1) Polkadot Rollups; | ||
| (2) EVM smart contract programmers; | ||
| (3) Coreplay programmers who wil; benefit from easier-to-use smart contract environments. | ||
| These changes in AssetHub are enabled by key Polkadot 2.0 technologies: | ||
| PolkaVM supporting Coreplay, | ||
| hyper data availability in Blobs Chain. | ||
|
|
||
| ## Motivation | ||
|
|
||
| EVM Contracts are pervasive in the Web3 blockchain ecosystem, | ||
| while Polkadot 2.0's Coreplay aims to surpass EVM Contracts in ease-of-use using PolkaVM's RISC architecture. | ||
|
|
||
| Asset Hub for Polkadot does _not_ have smart contract capabilities, | ||
| even though dominant stablecoin assets such as USDC and USDT are originated there. | ||
| In addition, in the [Minimal Relay Chain architecture #32](https:/polkadot-fellows/RFCs/blob/main/text/0032-minimal-relay.md), | ||
| DOT balances are planned to be shifted to Asset Hub, to support Polkadot 2.0's | ||
| [CoreJam map-reduce architecture](https:/polkadot-fellows/RFCs/blob/gav-coreplay/text/coreplay.md). | ||
| In this 2.0 architecture, there is no room for synchronous contracts on the Polkadot relay chain -- | ||
| doing so would waste precious resources of sync+async composability. | ||
| However, While Polkadot fellows have concluded the Polkadot relay chain should _not_ support | ||
| synchronous smart contracts, this is not applicable to AssetHub for Polkadot. | ||
|
|
||
| The following sections argue for the need for Smart Contracts on AssetHub. | ||
|
|
||
| ### Defi Applications need Smart Contracts on AssetHub | ||
|
|
||
| While the assetConversion pallet (implementing Uniswap v1) is a _start_ to having some basic defi on AssetHub, | ||
| many programmers are surprised to find that synchronous smart contract capabilities (e.g. uniswap v2+v3) on other chains | ||
| are not possible on AssetHub. | ||
|
|
||
| Indeed, this is true for many Polkadot parachains with the exception of the top 2 Polkadot parachains (Moonbeam + Astar) | ||
| who do include the EVM pallets. This leads to a cumbersome Polkadot smart contract programming experience between AssetHub | ||
| and these 2 Polkadot parachains, making the Polkadot ecosystem hard to work with for asset-related applications from defi to NFTs. | ||
|
|
||
| ### Rollups need Smart Contracts on AssetHub | ||
|
|
||
| Polkadot Data Availability is an extremely promising but underutilized technology that could be used by "Rollups". | ||
| Unlike Ethereum's DA which is capped at a fixed throughput, Polkadot data availability is [linear in the number of cores](https://forum.polkadot.network/t/polkadot-da-vs-competition/3403). | ||
| This means Polkadot can support a much larger number of rollups than Ethereum _now_, and even more as the number of cores grows. | ||
| This performance difference has not been widely appreciated in the blockchain community. | ||
|
|
||
| Recently, a "Blobs" chain has been developed to fill this gap by senior Polkadot Fellows: | ||
| * [ThrumDev](https:/thrumdev/blobs) | ||
| * [Blobs on Kusama - ParaID 3338](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fblobs.colorfulnotion.com#/chainstate) ) | ||
| * [Rollkit](https:/thrumdev/blobs/blob/e4c88182442c33f5d81dcfc9cc460dd81eab34a2/docs-site/docs/intro.md#integrations) | ||
|
|
||
| A rollup kit is mappable to widely used rollups, such as OP Stack, Arbitrum Orbit or StarkNet Madara. | ||
| This Blobs chain, currently on Kusama (paraID 3338), enables rollups to utilize functionality _outside_ the Polkadot 1.0 | ||
| parachain architecture by having rollups submit transactions. The Blobs chain write interface is simple | ||
| `blobs.submitBlob(namespaceId, blob)` with a read interface. However, simply sending blobs is not enough. | ||
|
|
||
| Key functionality for optimistic rollups (e.g. OP Stack, Arbitrum Orbit) are: | ||
| * enabling the users of the rollup to _deposit_ and _withdraw_ the native token into the rollup and from the rollup. | ||
| - Deposits: send DOT to the rollup from AssetHub by calling an EVM Contract function on AssetHub | ||
| - Withdrawal: withdraw DOT from the rollup by submitting a transaction on the rollup. After some of days (e.g. 7 day), the user submits a transaction on AssetHub to claim their DOT, using a Merkle proof. | ||
| * enabling interactive fraud proofs. Anyone monitoring a rollup, using the Blobs chain can access the recent history of any rollup chain, potentially detect invalid state transitions, and interact with rollup. | ||
|
|
||
| Analogous operations exist for ZK-rollups. | ||
|
|
||
| While it is possible to have the operations in EVM Contracts translated in FRAME pallets (e.g. an "opstack" pallet), | ||
| we do not believe the translation confers significant benefit. Instead, we believe the translation would require | ||
| regular updates, which have proven difficult to implement in practice. | ||
|
|
||
| ### ink! on AssetHub will lead to CorePlay Developers on AssetHub | ||
|
|
||
| While ink! WASM Smart Contracts have been promising technology, the adoption of ink! WASM Contracts amongst Polkadot parachains | ||
| has been low, in practice just Astar to date, with not many developers. This may due to missing tooling, slow compile times, | ||
| and/or simply because ink!/Rust is just harder to program than Solidity, the dominant programming language of EVM Chains. | ||
|
|
||
| Fortunately, ink! can compile to | ||
| [PolkaVM](https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811), | ||
| a new RISC based VM that has the special capability of suspending and resuming the registers in a VM. | ||
| This has the key new promise of making smart contract languages easier to user -- instead of smart contract developer worrying about | ||
| what can be done with the gas limits of a specific block or a specific transaction, Coreplay smart contracts can be much easier to | ||
| program on (see [here](https:/bkchr/coreplay-poc)). | ||
|
|
||
| We believe AssetHub should support ink! as a precursor to support CorePlay's capabilities as soon as practicable. | ||
| To the best of our knowledge, release times of this are [unknown](https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811/68). | ||
|
|
||
| ## Stakeholders | ||
|
|
||
| - **Asset Hub Users**: Those who call any extrinsic on Asset Hub | ||
| - **DOT Token Holders**: Those who hold DOT on any chain in the Polkadot ecosystem. | ||
| - **AssetHub Smart Contract Developers**: Those who utilize EVM Smart Contracts, ink! Contracts or Coreplay Contracts on AssetHub | ||
| - **Ethereum Rollups**: Rollups who utilize Ethereum as a settlement layer and interactive fraud proofs to secure their rollup and utilize Ethereum DA to record transactions. | ||
| - **Polkadot Rollups**: Rollups who utilize AssetHub as a settlement layer and interactive fraud proofs on Assethub and and Blobs/Sugondat DA to record rollup transactions. | ||
|
|
||
| ## Explanation | ||
|
|
||
| ### Limit Smart Contract Weight allocation | ||
|
|
||
| AssetHub is as present an relatively unused chain, but promises to be a major portion of the Polkadot 2.0 Minimal Relay Chain architecture. As such, it is proposed that _at most_ 50% of the available weight be allocated to smart contracts pallets (EVM, ink! and/or Coreplay). While to date AssetHub has limited usage, it is believed (see [here](https://forum.polkadot.network/t/permissioned-pallet-contracts-deployment-to-asset-hub-for-defi-primitives/3908/3)) that imposing this limit on smart contracts pallet would limit the effect on non-smart contract usage. Having a excessively small weight limit like 10% or 20% may limit the attractiveness of Polkadot as a platform for Polkadot rollups and EVM Contract. Having a excessively large weight like 90% or 100% may threaten AssetHub usage. | ||
|
|
||
| In practice, this 50% weight limit would be used for: | ||
| * Defi/NFT applications: modern defi EVM Contracts would be expected to go beyond the capabilities of `assetConversion` pallet to support many common ERC20/ERC721/ERC1155. | ||
| * Polkadot Rollups users, for deposit and withdrawal operations. Note the operations of recording blocks would be done on the Blobs Chains. Interactive fraud proofs would be extremely rare by comparison and can sabe | ||
| * Coreplay smart contract usage | ||
|
|
||
| We expect the first category to dominate. If AssetHub smart contract usage increases so as to approach this 50% limit, the gas price will increase a lot, motivating EVM contract developers to migrate to a EVM contract chain or rethink their application architecture to work asynchronously within Corejam. | ||
|
|
||
| ### Model AssetHub Assets inside EVM Smart Contracts based on Astar | ||
|
|
||
| Polkadot parachains Astar and Moonbeam have a mapping between assetIDs and "virtual" EVM Contracts. | ||
|
|
||
| * [Astar XCM Asset List](https://docs.astar.network/docs/learn/interoperability/asset-list) | ||
| * [Moonbeam XC-20](https://docs.moonbeam.network/builders/interoperability/xcm/xc20/overview/) | ||
|
|
||
| We propose that the AssetHub support a systemic mapping following Astar: | ||
| (a) Native Relay DOT + KSM - should be mapped to `0xFFfFfFffFFfffFFfFFfFFFFFffFFFffffFfFFFfF` on AssetHub for Polkadot and AssetHub for Kusama respectively | ||
| (b) All Assethubs assets map into an EVM address using a `0xffffffff` prefix | ||
| https://docs.astar.network/docs/learn/interoperability/xcm/integration/tools#xc20-address | ||
|
|
||
| The usage of the above has been made code-complete by Astar: | ||
| * [xc-asset-config](https:/AstarNetwork/Astar/tree/master/pallets/xc-asset-config) | ||
| * [assets-erc20](https:/AstarNetwork/Astar/tree/master/precompiles/assets-erc20) | ||
| * [pallet-assets extensions](https:/AstarNetwork/Astar/tree/master/chain-extensions/pallet-assets) | ||
|
|
||
| ## New DOT Revenue Sources | ||
|
|
||
| A substantial motivation in this proposal is to increase demand for DOT via two key chains: | ||
| * AssetHub - from defi/NFT users, Polkadot Rollup users and AssetHub Smart Contract Developers | ||
| * Blobs - supporting Polkadot Rollups | ||
|
|
||
| ### New Revenue from AssetHub EVM Contracts | ||
|
|
||
| Enabling EVM Contracts on AssetHub will support DOT revenue from: | ||
| * defi/NFT users who use AssetHub directly | ||
| * rollup operators who utilize Blobs chain | ||
| * rollup users who buy DOT to utilize Polkadot Rollups | ||
|
|
||
| ### New Revenue: ink!/Coreplay Contracts | ||
|
|
||
| Enabling ink! contracts will pave the way to a new class of AssetHub Smart Contract Developers. Given PolkaVM's proven reduced compile time and RISC architecture enabling register snapshots, it is natural to utilize this new technical on a flagship chain. | ||
|
|
||
| ## Drawbacks and Tradeoffs | ||
|
|
||
| Supporting EVM Contracts in AssetHub is seen by some as undercutting Polkadot's 1.0 parachain architecture, both special purpose appchains and smart contract developer platforms. However, we believe the lack of growth of leading parachains in the last 12-18 months, and the high potential of CorePlay requires a change in approach. | ||
|
|
||
| Maintaining EVM Contracts on AssetHub may be seen as difficult and may require Substrate engineers to maintain EVM Pallets and manage the xcContracts. We believe this cost will be relatively based on the proven deployment of Astar and Moonbeam compared to the potential upside of new DOT revenue from defi/NFT applications on AssetHub and the potential for utilizing Polkadot DA. | ||
|
|
||
| ## Testing, Security, and Privacy | ||
|
|
||
| Testing the xcAssets throughly will be critical. | ||
|
|
||
| ## Performance, Ergonomics, and Compatibility | ||
|
|
||
| ### Performance | ||
|
|
||
| The weight limit of 50% is expected to be adequate to limit excess smart contract usage at this time. | ||
|
|
||
| Storage bloat is expected to kept to a minimum with the nominal 0.01 Existential Deposit. | ||
|
|
||
| ### Ergonomics | ||
|
|
||
| Note that the existential deposit is not 0 DOT but being lowered from 0.1 DOT to 0.01 DOT, which may pose problems for some developers. Many developers routinely deploy their EVM contracts on many different EVM Chains in parallel. This non-zero ED may pose problems for some developers | ||
|
|
||
| The 0.01 DOT (worth $0.075 USD) is unlikely to pose significant issue. | ||
|
|
||
|
|
||
| ### Compatibility | ||
|
|
||
| It is believed that EVM pallet (as deployed on Moonbeam + Astar) is | ||
| sufficiently compatible with Ethereum. | ||
|
|
||
| The messaging architecture for rollups are not compatible with Polkadot XCM. | ||
| It is not clear if leading rollup architecture (OP Stack and Arbitrum Orbit) | ||
| could be made compatible with XCM. | ||
|
|
||
|
|
||
| ## Unresolved Questions | ||
|
|
||
| It is highly desirable to know the throughput of Polkadot DA with popular rollup architectures OP Stack and Arbitrum Orbit. | ||
| This would enable CEXs and EVM L2 builders to choose Polkadot over Ethereum. | ||
|
|
||
| ## Future Directions and Related Material | ||
|
|
||
| If accepted, this RFC could pave the way for CorePlay on Asset Hub for Polkadot/Kusama, | ||
| a major component of Polkadot 2.0's smart contract future. | ||
|
|