Additional info on Plaza

# <svg class="" fill="#e6007a" width="23" height="25" viewBox="0 -5 50 45" xmlns="http://www.w3.org/2000/svg"><path d="m21.1695 9.42485c4.4769 0 8.1062-2.10983 8.1062-4.71243s-3.6293-4.71242-8.1062-4.71242c-4.477 0-8.1063 2.10982-8.1063 4.71242s3.6293 4.71243 8.1063 4.71243z"></path><path d="m40.6292 24.3756c-2.3277-1.3674-5.9251.8139-8.1063 4.6636-2.23 3.8497-2.3277 8.0575 0 9.376 2.3277 1.3673 5.8763-.8139 8.1063-4.7125 2.23-3.8008 2.3277-8.0086 0-9.3271z"></path><path d="m21.1695 45c4.4769 0 8.1062-2.1098 8.1062-4.7124s-3.6293-4.7124-8.1062-4.7124c-4.477 0-8.1063 2.1098-8.1063 4.7124s3.6293 4.7124 8.1063 4.7124z"></path><path d="m1.70935 24.3756c-2.327703 1.3185-2.230038 5.5263 0 9.3271 2.23003 3.8986 5.77854 6.0798 8.10624 4.7125 2.32771-1.3185 2.23001-5.5263 0-9.376-2.1812-3.8497-5.77855-6.031-8.10624-4.6636z"></path><path d="m9.82353 6.58455c-2.3277-1.36734-5.87622.81389-8.10625 4.66355-2.230032 3.8497-2.327698 8.0575 0 9.376 2.32769 1.3674 5.92505-.8138 8.10625-4.7124 2.23007-3.8008 2.32767-8.00865 0-9.32715z"></path><path d="m32.5229 6.58455c-2.3277 1.3185-2.23 5.52635 0 9.32715 2.1812 3.8986 5.7786 6.0798 8.1063 4.7124 2.3277-1.3185 2.23-5.5263 0-9.376-2.23-3.84966-5.7786-6.03089-8.1063-4.66355z"></path></svg> Additional info ## CONTEXT ### [Codename "Plaza"](https://www.rob.tech/blog/plaza/) > The city needs to grow outwards from the center, and that center should be the Plaza (= the New York City, Dubai, London, or Shenzhen of the Polkadot continent, the first megacity of many and a precursor to greater expansion) [www.rob.tech/blog/plaza](https://www.rob.tech/blog/plaza/) --- <h3>The State of Polkadot</h3> <ol> <li>1. Scalability Groundwork has been laid for Polkadot's scalable multi chain world</li> <li>2. Polkadot has so-far relatively uncoordinated actions and is fragmented into many chains which create the need for users, apps & wallets to coordinate</li> <li>3. While many projects currently benefit from having their own chain, and despite the hard work of Wallet and Frontend Developers, the long tail of contract developers and users must spend a lot of time, money & effort to coordinate difficult async interaction, juggling composability of assets, accounts and state across a complex multi chain landscape. Developers also have high time & money costs for building chains, like for example coordinating collator sets and handling block explorers, indexing, bridging, exchange integrations and other overhead.</li> <li>4. Those costs are worthwhile and necessary once scaling capabilities are needed</li> <li>5. Even a single chain can use a large number of cores to process transactions, logically sequential, synchronously composable and validated in parallel across many cores utilizing <a href="https://wiki.polkadot.network/docs/learn-elastic-scaling">elastic scaling</a>. It scales to thousands of TPS today and much further over time. Conservatively, even a single chain scales up to tens of millions of daily users.</li> <li>6. But for lack of real users, there is no scaling pressure currently to merit the level of ecosystem fragmentation.</li> <li>7. Ethereum has the largest user base and those could be funneled to Polkadot by migrating beloved and popular ethereum dapps onto polkadot. This can be achieved by giving them the same interfaces and UX while providing cheaper and faster execution layer with additional functionality from polkadot's unique cross-chain interactions like XCM and bridges. Migrating ethereum dapps means migrating their users to the polkadot ecosystem. The biggest problem is user inertia, so the less changes for a users basic journey experience, the better for winning them over.</li> <li>8. As an ecosystem we should work together and use this to our advantage to build a batteries-included single chain "hub" and focus on scaling it up until this single chain system hits its scaling limits. This is helped by providing most value and lowest switching costs for ethereum builders.</li> <li>9. Only when organic pressure reaches the point of bursting, we should relieve the pressure by utilizing multi chain capabilities and spinning out apps, users, and system functionality, which is enabled by easy migration of contracts to dedicated chains in order to save costs. This behavior can already be observed by ethereum dapps migrating to Ethereums Layer 2 solutions today.</li> </ol> <hr> <h3>Crucial Missing Feature: "Smart Contract Capabilities"</h3> Polkadots core features are asset issuance (currently on AssetHub), staking (currently on RelayChain), bridging and apps. They would all benefit from simple generalizable programmability, but smart contracts are currently mostly lacking from the polkadot landscape and often live in different chains altogether from the assets or systems they aim to interact with. Additionally over time, tightening integration with assets, integrating polkadot identity and adding polkadot governance functionality can enhance polkadot by making scripting and automation primitives more powerful and broadening the usage. For example, leveraging smart contract capabilities to allow custom rewards in restaking protocols and permissionless programmable opengov (potentially enabled by tornado core protocol inspired private voting) is one of the many ideas that could turbocharge innovation. <a href="https://www.youtube.com/live/MU7tCyhBU7g?t=2089s"><img src="https://i.imgur.com/roSuozH.jpeg"></a> <hr> <h3>The Plaza</h3> Starting today, the ecosystem should coordinate behind building one single batteries-included highly-scalable Polkadot system chain, to serve as a "hub" for users, developers, liquidity and apps by focusing 100% of resources and energy on strategically concentrating developer efforts to integrate all of Polkadot's core features with: <uL> <li>new "Smart Contract Capabilities"</li> <li>and exceptional UX and overall usability</li> </uL> The long tail of users and developers are both better served by smart contract platforms, but Polkadot actually has enough cores to support both: smart contract builders and chain builders. <hr> <h3>The Plan</h3> <ol> <li>1. Change the name of AssetHub to reflect the broader purpose as an ecosystem hub, as it already has wallet, bridging and tooling integrations</li> <li>2. Make this new "Plaza System Chain" (=former AssetHub) a key focus of marketing, developer relations and developer education programs</li> <li>3. Add synchronous smart contract scripting and execution capabilities (enabled by Rust and EVM via RISC-V/PolkaVM) to the "Plaza System Chain" to gain support for new languages like ink! as well as interpreted EVM languages like solidity and more in the future to turbo charge Polkadots core features via: <ul> <li><a href="https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811">polkaVM (forum post 3811)</a></li> <li><a href="https://forum.polkadot.network/t/contracts-update-solidity-on-polkavm/6949">solidity revive compiler based on polkaVM (forum post 6949)</a></li> <li><a href="https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375">EthRPC (forum post 7375)</a></li> <li><a href="https://polkadot.polkassembly.io/referenda/723">EthRPC (proposal 723)</a></li> <li><a href="https://polkadot.polkassembly.io/referenda/885">evm compatible contracts on AssetHub (proposal 885)</a></li> </ul> </li> <li>4. Create exceptional tooling for supporting existing and new smart contract developers to build on "Plaza System Chain" utilizing all new capabilities </li> <li>5. Reduce "Plaza System Chain" fees to minimum posssible sustainable quantity</li> <li>6. Introduce priority-fee mechanism to "Plaza System Chain" as route to capture value</li> <li>7. Focus on scaling "Plaza System Chain" as far as possible using polkadot cores without compromising full node capabilities</li> </ol> This plan can be implement eagerly, knowing that when the Plaza is saturated, Polkadot (or JAM) has the raw validated compute power needed to handle that expansion. ------------------------------------------------------------------- ## VISION <h3>Developer Experience for Plaza and Jam</h3> <blockquote> Lets Integrate Polkadot into the web3 ecosystem marketing funnel. From a developer experience perspective, we have been in the shadows of Ethereum, Solana and others for too long. Ethereum because they are older and Solana because they have better tooling and UX. Now that we have figured out how to make tech scale, it is time to step out of that shadow and finally up our game and stop piggy backing on outdated tooling from our competitors and build the lighthouses on our shores to begin onramping people to Polkadot, focusing on the Plaza. </blockquote> <hr> <h3>The web3 ecosystem marketing funnel</h3> Over the past decade, web3 has expanded into a vast ecosystem with various blockchain platforms catering to different audiences. Polkadot stands out as the most technically advanced, occupying a crucial position towards the end of the web3 funnel. Sadly, so far the gap between smart contracts and parachains has been too wide, which might have contributed to the many layer 2 solutions around Ethereum. Also smart contract parachains, such as Moonbeam, Astar and others, maybe because the lack of polkadot native tooling or being hidden behind the main Polkadot brand, could not change that trend yet. Ethereum and the EVM is now widely used in the web3 ecosystem and Solidity is the industry standard and widely adopted and supported as the main smart contract language. Smart contract platforms are easier to get started with and cheaper to build & deploy than a parachain, thus Ethereum and other smart contract-based dapp platforms naturally precede Polkadot in the web3 funnel, therefor it is sensible to bridge to Ethereum by adding smart contracts as a first class citizen on Polkadot to attract the large pool of projects for which contracts suffice. Focusing on the "Plaza System Chain" to feature solidity smart contracts will create a place most similar to Ethereum, but with all the upsides of Polkadot and no downside. The PolkaVM integration and EVM/YUL to PolkaVM recompiler (revive) can provide a significant performance improvements over Ethereum or existing Polkadot smart contract execution environments (like Frontier and pallet-contracts) at much lower transaction costs. The revive compiler can also be re-used on top of JAM, which formally defines Layer-0 sync execution at the protocol level via <a href="https://graypaper.com/">JAM graypaper</a>. This could finally open the floodgates and unclog the funnel for users to be able to flood into Polkadot where they can start to leverage the advanced tech stack. It also allows Polkadot to leverage the vast knowledge and tooling around Solidity and the EVM as a starting point to populate the "Plaza System Chain". If built right the light of Polkadot-first developer tooling can serve as a lighthouse on the shore of Polkadot to shine so bright, it will be visible to developers in blockchain ecosystems outside of Polkadot in the web3 funnel, such as Ethereum or Solana. The first light visible in other ecosystems can come from marketing stunts such as integrating Polkadot technology into EVM based tooling like Remix or Hardhat and with this allowing users and developers to familiarize with the benefits of Polkadot from the comfort of their familiar environments. The next logical step for developers from there is to explore the shores of Polkadot and the many additional advanced features and capabilities PolkaVM offers and which didn't exist or weren't feasible on Ethereum. It is therfore important to have exceptional Polkadot first tooling ready to serve as lighthouses and guide users and developers to our shores. -------------------------------------------------------------------   <style> /* Use https://unbounded.polkadot.network/ */ #doc, body { --brightpink: hsla(328, 100%, 55%, 1); --background: #181a1b; --boxes: hsla(328, 100%, 20%, 1); --titles: #e6007a; --text: #ddd; --tablehead: hsla(328, 100%, 30%, 1); --tablecells: hsla(328, 100%, 10%, 1); --tablecells: var(--background); --links: hsla(328, 100%, 55%, 1); --listnumbers: var(--titles); --quotes: #999; } #doc blockquote, .ui-content blockquote { color: var(--quotes) !important; } #doc h1, #doc h2, #doc h3, #doc strong, .ui-content h1, .ui-content h2, .ui-content h3, .ui-content strong { color: var(--titles) !important; letter-spacing: -.02em !important; } body, .ui-view-area, .ui-content, #meta-title-tags > div { background-color: var(--background) !important; } #doc, .ui-content { color: var(--text) !important; } #doc summary, .ui-content summary { cursor: default !important; margin: 0 !important; padding: 0 !important; } #doc details, .ui-content details { background-color: var(--boxes) !important; background-color: var(--background) !important; border-radius: 10px !important; padding-left: 30px; padding-right: 30px; padding-top: 0px; padding-bottom: 0px; margin-top: 0px; margin-bottom: 0px; } #doc summary::marker, .ui-content summary::marker { content: ''; } #doc a, #doc a:hover, .ui-content a, .ui-content a:hover { color: var(--links) !important; } #doc table, .ui-content table { border: 0 !important; background-color: var(--background) !important; } #doc thead { border: 2px solid var(--brightpink) !important; border-radius: 10px !important; border-bottom: 1px solid black !important; } #doc tbody, .ui-content tbody { border: 2px solid var(--brightpink) !important; border-top: 1px solid black !important; } #doc th, .ui-content th { border: 1px solid black !important; background-color: var(--tablehead) !important; } #doc td, .ui-content td { border: 1px solid black !important; background-color: var(--tablecells) !important; } #doc ul, #doc ol, .ui-content ul, .ui-content ol { list-style: none !important; } #doc .marker, .ui-content .marker { color: var(--listnumbers) !important; } #doc ul li::before, .ui-content ul li::before { content: "•"; color: white; display: inline-block; width: 1em; margin-left: -1em } </style>