CoreJam System Chain on EVM L2s with OP Stack

[sourabhniyogi]

Original: Polkadot+Kusama should support the possibility of having up to 10-30% of its blockspace weight allocatable to EVM and WASM Smart Contracts. This is not for Polkadot to be a yet another EVM Chain, but specifically to:

1. support the use of Polkadot's Data Availability resources to non-Substrate [largely EVM] L2 Stacks, which will bring in additional demand for DOT and through those networks, new users and developers
2. (assuming CoreJam Work Packages have some direct relation to EVM Contracts + WASM Contract Interpretation), support Polkadot 2.0 experimentation in its transformation into a “map reduce” computer and bring in new classes of CoreJam+CorePlay developers in addressing sync/asynchronous composability

Updated: This proposal attempts to adapt the CoreJam architecture to EVM L2s, specifically utilizing OP Stack + Solidity instead of Polkadot/Substrate. Almost all CoreJam concepts are retained, but CoreJam's interfaces are replaced with Solidity/EVM Contracts + OP Stack's Golang.

[rphmeier]

With respect to (1) I believe this is out of scope of adding EVM contracts to Polkadot per-se (though is something I'd very much like to see). As long as Polkadot's DA is exposed, L2 stacks can be built anywhere on top of Polkadot.

As you mentioned in the RFC, I did indeed write a post advocating for every chain to have smart contracts. I think my arguments on synchronous composability still hold. I'd tentatively support having some very limited amount of Polkadot relay-chain blockspace allocated to smart contracts, though in the event that on-chain processing becomes the bottleneck for the number of cores, I'd advocate for the smart contract functionality to be outmoded by the number of cores.

[gavofyork]

CoreJam already provides for the possibility of permissionless logic to be introduced for determination on the Relay-chain itself.

CoreJam, as it already stands, enables both (1) and (2) without needing to reassign "blockspace" in this way.

[sourabhniyogi]

@gavofyork [@rphmeier] Rather than chart a course for Kusama 2.0 with CoreJam+EVM, I rewrote this to be a totally different approach to CoreJam. In last month's call, you asked "is Polkadot just parachains, is CoreJam some other thing" and I think CoreJam's map-reduce is just too promising to be just on Polkadot/Substrate, done in Rust only, developed with Polkadot 1.0, or forced into a "shim" onto parachains with Frontier barely more than a thought on Polkadot 2.0 roadmap. I hope you can lead people out of "Polkadot is better than EVM/Smart Contracts/Solidity" to see things differently. I think a new generation of students deserve it.

Lots of basic questions I had, having gone through the exercise:

• how EVM users should submit WorkItem going into work packages/services
• how to bring Instantaneous CoreTime Credits back, why you removed it in favor of Bulk CoreTime only
• how to map dynamic backing groups into a set of OP Stack nodes
• how to measure cores
• how to measure DA throughput

I can mostly go divergent from here on out and come up with my own answers to a lot of this, but it would be cool if CoreJam here is CoreJam there with your best advice on how that could happen.