Add EVM+ink! Contracts Pallets to Asset Hub for Polkadot #66
Conversation
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.
sourabhniyogi
force-pushed
the
cn-add-smartcontracts-to-assethub
branch
from
b77c11b
to
a8e5c25
Compare
|
What is the point of this? The whole point of Polkadot was that Parachains would provide specific functions to the broader ecosystem. By adding SmartContract capabilities to AssetHub you will use AssetHub's blockspace for something it was not meant to do. |
|
Utilizing Polkadot DA, Polkadot Rollups can bring DOT demand far greater than Moonbeam + Astar's demand for DOT alone.
In RFC #32, it was decided that Smart Contracts could not be on the Relay Chain. If there is a charter enumerating all the things that AssetHub was meant to do vs not meant to in the 2.0 era, take a look at that.
System chains are the next logical choice beyond the relay chain itself. Out of all system chains, AssetHub is the only sensible choice.
In the 2.0 era, Polkadot Rollups should not depend on other parachains' ability to secure CoreTime. Depending on AssetHub is superior because it has no risk of suddenly being unable to secure funds to acquire CoreTime due to market conditions.
AssetHub's blockspace is hardly used at present, but enabling AssetConversion+Polkadot Rollups (with Blobs/Sugondat) will change in the 2.0 era.
There will be many uses for AssetHub, from minting NFT collections to being the place where stablecoins USDC + USDT are integrated with CEX.
Supporting Rollups and combining with Polkadot's superior DA (from Blobs chains, superior relative to Ethereum) is one powerful way to bring in new high scale DOT users to the Polkadot ecosystem. Ignoring this opportunity to protect a few 1.0-era parachains in a 2.0-era makes extremely little sense.
|
|
Polkadot's Common Good Parachains idea is to have parachains that are app-specific. If you start adding features, what is the goal of having other parachains like Moonbeam, Astar, and HydraDX? Let's call it a day and add a single-sided AMM to AssetHub, Privacy features, prediction markets, and automation. Smart Contracts on Polkadot were denied because they are moving ALL functionalities that are not just block finality-related to system chains to maximize Polkadot's blockspace for security. Asset-Hub's blockspace was designed for Asset-specific things, not smart contract execution. |
It was originally, but the content of this RFC argues for a change in its design to extend from "Asset-specific things" to include smart contract execution. This supports both EVM sync patterns with those "Asset-specific things" and Polkadot 2.0 technologies:
Many Polkadot Rollups require EVM (deposits, withdrawals, fraud proofs, ...) -- converting them to pallets makes little engineering sense. Many popular defi primitives can usefully work with the top assets of AssetHub (DOT, USDC, USDT), yes, without any other parachains. This has the potential for making AssetHub accessible for everyday users and developers while bringing in additional DOT revenue from those same users and developers. The choice is clear: While the past started with choice (1) which made sense in the 1.0 era, this RFC argues for choice (2) in the 2.0 era. |
|
AssetHub should probably move the oposite direction, meaning improve performance by optimizing for limited functionality. As an example, you cannot safely run a smart contract chain over storage wich lacks non-membership proofs, but if you give up non-membership proofs then you could've optimal uniform depth storage. AssetHub might or might not need non-membership proofs. It's also possible "best effort" uniform depth storage like Cosmos works well enough in practice. We donno right now.. As for strategy & revenue.. In elastic scaling, we'll permit parachains to make blocks faster than the relay chain, but as their speed increases their data model must address liveness concerns. There are diverse somewhat incompatible ways smart contract chains could handle this smart contract vs liveness conflict, including networking restrictions, collator negotiations, runtime rust-like borrowing, restricted langauges, etc. In polkadot, we've beaten ETH roll ups on the performacne vs security trade off, but we've never solved this smart contract vs liveness conflict. And nobody else did either because the design space looks huge. We'll likely want multiple strong smart contract chains like Moonbeam and Astar, who make different choices and explore different parts of this design space. It's thus best if we do not step on the toes of our smart contract parachains right now. |
@burdges Ser, what performance do you need to see improve? Forcing Polkadot developers into asynchronous patterns to use AssetHub is unnecessary and inhibits usage of AssetHub and Polkadot generally. The USDC and USDT assets on AssetHub are barely used, the AssetHub blockspace is barely used. It was one thing to make the performance argument on the relay chain in RFC #32, but we're not talking about the relay chain anymore. Having sync programming constructs on AssetHub is necessary for Polkadot Rollups, valuable for ink/Coreplay, and to essential for maximizing the use of top 2 assets other than DOT in the ecosystem: USDT and USDC. Failing to do this LIMITS Polkadot growth. If AssetHub performance issues exist, then AssetHub should be improved by developers actually USING AssetHub and hitting the performance limits NOW, not in several years when someone has finally figured whether AssetHub may or may not need non-membership proofs.
Your approach appears to be rooted in fear and highly regressive. Polkadot already has these strong contract chains like Moonbeam and Astar, which will continue to exist because they are usable and successful in their own right, and have been since the end of 2021. Two years have passed. Now they will bring in a certain amount of CoreTime revenue in 2024 and we need to grow Polkadot to new heights. This RFC is concerned about making AssetHub usable for developers working with AssetHub assets in defi/nft apps, the easier to use ink=>Coreplay smart contract programming constructs, and Polkadot Rollups through relatively small changes on AssetHub that are extremely easy to justify as bringing in new DOT revenue. Polkadot can win everything, but not with an approach that is rooted in fear and regressive thought patterns that artificially force Polkadot 1.0 era technology on everyone, with some fake requirement of needing to show off that yes, async patterns need to exist. Async programming constructs are already widely being used in Polkadot AND in competing Web3 ecosystems, sync+async programming constructs are being used in Polkadot AND in competing Web3 ecosystems. Its not a novel thing to be exploring async+sync programming patterns anymore, ser. Its time to advance to new places with Polkadot 2.0 vision. Its time now. |
|
What if I want to build directly on top of Polkadot/Kusama skipping the parachains and pay txn fees directly using DOT/KSM rather than parachain native token? Is Asset Hub the better viable option? Recently I came across https://yerba.network/ by sasha(ink dev), sounds interesting to be able to pay txn fees using KSM. |
You can do that on Karura / Acala from like a year ago I do want to point it out, from a purely technical perspective, Frontier is not a good EVM stack that play nicely with the core time model or works with light client. There are many incompatibilities between EVM and core time model, and I cannot support this unless a feasibility study is implemented. I can list a few incompatibilities to get you start thinking:
Besides, many use cases simply doesn't require AH to have smart contracts. |
|
@xlc thank you for your answer, appreciate the reply. What if I want to create and use smart contracts with ink! on Polkadot directly, instead of on its parachains, because I feel it's safer and more trustworthy? Is this a possibility in near future? I understand there are some challenges associated with it as Jeff pointed out earlier. But as a dev POV I want ink Smart Contracts as a first step into Polkadot or Kusama then scale later on into parachains if needed. |
|
We will never have smart contracts on relaychain directly. We may have smart contracts on a system chain. But what is the problem you trying to solve again? |
@xlc The incompatibilities between EVM and the CoreTime model are not relevant to the RFC:
You must have something else in mind. Can you explain how the incompatibilities between EVM and CoreTime affect the ability to add EVM pallets to AssetHub?
@xlc The RFC recommends that Astar follow Astar's design choices (rather than Moonbeam or Acala), which is the #1 parachain in the ecosystem by marketcap. However, I'd love to hear why you think Astar's choices would be bad for AssetHub relative to Acala or Moonbeam, with TWO YEARS of hindsight now. Can you help? Astar uses Frontier with a small but important set of modifications, which are well documented, easy to apply to AssetHub, and hardly require a "feasibility study". There are TWO YEARS of Astar data to act as a "feasibility study" for AssetHub to basically mirror the same judgements (and basically the same from Moonbeam, and maybe a bit less for Acala, you know best). It would be absolutely bizarre to demand a feasibility study with this much history. [Aside: I think it would be wonderful to have a "CoreEVM" update that addresses the CoreTime incompatibilities with Frontier so that a parachain could use EVM pallets as well. THIS would be a powerful feasibility study, I hope you can lead it and the whole ecosystem would benefit with a giant Frontier update! Call it CoreEVM! Or ETHCore -- That would be poetic =)] |
|
With ED, it is not possible to have 100% EVM compatibility. Acala have ED and not 100% EVM compatibility. Moonbeam don’t and have it. With Frontier, user will not be able to access EVM via light client. The EVM RPC doesn’t work with tools like Chopsticks. They are just unsolved problems and everyone is making some trade offs. A study is absolutely required to understand the trade offs and then allow everyone to make a decision. |
Since none of your above points are about CoreTime (still don't understand why you brought it up..), the tradeoff decisions concerning EVM + ink! are then about what specific choice AssetHub should make, which are extremely well informed by over two years from Polkadot's top 3 parachains [circa December 2021]. For the 2 parameters you brought up
Concerning (1) and non-zero ED, is there some write up from Acala + Astar about how the non-zero ED choices differ that everyone can study to decision how AssetHub should make similar or different choices? I did not see much to go on here concerning design choices: Concerning (2), I am unfamiliar why requiring light support for Frontier should derail ink!/EVM support. Can you explain this in detail? It is NOT essential to have 100.0% EVM Compatibility, but it IS essential to support the following use cases:
@xlc Can you itemize what parameters you would like to see characterized in a tradeoff study? I think its really important to recognize which parameters are truly important and use the learnings from Astar+Acala to make the correct decisions for AssetHub. |
|
We have this https://evmdocs.acala.network/general/about-acala-evm+ which may or may not answer all your questions but it explains some of the design process of Acala EVM+. For the rest of the discussion, I would like to get back to step zero. I believe the goal for all of us is to solve some issues, which you have listed a few. But I don't think you want to add smart contracts to AH for the sake of adding it. We should explore all alternatives before deciding if a particular solution (i.e. the one you proposed) is the best one. So please define the problem. You have listed two items:
For 1: Because you did not define exactly the requirements, so my solution to the problem that you have defined is simply use one of the existing EVM parachain. I know this answer does not satisfy you but let's iterate it from here. You could say my solution does not solve some specific use case and then we could try to change this alternative approach in such way to address the use case you proposed. It could totally be implementing smart contract in AH, but should not skip the intermediary steps or I am sure our maths teacher won't be happy. For 2: There are lot more alternatives:
|
Cool, are all the parameters you would expect from feasibility study covered in Acala's detailed overview there? If not, what is missing?
summarizes the problem of (1)+(2) below. If you have questions in the RFC, please ask and I will clarify. Super happy to improve the motivation section, thank you!
Again, the "Motivation" section of the RFC covers this topic. I did try to make it readable for both our math teacher and you =) Could you kindly review that?
So, this alternative should be ruled out. Do you see differently?
Blobs has the basics to serve Polkadot Rollups for a DA perspective, but converting all Rollup tech (OP, ARB, PolygonCDK) into rollup pallets is way too engineering intensive -- Thrum's shims model is just clearly better since it spares tons of engineering replication with little to gain. In contrast, adding EVM pallets to AssetHub is largely about making tradeoff decisions based on the history of successful EVM parachains -- I do agree reviewing the tradeoffs for AssetHub adding EVM+ink/Coreplay merits careful review of the EVM+ink/Coreplay parachains. |
|
@joepetrowski (all) Is a separate "OpenEVM" SYSTEM chain (with the assetConversion pallet) -- approved by OpenGov Root Referendum -- a better way to address the need for Polkadot Rollups needing EVM? https://twitter.com/giottodf/status/1757275333143707849 This keeps AssetHub purely doing ONE THING (yay!) and relegates the OpenEVM SYSTEM chain to do other things:
The underlying thesis is that DOT Revenues from OpenEVM SYSTEM chains would exceed that of the EVM Smart Contract parachains (Moonbeam + Astar). Questions:
|
Probably, yes. I'm discussing with some other Fellows the best way to essentially override the Fellowship RFC process in a way that doesn't take the single-proposal Root track, see polkadot-fellows/runtimes#184
Yes but that's a separate issue to "should the chain exist". It's purely a scheduling/core assignment problem, which really should be automated to scale with more load.
IMO this would be the Fellowship. The Fellowship has a mandate to maintain and develop the Polkadot protocol. Of course, people in the Fellowship have opinions about what should be (or not be) in the protocol, but a Root referendum that says unequivocally, "the network wants X feature", should be sufficient. The Fellowship works for the network. Of course, if what the network wants is wildly insecure or reckless, the Fellowship's job would be to try to stop it or at least not support it, and at the point it would come to someone else implementing the change and doing a non-Fellowship-endorsed release/upgrade.
I think that a new collective for this purpose is a terrible idea. We don't have a "Bridge Hub collective". Don't get me wrong, I love collectives and think they are hugely underutilized, but let's not make every single problem a nail and collectives a hammer. We already have a collective for the maintenance of the system, the Tech Fellowship, and I don't see why we'd need another Fellowship for the maintenance of a piece of the system.
I would much rather see a solution that does not put EVM on Asset Hub. |
Who'd maintain this? We've multiple external parachain projects who do this job now, so does one want them to merge? Or does someone want tresury funds to compete with them? We do have folks doing EVM compiler work at Parity, presumably EVM->PolkaVM eventually. We should not bring the actual EVM chain work in-house at Parity or W3F of course.
You said "rollup" and "need" in the same sentence. Afaik all roll ups are pessimisations vs parachains in one of two senses, either zk roll ups need exterme CPU time costs, or else optimistic roll ups need long unlocking period, meaning rollups needs days or weaks of delay when sending messages. And optimistic roll ups have the same problem as nested relay chains that polkadot cannot validate parachain's off-chain concensus. If someone wants a high-speed low-security chain, then we could do that in other ways, like cores with fewer approval checkers, but it still complicates messaging, which makes doing it messy. In brief, we already have better tech for doing what rollups do, which makes them mostly pointless. We can have parachains which also act like an optimistic roll up on another chain like ETH, but likely bridges superceed these. A fully EVM programable bridge maybe interests folks. A system EVM chain cannot facilitate these features. |
Like Rob said here, an RFC just says the "what". With sub-treasuries functioning now, it would make sense for people to apply for funding to implement approved RFCs. Staying neutral to the EVM thing here, just saying that if the Root origin says "we want something", I'm sure there will be a way to make implementation happen. |
An OpenEVM Collective, seeded with technical people deeply involved in improving Polkadot EVM technology https://github.com/polkadot-evm/seeding I would think this could have been in the Fellowship, but the Fellowship has a LOT of extremely complex feelings about EVM technology, as if its an unwanted bastard child, so it is SUPER clear that its valuable to give EVM people their own space rather than pretend the bastard doesn't exist. Pretending the EVM bastard doesn't exist is wrong. Polkadot can do EVM -- with all its bastardized synchrononous atomicity -- in its own way with its superior CORES. An OpenEVM collective distinctly committed to doing this with a full heart in a Polkadot-first way can do amazing things for the Web3 industry and I hope the Fellows can see one distinct from the Fellowship is valuable and either timely or long overdue.
Interesting question, but... they already issued their own non-DOT token in all cases I know of, that would be insane because the idea is to bring far more DOT revenue instead.
The idea is to bring far more DOT revenue with (initially or permanently) treasury-funded CoreTime to demonstrate that Polkadot EVM tech is not just better in theory but in the marketplace, to compete not with other Polkadot parachains but with Arbitrum, Optimism, Avalanche et el. The "them" framing has to be not rooted in a Polkadot frame but in the broader Web3 ecosystem. A serious % of all available cores (say, 8-16%, like 24 cores or 48 cores out of 300) can be allocated to 1-3 "OpenEVM" chains. If Moonbeam/Astar is using 1 "core" and operating at 6s, my naive idea is that:
This block production time trick is widely used, and everyone who knows anything about optimistic rollups also knows that users pretty much forget about the 7 day window. A bunch of OpenEVM chains (plural, because we should retrofit XCM to this somehow surely) could take 48 cores and have different parameters with different gas/weight limits, while PolkaVM/CorePlay grows up to compete, something like this with 42 cores out of 300:
I should think existing EVM parachains would also want more cores in pretty much the same way in order to compete not with OpenEVM or each other but with the broader Web3 ecosystem. If they ask for OpenGov supported resources for the same number of 24-48 cores, they should offer similar amount of DOT revenue.
Your conclusion is that Polkadot Optimisic Rollups with a "Blobs" chain and Optimism and Arbitrum shims with Polkadot DA would suck in the same way as Optimism and Arbitrum, right? (Not 100% sure) Ok, if we can replicate the above tricks with more cores in a set of OpenEVM chains (where DOT revenue accrues to Polkadot Treasury, and not with EVM parachains with their own token), we can scrap Polkadot Rollups. Can you kindly explain "cores with fewer approval checkers" to us and help us get beyond the above naive idea/ improve it in a OpenEVM+CoreTime combined world? So now that Polkadot 2.0 is virtualizing VMs themselves in work packages, for Polkadot EVM chains to compete in the broader Web3 marketplace (not in "we have better tech", I mean like in terms of TVL, marketcap, TPS vanity metrics, etc.), we should utilize the full power of CORETIME+Frontier [or whatever is better]. Can we agree on this? Whether OpenEVM chains NEED to be system chains can be decided by OpenGov, I don't think users really can see it. But Circle+Tether+CEXes see the difference clearly. They clearly see system chains like AssetHub with EVM powers totally different from non-system chains with EVM powers. For a key multi-ecosystem feature like USDC CCTP, its a massive loss for Polkadot to not have CCTP somewhere, and I don't see a coherent plan for this. The hope might be, however, that with a lot of talented people in an OpenEVM collective an equivalent credibility would exist for OpenEVM chains. Then the OpenEVM chains would be taken as seriously by Circle+Tether+CEXes if they weren't system chains. Anyone who looks would see the "asset related" functionality of OpenEVM chains as being the shadow AssetHub, kind of subversive. |
|
Everytime a core consumer / parachain / external agent develops a widely used tool, will we discuss if Polkadot should subsidize it into it's "common goood" space? Polkadot has a specific job, and bringing overhead costs (maintenance) and production costs (block-space) up should be carefully considered. The question is if EVM makes the cut. Avalanche c-chain shows that it might. |
|
I think the scope should be reduced or broken up to just concern the I don't understand what |
|
I'd think https://forum.polkadot.network/t/contracts-update-solidity-on-polkavm/6949 supersedes this RFC, given polkavm contracts should definitely work. |
Yes, and the target runtime likely won't diverge much from |
Excellent. I'll make the change based on |
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 smart contract programmers
These changes in AssetHub are enabled by key Polkadot 2.0 technologies: PolkaVM supporting Coreplay, hyper data availability in Blobs Chain.