polkadot-fellows/RFCsTable of Contents
-| 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 |
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 will benefit from easier-to-use smart contract environments.
-These changes in AssetHub are enabled by key Polkadot 2.0 technologies:
-PolkaVM supporting Coreplay, and
-hyper data availability in Blobs Chain.
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 RFC #32 - Minimal Relay Chain architecture,
-DOT balances are planned to be shifted to Asset Hub, to support Polkadot 2.0's
-CoreJam map-reduce architecture.
-In this 2.0 architecture, there is no room for synchronous contracts on the Polkadot relay chain --
-doing so would waste precious resources that should be dedicated to 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.
-EVM Smart Contract chains within Polkadot and outside are dominated by defi + NFT applications. While the assetConversion pallet (implementing Uniswap v1) is a start to having some basic defi on AssetHub, -many programmers may be surprised to find that synchronous EVM 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 (by marketcap circa early 2024: Moonbeam + Astar) who do include the EVM pallets.
-This leads to a cumbersome Polkadot EVM 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.
The ink! defi ecosystem remains nascent, having only Astar as a potential home, and empirically has almost no defi/NFT activity. Although e.g. uniswap translations have been written,
-An AssetHub for Polkadot deployment of EVM and ink! contracts, it is hoped, would likely support new applications for top assets (USDC and USDT) and spur many smart contract developers to develop end user applications with familiar synchronous programming constructs.
-Polkadot Data Availability technology is extremely promising but underutilized.
-We envision a new class of customer, "Polkadot Rollups" that can utilize Polkadot DA far better than Ethereum and other technology platforms.
-Unlike Ethereum's DA which is capped at a fixed throughput now extending to EIP-4844, Polkadot data availability is linear in the number of cores.
-This means Polkadot can support a much larger number of rollups than Ethereum now, and even more as the number of cores in Polkadot grows.
-This performance difference has not been widely appreciated in the blockchain community.
Recently, a "Blobs" chain has been developed to expose Polkadot DA to rollups by senior Polkadot Fellows:
- -A rollup kit is mappable to widely used rollup platforms, such as OP Stack, Arbitrum Orbit or StarkNet Madara.
-A Blobs chain, currently deployed on Kusama (paraID 3338), enables rollups to utilize functionality outside the Polkadot 1.0 parachain architecture by having rollups submit transactions via a rollup kit abstraction. The Blobs chain write interface is simple blobs.submitBlob(namespaceId, blob) with a matching read interface.
However, simply sending blobs is not enough to power a rollup. End users need to interact with a "settlement layer", while rollups require proof systems for security.
-Key functionality for optimistic rollups (e.g. OP Stack, Arbitrum Orbit) are:
-Analogous functionality exist for ZK-rollup platforms (e.g. Polygon zkEVM, StarkNet Madara), with high potential for using the same Blobs+AssetHub chains.
-While it is possible to have the operations in EVM Contracts translated in FRAME pallets (e.g. an "opstack" pallet), we do not believe a pallet translation confers significant benefits.
-Instead, we believe the translation would require regular updates from the rollup platform, which have proven difficult to implement in practice.
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 nowhere near as many developers.
-This may be due to missing tooling, slow compile times, and/or simply because ink!/Rust is just harder to learn than Solidity, the dominant programming language of EVM Chains.
Fortunately, ink! can compile to PolkaVM, a new RISC based VM that has the special capability of suspending and resuming the registers, supporting long-running computations.
-This has the key new promise of making smart contract languages easier to use -- instead of smart contract developers worrying about what can be done within the gas limits of a specific block or a specific transaction, Coreplay smart contracts can be much easier to program on (see here).
We believe AssetHub should support ink! as a precursor to support CorePlay's capabilities as soon as possible.
-To the best of our knowledge, release times of this are unknown but having ink! inside AssetHub would be natural for Polkadot 2.0.
AssetHub is a major component of the Polkadot 2.0 Minimal Relay Chain architecture. It is critical that smart contract developers not be able to clog AssetHub's blockspace for other mission critical applications, such as Staking and Governance.
-As such, it is proposed that at most 50% of the available weight in AssetHub for Polkadot blocks be allocated to smart contracts pallets (EVM, ink! and/or Coreplay). While to date AssetHub has limited usage, it is believed (see here) that imposing this limit on smart contracts pallet would limit the effect on non-smart contract usage. A excessively small weight limit like 10% or 20% may limit the attractiveness of Polkadot as a platform for Polkadot rollups and EVM Contracts. A excessively large weight like 90% or 100% may threaten AssetHub usage.
-In practice, this 50% weight limit would be used for 3 categories of smart contract usage:
-assetConversion pallet to support many common ERC20/ERC721/ERC1155 centric applications.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 significantly. This likely motivates EVM contract developers to migrate to a EVM contract chain and/or rethink their application to work asynchronously within CoreJam, another major Polkadot 2.0 technology.
-It is essential to make AssetHub assets interface well with EVM Smart Contracts. -Polkadot parachains Astar and Moonbeam have a mapping between assetIDs and "virtual" EVM Contracts.
- -We propose that 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) Other Assethubs assets should 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:
- -Polkadot parachains Astar and Moonbeam adopted two very different approaches of how end users interact with EVM Contracts.
-We propose that AssetHub for Polkadot adopt the Astar solution, mirroring it as closely as possible.
A substantial motivation in this proposal is to increase demand for DOT via two key chains:
-Enabling EVM Contracts on AssetHub will support DOT revenue from:
-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 these new technical capabilities on a flagship system chain.
-To the extent these capabilities are attractive to smart contract developers, this has the potential for bringing in new DOT revenue from a system chain.
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 platform parachains.
-We believe the lack of growth of parachains in the last 12-18 months, and the high potential of CorePlay motivates new options be pursued in system chains.
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 small based on the proven deployment of Astar and Moonbeam.
-The cost will be justified compared to the potential upside of new DOT revenue from defi/NFT applications on AssetHub and the potential for utilizing Polkadot DA for Polkadot rollups.
Testing the mapping between assetIDs and EVM Contracts thoroughly will be critical.
-Having a complete working OP Stack chain using AssetHub for Kusama (1000) and Blobs on Kusama (3338) would be highly desirable, but is unlikely to be required.
-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.
-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.
-It is believed that EVM pallet (as deployed on Moonbeam + Astar) is sufficiently compatible with Ethereum, and that the ED of 0.01 DOT pose negligible issues.
-The messaging architecture for rollups are not compatible with Polkadot XCM.
-It is not clear if leading rollup platforms (OP Stack, Arbitrum Orbit, Polygon zkEVM) could be made compatible with XCM.
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.
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.
-The importance of precompiles should
Table of Contents
This RFC proposes changing the current deposit requirements on the Polkadot and Kusama Asset Hub for creating NFT collection, minting an individual NFT, and lowering it's coresponding metadata and attribute deposit. The objective is to lower the barrier to entry for NFT creators, fostering a more inclusive and vibrant ecosystem while maintaining network integrity and preventing spam.
-The current deposit of 10 DOT for collection creation (along with 0.01 DOT for item deposit and 0.2 DOT for metadata and attribute deposit) on the Polkadot Asset Hub and 0.1 KSM on Kusama Asset Hub presents a significant financial barrier for many NFT creators. By lowering the deposit requirements, we aim to encourage more NFT creators to participate in the Polkadot NFT ecosystem, thereby enriching the diversity and vibrancy of the community and its offerings.
The actual implementation of the deposit is an arbitrary number coming from Uniques pallet. It is not a result of any economic analysis. This proposal aims to adjust the deposit from constant to dynamic pricing based on the deposit function with respect to stakeholders.
deposit function adjusted by correspoding pricing mechansim.Previous discussions have been held within the Polkadot Forum community and with artists expressing their concerns about the deposit amounts. Link.
-This RFC proposes a revision of the deposit constants in the nfts pallet on the Polkadot Asset Hub. The new deposit amounts would be determined by a standard deposit formula.
This RFC suggests modifying deposit constants defined in the nfts pallet on the Polkadot Asset Hub to require a lower deposit. The reduced deposit amount should be determined by the deposit adjusted by the pricing mechanism (arbitrary number/another pricing function).
Economic Impact on Previous Stakeholders: The change could have varied economic effects on previous (before the change) creators, platform operators, and investors. Balancing these interests is essential to ensure the adjustment benefits the ecosystem without negatively impacting its value dynamics. However in the particular case of Polkadot and Kusama Asset Hub this does not pose a concern since there are very few collections currently and thus previous stakeholders wouldn't be much affected. As of date 9th January 2024 there are 42 collections on Polkadot Asset Hub and 191 on Kusama Asset Hub with a relatively low volume.
-The prevention of "spam" could be prevented by OpenGov proposal to forceDestoy list of collections that are not suitable.
The primary performance consideration stems from the potential for state bloat due to increased activity from lower deposit requirements. It's vital to monitor and manage this to avoid any negative impact on the chain's performance. Strategies for mitigating state bloat, including efficient data management and periodic reviews of storage requirements, will be essential.
-The proposed change aims to enhance the user experience for artists, traders and utilizers of Kusama and Polkadot asset hub. Making Polkadot and Kusama more accessible and user-friendly.
-The change does not impact compatibility as redeposit function is already implemented.
There remain unresolved questions regarding the implementation of a function-based pricing model for deposits and the feasibility of linking deposits to a USD(x) value. These aspects require further exploration and discussion to ascertain their viability and potential impact on the ecosystem.
-We recommend initially lowering the deposit to the suggested levels. Subsequently, based on the outcomes and feedback, we can continue discussions on more complex models such as function-based pricing or currency-linked deposits.
If accepted, this RFC could pave the way for further discussions and proposals aimed at enhancing the inclusivity and accessibility of the Polkadot ecosystem.
@@ -1591,16 +1393,16 @@This RFC proposes changes that enable the use of absolute locations in AccountId derivations, which allows protocols built using XCM to have static account derivations in any runtime, regardless of its position in the family hierarchy.
-These changes would allow protocol builders to leverage absolute locations to maintain the exact same derived account address across all networks in the ecosystem, thus enhancing user experience.
One such protocol, that is the original motivation for this proposal, is InvArch's Saturn Multisig, which gives users a unifying multisig and DAO experience across all XCM connected chains.
-This proposal aims to make it possible to derive accounts for absolute locations, enabling protocols that require the ability to maintain the same derived account in any runtime. This is done by deriving accounts from the hash of described absolute locations, which are static across different destinations.
The same location can be represented in relative form and absolute form like so: