fin

text/0033-kusama-hybrid-relay-chain.md

@@ -12,25 +12,23 @@ Polkadot+Kusama should pursue different usability and scalability:
 
 1. Polkadot 2.0 should be a [Minimal Relay Chain](https://github.com/polkadot-fellows/RFCs/pull/32), maximizing cores/resources for maximum scalability of CoreJam + CorePlay's asynchronous-first patterns
 
-2. Kusama 2.0 should be a Hybrid Relay Chain, prioritizing developer+user friendliness over scalability with full backwards compatibility with 1.0 Blockchain technology: EVM+WASM Smart Contracts
+2. Kusama 2.0 should be a [Hybrid Relay Chain](https://www.rob.tech/blog/hybrid-chains/), prioritizing developer+user friendliness over scalability with full backwards compatibility with 1.0 Blockchain technology: EVM+WASM Smart Contracts
 
-With this 2 network refactorization, developers and users can start their
+This solution elevates Kusama to the level of Ethereum while giving developers on-ramps to Polkadot's new scalability solutions.
 
 ## Motivation
 
-Polkadot 1.0's approach to scalability since inception has been as a platform for heterogenous shards or "app chains".   Asynchronous interoperability between shards was enabled through XCM through the relay chain, including two teams (Moonbeam/Moonriver, Astar/Shiden) who successfully led Substrate-first EVM Chains in 2020-2023, promoting EVM + WASM Contract platforms widely to a large user and developer community.   Almost all other chains ignored smart contract usage entirely, in favor of Rust pallets.   Still, when not using XCM asynchronous patterns (used largely just for cross-chain asset transfers), both sorts of approaches rely on developers pursuing a blockchain-centric state transition way of operating: everything has to be done within one block, whether using EVM/WASM Smart Contracts or Substrate Pallets.
+Polkadot 1.0's approach to scalability since inception has been as a platform for heterogenous shards or "app chains".   Asynchronous interoperability between shards was enabled through XCM through the relay chain, including two teams (Moonbeam/Moonriver, Astar/Shiden) who successfully led Substrate-first EVM (+ WASM) Smart Contract dev platforms in 2020-2023, promoting them widely to a large user and developer community.   Almost all other chains ignored smart contract usage entirely, in favor of Substrate pallets.   Still, when not using XCM asynchronous patterns (used largely just for cross-chain asset transfers), both sorts of approaches rely on developers pursuing a blockchain-centric state transition way of operating: everything has to be done within one block with sync patterns, whether using EVM/WASM Smart Contracts or Substrate Pallets.
 
-In 2.0, the state transition function is refactored by bringing asynchronous patterns to the center with Map-Reduce/Collect-Refine-Join-Accumulate (CJRA) + Actor.  Polkadot fundamentally revolutionizes the bottleneck to blockchain scalability at the "Reduce" step with CoreJam and with a more intuitive "Actor" programming model in CorePlay.   This will take most of 2024 to develop, while most blockchain technology will continue to live on with 1.0 EVM Contracts, which non-existent treatment of async patterns: messaging is bolted on by networks.
+In Polkadot 2.0, the state transition function is refactored by bringing asynchronous patterns to the center with CoreJam's Map-Reduce/Collect-Refine-Join-Accumulate (CJRA) + CorePlay Actor programming models.  This will take most of 2024 to develop, while most blockchain technology will continue to live on with 1.0 EVM Contracts, which have non-existent treatment of async patterns: messaging is bolted on by networks like Axelar and LayerZero.
 
-While Polkadot aims to be a massively scalable map reduce computer, in most cases, developers do NOT need scalability right away and both devs+users find the multichain factorization unnecessarily complex.  Few parachains have scaled their user base to more than a few hundred user per day resulting in very poor "blockspace" usage.  We are left with a puzzle: if Polkadot technology is fundamentally the world's best solution to async/sync patterns at the heart of the state transition function, but embodies complex patterns, how do we
+While Polkadot aims to be a massively scalable map reduce computer, in most cases, developers do NOT need scalability right away -- it is widely recognized that both devs+users find the multichain factorization unnecessarily complex, while technologists know that complexity is required for scalability.  Few parachains have scaled their user base to more than a few hundred user per day, resulting in very poor "blockspace" usage.  We are left with a puzzle: if Polkadot technology is fundamentally the world's best solution to async/sync patterns at the heart of the state transition function, but embodies complex patterns, how do we give developers an on-ramp?
 
-[Hybrid Chains](https://www.rob.tech/blog/hybrid-chains/) provide the answer:
+Rob Habermerier's [Hybrid Chains](https://www.rob.tech/blog/hybrid-chains/) provide the answer:
 
 ![](https://europe1.discourse-cdn.com/standard21/uploads/polkadot2/original/2X/7/7cca3339cc4eb1ab3971d6fe10280d4469510ea3.png)
 
-"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."  
-
-By adding Smart Contracts to the Kusama Relay Chain, developers can scale from sync-first "old" blockchain technology to "new":
+By adding Smart Contracts to the Kusama Relay Chain, developers can scale from sync-first "old" blockchain technology to "new" in this spectrum:
 
 1. full sync patterns in Smart Contracts on the Relay Chain.  _This pattern is manifested in Ethereum but has never been seen in Polkadot or Kusama._
 2. full sync patterns in Smart Contracts on a Parachain.  _This pattern is seen in Astar + Moonbeam._
@@ -39,26 +37,25 @@ By adding Smart Contracts to the Kusama Relay Chain, developers can scale from s
 5. hybrid sync + async patterns in CoreJam + CorePlay.  _This pattern is under active development and will appear in Kusama 2.0 + Polkadot 2.0._
 6. hybrid sync + async patterns in Substrate Pallets.  _This pattern is seen in all other parachains._
 
-Developers should be able to _start_ at any point in the above spectrum and move upwards as their needs for scale increase, culminating in CoreJam/CorePlay.
+Developers can _start_ at any point in the above spectrum and move upwards as their needs for scale increase, culminating in CoreJam/CorePlay and Substrate pallets in app chains.
 
-For "core" efficiency reasons, it is highly undesirable to load sync patterns (whether Smart Contracts or Substrate pallets) onto the Relay Chain: [RFC #32 Minimal Relay Chain](https://github.com/polkadot-fellows/RFCs/pull/32) takes this the logical extreme, advocating moving Balances, Staking, Identity, Governance off of Polkadot, with Polkadot founder @gavofyork's strong conviction that  "The Relay-chain should do one thing and do it well. That means being the head of a secure decentralised multicore computer. Sticking an EVM smart contract in there and/or continuing to allow end-user-application-level transactions and general interaction goes directly against this mantra."  
+For "core" efficiency reasons, it is highly undesirable to load sync patterns (whether Smart Contracts or Substrate pallets) onto the Relay Chain: [RFC #32 Minimal Relay Chain](https://github.com/polkadot-fellows/RFCs/pull/32) takes this the logical extreme, moving Balances, Staking, Identity, Governance off of Polkadot, with Polkadot founder @gavofyork's strong conviction that  "The Relay-chain should do one thing and do it well.  That means being the head of a secure decentralised multicore computer. Sticking an EVM smart contract in there and/or continuing to allow end-user-application-level transactions and general interaction goes directly against this mantra."  
 
-This proposal takes Kusama 2.0 to the other extreme of Polkadot 2.0, and
+So, this proposal takes Kusama 2.0 to the other extreme of Polkadot 2.0, and
 
-_Elevates Kusama to the level of Ethereum_
+_Elevates Kusama to the level of Ethereum._
 
-By putting EVM Smart Contracts on the Relay Chain, Kusama can simultaneously pursue both leading ecosystem's path to scalability:
+By putting EVM+WASM Smart Contracts on the Relay Chain, Kusama can simultaneously pursue both leading ecosystem's path to scalability:
 
 1. Ethereum: [Scalability from rollups](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) _and_
-2. Polkadot: [CoreJam]() and [Coreplay]().
-
-Developers can program EVM Contracts directly on Kusama just as they do on Ethereum.
+2. Polkadot: [CoreJam](https://github.com/polkadot-fellows/RFCs/pull/31) and [Coreplay](https://github.com/polkadot-fellows/RFCs/blob/gav-coreplay/text/coreplay.md)
 
-Developers can work on EVM L2 Stacks (e.g. OP Stack) that live on top of Kusama instead of Ethereum.  
 
-Developers can work on appchains that does not exist on Ethereum, with highly scalable async+sync patterns.
+* Developers can program EVM Contracts directly on Kusama just as they do on Ethereum.  But not Polkadot.
+* Developers can work on EVM L2 Stacks (e.g. OP Stack) that live on top of Kusama instead of Ethereum.  But not Polkadot.
+* Developers can work on appchains that does not exist on Ethereum, with highly scalable async+sync patterns.  On both Polkadot and Kusama.
+* Developers can work on Corejam/Coreplay that does not exist on Ethereum, with highly scalable async+sync patterns.  On both Polkadot and Kusama.
 
-Developers can work on Corejam/Coreplay that does not exist on Ethereum, with highly scalable async+sync patterns.
 
 ## Stakeholders