Support Non-Substrate EVM L2 Networks by adding EVM+WASM Contracts to Polkadot/Kusama

[sourabhniyogi]

This should happen in 2023 not for Polkadot to become yet another EVM Chain but to set the stage for Polkadot 2.0 turning into a “map reduce” computer in 2024.

@rphmeier argues for this on technical grounds of synchronous composability here, arguing that EVERY chain, even app-chains, should have smart contracts:

Hybrid Chains: Every Chain Should Have Smart Contracts | rob.tech

What the hybrid-chain approach is likely to look like in practice is application-specific logic deployed alongside smart contracts, with a limited amount of blockspace allocated to smart contracts. Given that contracts would only be able to consume some of the resources per-block, the absolute costs of gas would be higher relative to chains that focus entirely on smart contracts, all else equal.

@joe echoes this here for AssetHub:

@joepetrowski

For interactions that absolutely must be synchronous … then we could explore the idea of hybrid blockspace where we set aside say 10% of the blockspace for contract execution. If there is a lot of demand for this tranche of blockspace, then the gas price will increase a lot, motivating contract developers to migrate to a contract chain or rethink their application architecture to work asynchronously.

When I read the above “asynchronous” + “synchronous”, I am thinking this:

• asynchronous = slow, multi-block cross-chain messages, done within mouse speeds in Polkadot’s XCM and slothy speeds outside Polkadot
• synchronous = fast, single block, done with elephant sized parachains in Polkadot and mouse-sized EVM Contracts everywhere else

but in Polkadot 2.0’s “Map Reduce”/Collect-Refine-Join-Accumulate architecture, we will have a very different way of working through synchronous + asynchronous composability. This will take center stage in 2024 and I want to see the prereqs addressed in 2023.

There will be TREMENDOUS resistance in the ecosystem to the idea of bringing in EVM + WASM Contracts to the Polkadot + Kusama + … chains:

• [cultural tribalism]: People in the Polkadot ecosystem have been trained to think of EVM Contracts as stodgy old technology like DOS’s C:> coming straight from @gavofyork. It IS stodgy old technology, but it is also VERY widely known that EVM smart contract development (and WASM=ink! smart contract development) is “mouse-sized” relative to “elephant-sized” parachains (analogy from @darkfriend77). Everyone knows Solidity/EVM as easier to learn, way cheaper to deploy and use, and has a 100x larger community. Coreplay promises to change this, but it will take most of 2024 for this to come to fruition.

• [engineering concerns]: Engineers who see Moonbeam suffering from storage bloat from XEN probably see EVM Contracts in Polkadot/Kusama/AssetHub/BridgeHub as like giving Polkadot long COVID! Whatever medicine Moonbeam is taking for this parametrically, all system chains should get vaccinated from storage bloat. 10% for EVM Contracts + 20% WASM Contracts = 30% (in weight), seems like a a good conservative start.

• [business channel conflict concern]: Moonbeam, Astar and others will cite channel conflict ala “hey, smart contracts were our job!” just as they did concerning an AssetHub Asset Conversion Pallet. Both @rphmeier and @joe have very good economic predictions about what will happen. Read their comments above.

• [new revenue]: Polkadot’s DA is very likely to be a diamond in the rough, just waiting to be used for OP Stack, StarkNet and other L2 tech that use EVM Contracts like this one to manage deposits/withdrawal to+from Ethereum. Again, there is systemic cultural tribalism against EVM everything in Polkadot (cf this =)) – this systemic tribalism has to be overcome by recognizing that if this underutilized DA can be made demonstrably economically and technically superior, this is a large robust source of KSM=>DOT demand that can easily dwarf Coreplay/CoreJam experimentation in 2024, and might even solve the lack of incoming revenue for Kusama Treasury and lack of revenue growth in Polkadot. By having 10% of Polkadot/Kusama blockspace allocated to EVM L2 chains just like Moonbeam we can have new KSM=>DOT demand and solidly beat EIP-4844. Tribal arrogance would then be replaced with market cap increases.

I believe if Kusama + AssetHub on Kusama + BridgeHub on Kusama start incorporating this and overcome the cultural and engineering concerns, parachains may follow in 2024. With some luck, the map reduce computer can use these parachains as a “Polkadot 2.0 shard” and earn fees rather than spin around minting empty blockspace serving less than 1000 DAUs. If any parachains app chain functionality actually takes off to exceed some threshold of blockspace usage, every parachain’s governance could just adjust parameters accordingly to deemphasize generic EVM+WASM Contract functionality. Similarly, if Bulk Coretime Credits sales and Instantaneous Coretime Credits do not stimulate sufficient demand, DA-based revenue on Polkadot from EVM L2 tech can supplant shortfall.

Concretely, I would like to suggest that both EVM + WASM Contract functionality be deployed in Winter 2024/Spring 2024 on { Kusama, AssetHub on Kusama, BridgeHub on Kusama } and that Polkadot Fellows review this idea closely here, and it be a topic on a Monthly Live Fellowship Call.

[burdges]

As a rule, if you think you need synchronous global state access, then you’ve not yet understood your problem well enough.

We’ve exceptions of course, but if you ignore this rule too much, then your users would eventually figure out your ethereum-like blockchain cannot be scalable (false in general, but true if you demand synchronous global state like ethereum).

Anyways…

AssetHub should be scalable, which eventually requires being sharded across multiple chains, so then nothing could be synchronous across all of AssetHub.

AssetHub should’ve one shard parachain within each relay chain, but parachains of different relay chains cannot talk to one another by on-chain messages, only by off-chain state channels, ala XCMP. AssetHub could require multiple shards within each relay chain too, depending upon storage bloat, traffic, etc.

In either case, AssetHub cannot have synchronous global state across all of AssetHub, only within individual shards of AssetHub. We’ll either have arbitrage or waiting periods for AMMs, ala uniswap. I’m unsure what contract-like functionality this argues for or against, maybe some nerfed contract that enforces asynchrony, but definitely not EVM. lol

As an aside, I suppose EVM parachain projects like Moonbeam have a rich future of attempting to apply our upcoming scalability tooling to their non-scalable smart contract chain state. A single centralized collator ala solana helps, but they could explore ideas like limited contract horizon too, or the 60+ similar ideas from old ethereum sharding discussions. lol

Also…

We want clean abstraction layers in the relay chain for several reasons, but smart contracts only make doing this painful. We’ll hopefully remove balances & accounts from the relay chains eventually, so no gas or contracts there either. lol

[sourabhniyogi]

Thank you @burdges – At @xlc’s recommendation and based on your thoughtful note, I wrote up RFC 33 - Support Non-Substrate EVM L2 Networks.

I am probably not alone in wanting your write ups on what you mean by

1. “how to apply the scalability tooling to non-scalable smart contract chain state”
2. “but smart contracts only make doing this painful”
3. out the 60 similar ideas on ethereum sharding which ones actually inform CoreJam/Coreplay designs in the “AssetHub could require multiple shards within each relay chain too, depending upon storage bloat, traffic, etc.” with Asset Actors

These would be immensely valuable to explain in detailed RFCs. I’m expecting CoreJam composability to use XCM in fully worked out examples independent of EVM/WASM Contracts – if that can be done, surely WASM Contract interpretation and then EVM Contract interpretation can be bolted on. If this is painful, its good pain to have high impact experimentation in a hybrid chain model.

We shouldn’t be fooled with “we’ll hopefully remove balances & accounts from the relay chains” unless backed with real plans. Every solution that just adding on async processes - just because we can – sure looks like premature scaling to me and leads me the horrible conclusion that Polkadot would be heading to being “default dead”.

We now know too much to treat these problems like we haven’t encountered them 60 times already. I’m certain we can figure out solutions but it does require real detailed answers to real problems!