Today, I’d like to present a plan for Polkadot to consolidate functionality into a single highly-scalable system chain as a hub for users, developers, liquidity, and apps. This system chain would be an evolution of the current AssetHub chain, codenamed “Plaza”, which already has wallet, bridging, and tooling integrations that can be preserved to build momentum.
I am proposing this as an individual participant in Polkadot governance and this post contains only personal opinions.
Concretely, the proposal is to consolidate all the following features into a single system parachain, to be evolved from AssetHub and brought up to the maximum possible scale:
- Asset Issuance [Currently on AssetHub]
- Smart Contracts (Rust and EVM via RISC-V/PolkaVM) [Proposed in https://polkadot.polkassembly.io/referenda/885]
- Staking [Currently on the Relay Chain]
- Bridging Pallets [Currently on the BridgeHub parachain]
- Near-zero fees (until scaling limits are reached)
I refer to this chain with the codename “Plaza” from here on out.
The current trend of Polkadot is to split these functionalities across several different chains, and for wallets, applications, and users to coordinate their activities across these chains. This approach has come with real costs, without a current driving scaling pressure to merit this level of fragmentation.
Essentially, we should be strategic and concentrate hard on usability now that we’ve laid the groundwork for scalability. There are two ways to do this. Option 1 is the status quo: we spend a lot of money and time to build the best asynchronous composability framework possible and hope this is easy enough to compete with synchronous systems once it is done. Option 2 is to focus scaling resources and energy on building a synchronous system which we know will have scaling limits and let organic scaling pressures lead the way once those limits are saturated. This post is focused on “Option 2”.
Polkadot will soon have Elastic Scaling, where a single chain will be able to use a large number of cores to process transactions - logically sequential, synchronously composable, and validated in parallel across many cores. I believe we should use this to our advantage to create a “hub” to focus UX, integration, and developer efforts on, and we should lay the groundwork for this today. We can scale this chain to thousands of TPS today and much further over time. The scaling limits of a single chain are going to be saturated, very conservatively, with tens of millions of daily users.
Smart contract support is absolutely crucial. Assets, staking, bridging, and apps benefit from generalizable programmability. This is lacking in the current Polkadot landscape, with smart contracts often in different chains altogether from the assets or systems they aim to interact with. We can support RISC-V smart contracts via PolkaVM, and with it, gain support for new languages like ink! as well as interpreted EVM.
Here are the specific difficulties the Plaza plan can address. For users, interacting with multiple chains is more complex, requiring them to juggle assets, accounts, and state across several different chains. Wallet and frontend developers have taken on large amounts of work to make this easier, but are still less than perfect. For developers, the time and money costs of building a chain, coordinating a collator set, handling block explorers, indexing, bridging, and exchange integrations add a large amount of overhead against building the products they wish to bring to the world.
These costs are worthwhile and even necessary once the scaling limits of a single chain have been reached, but are a poor trade-off until that point. While many projects do benefit from having their own chain, the long tail of developers and users are both better served by smart contract platforms. Polkadot has enough cores to support chain builders and smart contract builders together.
We should work together as an ecosystem to bring a batteries-included single chain up to its point of bursting and only then relieve the pressure by spinning out apps, users, and system functionality. Polkadot has the cores to support all of this to the level of scale the world needs. The city needs to grow outwards from the center, and that center should be the Plaza.
Although not included in the list of core functionality, there is a case to integrate Polkadot’s identity and governance functionality to the Plaza over time. Tight integration between smart contracts, assets, identity, and governance enables powerful scripting and automation primitives to enhance these systems and broaden their usage and could be considered for inclusion in the Plaza.
With engineering advances like NOMT, Optimistic Concurrency Control, and ZK Merkle Proving, we can build this “plaza” chain to support hundreds of millions of transactions per day over time. I am not talking about using supercomputer sequencers, but just normal machines with good software engineering. Accessibility for full nodes to join the network should remain a priority and we don’t need to compromise on this.
Another element of the Plaza is the potential for value accrual to DOT through transaction ordering priority fees. I have written on twitter recently that I don’t believe trying to sell all the blockspace is the best strategy, particularly because the price of cryptoeconomic compute is bounded-above by the cost of ZK and because Polkadot has been so successful in scaling raw compute. However, not all blockspace is created equal. Oftentimes, having the first transaction in a block is valuable in itself, even when blocks are nowhere near full. This is important: even when blockspace is abundant, the first transaction in a batch is a scarce resource that people will pay for. To take advantage of this, we need synchronous composability and programmability.
One example of this phenomenon is in market making: when the price of an asset moves between blocks, the first transaction often has access to a “free” arbitrage. With high concentrations of liquidity, this arbitrage can be quite large and being the first user to make that trade in each block is a good worth paying for. This race to be first is always the case in financial markets, and presents a viable opportunity for token value accrual, for example, by burning priority fees in part. The story I present here is one where the median fee is near zero but the mean fee is enough to cover the cost of blockspace.
Many of the things I’ve discussed are already being implemented. For example, there is already a proposal underway to reduce existential deposits on AssetHub here and discussions further reductions in fees.
A proposal for PolkaVM/Risc-V contract execution on AssetHub is being voted on here and is ready to be developed.
This proposal is about putting a larger story behind these so-far uncoordinated actions, adding additional changes, and coordinating the ecosystem behind this direction.
Whether this plan is eventually put in motion will depend on the results of a Polkadot Wish-For-Change Referendum to approve the Plaza plan, which includes roughly the following goals:
- To change the name of AssetHub to something that reflects a broader purpose as an ecosystem hub.
- To focus on scaling “Plaza” as far as possible using Polkadot cores and without compromising on full node capabilities.
- To make Plaza a key focus of marketing, DevRel, and developer eduction programs.
- To add contract/scripting capabilities to “Plaza”.
- To reduce the fees on “Plaza” to the minimum possible sustainable quantity.
- To introduce a priority-fee mechanism to “Plaza” as a route to value capture.
Implementing some of these goals will require follow up referendums. Some of them will require fellowship RFCs and technical planning. Some will just require small pull requests.
This post is a precursor to a formal proposal to Polkadot Governance, and is an invitation for discussion, debate, and collaboration, as well as a call to action.
My vision here is that this will be the New York City, Dubai, London, or Shenzhen of the Polkadot continent, the first megacity of many and a precursor to greater expansion. We can implement this plan eagerly, knowing that when the Plaza is saturated Polkadot (or JAM) has the raw validated compute power needed to handle that expansion. Here’s to doing things that don’t scale, but scale far enough to get us to the next era.