CoreJam: Hello World! Collect-Refine-Join-Accumulate Examples

1

@rphmeier @bkchr @gavofyork : CoreJam (amazing!) deviates massively from “The Relay Chain has just one job” in allowing arbitrary MapReduce/Collect-Refine-Join-Accumulate “Work Packages” to run on Polkadot, making Polkadot the “Ubiquitous Computer” while also letting 100 parachains bloom.

I understand you’re seeking maximal generality in your WIP writeup but I have two pragmatic requests:

  1. connect Work Packages back to WASM (ink!) + EVM Contracts – like, do ink!/Solidity devs get backwards compatibility or not?

  2. provide a “Hello World!” Work package example (in ink! or Solidity) that illustrates Collect-Refine-Join-Accumulate stages with “Actors” and any underlying new concepts

Most people learn MapReduce with a word count example (eg like this).

Having just ONE well-worked out example with ink! or Solidity (which is NOT about validation) that uses the new Storage Pallet API should get us thinking about how devs use the CRJA Stages for “Actors” and stimulate a new era of experimentation.

1 Like
2

Thanks @sourabhniyogi

  1. With CoreJam, work packages can be anything - advancing a blockchain, executing Wasm (ink!) code, EVM interpretation. Backwards compatibility with everything happening on Polkadot already has been a prime concern.
  2. Absolutely. We will need very clear examples. At the moment, as an idea, it’s too early to demonstrate anything.
2 Likes
3

Awesome. My advice is that you ignore any instincts to slip in another innovation in the middle of the above and extend backwards compatibility from Polkadot to all Ethereum rollups.

On the opposite extreme of “Hello world” in complexity, could you address the how+why of Polkadot can serve the ONE very focussed use case of running an OP Stack chain on Polkadot (OP Stack representing 10 out of 33 Eth L2s)

  1. How (in ~5-10 slides) you envision an OP Stack chain actually interfacing with Polkadot in
    a CoreJam/CoreTime/CorePlay way

Explicitly situate your solution relative to EIP-4844, KZG commitments, proto-danksharding/danksharding.

  1. WHY someone building a OP Stack chain would use Polkadot as the L1 instead of Ethereum.

2b. If possible, contrast the above design with a Native EVM Parachain (Astar) vs zkEVM Parachain (Astar zkEVM) vs zkSync Era or StarkNet

  1. Exactly how the community could execute on the above vision in a decentralized way in 2024, rather than mostly produced from Parity.

You should put all the substance of the above into a Polkadot 2.0 white paper or RFC, parallel to CoreJam/… writeups. I think this will mobilize a lot of us to figure out how to contribute to this – If there is a working group we can develop out of this that can work with a high sense of urgency, lets form it.

Thank you for this exciting new direction, everything can be connected beautifully by combining technical excellence and execution across the entire Polkadot + Ethereum community

3 Likes
4

Any technological initiative that makes it easier to move from Ethereum L2 (whatever the flavor) to Polkadot is a good thing, an awesome weak signal. We must be aware that L2 networks are mainly lowering the transaction fees and the consequences of it. Probably low hanging fruit in some months…

The OP stack is a walled garden without the possibility of custom native tokens and the ability to pay gas fees with them. It imposes a significant commitment to access Ethereum liquidity, that would lead to friction and conflict between involved parties. In contrast, Polygon L2 allows for custom native tokens and promises interoperability across chains built with their technology, without the need for third-party relaying networks like Chainlink CCIP (with its own economy and sovereign currency). The current pressing issue is access to Ethereum liquidity, but in my opinion, this is a transitory situation stemming from market bubbles.

A clear path to transition from Polygon L2 to fully sovereign and interoperable Polkadot parachains seems like a good idea.

1 Like