Polkadot 1.0
- Functionally complete
- Codebase release imminent
What is Polkadot 1.0?
- A main blockchain ("Relay-chain") with BABE consensus…
- …able to secure other blockchains ("parachains").
What is Polkadot 1.0?
What is Polkadot 1.0?
- Relay-chain includes traditional functionality: token, registry, staking, governance.
- Chains can send messages (XCM used as language)
What is Polkadot 1.0?
- "Slots" for parachains leased in 6 month chunks for up to 2 years.
- Crowdloans allow users to trustlessly loan funds to teams for lease deposits.
- No other means to utilize Polkadot.
The only true voyage of discovery, the only fountain of Eternal Youth, would be not to visit strange lands but to possess other eyes
– Marcel Proust
New Perspective on What Polkadot Is
- Space, not chains.
- Apps, not chains.
- Resilience.
A provider of maximally-resilient, general-purpose continuation computation. The Polkadot Relay-chain is the foundation of the Ubiquitous (Multicore) Supercomputer.
Polkadot: Ubiquitous Supercomputer
- Polkadot Supercomputer comprises many Polkadot Cores.
- Polkadot cores are a lot like regular CPU cores.
- Blockchains secured by using a Polkadot Core are called parachains.
The Polkadot Core
- Polkadot Supercomputer has ~50 cores now.
- Our models suggest this can grow to 500-1,000 cores in the next few years as optimizations are made.
Polkadot Core Performance
The performance of each Polkadot core is:
- Bandwidth: ~1 MiB/s
- Compute: Geekbench 5 SC score ~380
- Latency: 6 seconds
We expect this to track hardware improvements.
Contracts-on-Cores
- Cores can be used to secure not just parachains; "smart contracts" may also be hosted.
- Avoids the need for custom chain infrastructure.
- Effective for contracts with constrained state & I/O (e.g. 2.5 MB) and heavy compute requirements.
What it means…
- Cores are agile; procurement should be agile too.
- Slot auction model not agile: designed for long-term chains.
- Creates high barriers to ecosystem entry; both perceived and real.
- Gifted tinkerers don't launch 😥
A (Possible) Future
Agile Polkadot
Core Rental
A departure from leases & slots
Time on Polkadot cores (Coretime) is sold periodically.
Core Rental
Two Polkadot-native sales of Coretime:
- Bulk: Monthly sale of 4 weeks of Coretime.
- Instantaneous: Ongoing sale of Coretime for immediate usage.
Minimise parameterisation. Maximise agility.
Bulk Sales
4-weekly sale of 4 week Coretime at fixed price.
- Target e.g. 75% of available cores rented in bulk.
- Price adapts depending on deviation from this.
- Unrented cores go to instantaneous market.
- Special considerations for pre-existing tenants.
Instananeous Sales
Blockly sale of bulk Coretime at a spot price.
- Automated market maker regulates price targeting 100% usage.
- Bulk coretime can be placed in this market.
- Total sale revenue split between Coretime providers.
The Nature of Instantaneous Coretime
- Purchased by chains, through collators.
- Boosts transaction throughput.
- Reduces latency (if the para is not permanent).
- Powers a core-contract.
The Nature of Bulk Coretime
Broker para exposes XCM NFT for Bulk Coretime.
- Can be split into multiple NFTs representing smaller periods.
- Can be moved between chains and traded like any other NFTs.
- Can be consumed to allocate corresponding period on a Polkadot core.
Bulk Coretime Usage
Bulk Coretime can be allocated in several ways:
- Assigned to a single paras (similar to a lease).
- Assigned to a number of paras (taking turns on a core).
- Placed on the instantaneous market.
Or just carved up and sold separately OTC.
Bulk Coretime Usage: Rent controls
When assigning a fresh month of bulk Coretime, Broker records price paid and assignment. Coretime can always be purchased next month for same assignment with a capped price change.
Assigning is irreversable.
Meaning for Existing Paras
- Existing leases would continue as usual.
- Bulk pricing initialized by governance.
- My opinion is to start low.
- Floor price, rent controls and RoFR give long-term guarantees on price paid and slot availability.
Meaning for Existing Paras
Parachains need not conform to a fixed period but will have an adaptive period ala CPU clock
- Parachains likely to have "base rate"
- Compress (to reduce latency at the cost of bandwidth)
- Combine (to reduce latency and increase performance with additional core(s))
Meaning for Existing Paras
- More transaction bandwidth when you need it.
- Lower costs when you don't.
- Potential for high performance multicore chains.
- Potential for periodic chains.
- Potential for purely PAYG chains.
- Potential for low-latency chains.
- Longer-term capex planning possible.
Core Usage
Coretime can be sliced and recombined in various ways.
- Split
- Strided
- Compressed
Dumb Core Usage (Long-term Leasing)
Dumb Core Usage (Affinity Unimportant)
Agile Core Usage
Exotic Scheduling
Ranges can be Split
Owners of a range can split and trade.
Ranges can be Strided
Chains can take turns on a core to share cost.
Cores can be Compressed
Verify many blocks on a core to allow higher block rates and lower apparent latency.
Cores can be Combined
Use multiple cores for greater compute power; either a instantaneously or longer-term.
Possible Future Directions
Chains share a core to share costs with no reduction in latency
Possible Future Directions
Putting it all together
Application centric
Not chain centric
Polkadot 1.0:
A Chain Centric Paradigm
- Isolated chains able to exchange messages.
- Similar to bridged sovereign chains.
- Results in UXs isolated to a single chain.
Apps must seamlessly span chains in order to unlock Polkadot's potential
App-centricity is needed
- System chains host apps, not the Relay chain.
- System features span many system chains.
- Apps must span across chains.
- UIs must draw upon many chains.
XCM & Accords
- XCM is a language.
- It abstracts over common functionality in chains.
- Nice chains faithfully interpret XCM.
- No guarantees; not ideal in a trustless env.
In the world of trading…
"A secure trade route, not a framework for binding trade agreements"
XCM
As an intention language, XCM is well-suited when one system trusts another to honour the stated intention.
But when two systems are under the same consensus, we can do better.
Accords
An Accord is an opt-in treaty across many chains.
- Treaty logic cannot be changed or undermined by a chain.
- Faithful execution of treaty guaranteed.
- Specific to a particular function.
- Permissionlessly proposable.
Accords
Polkadot is a unique architecture on which Accords can exist and be capitalized.
They allow patterns of cooperation over multiple chains impossible (or rather, insecure!) in other architectures.
Example Accords
- Asset "hub".
- Multicast XCM router.
- Trustless multi-chain DEX.
Project CAPI: App-centric middleware
- Helps create Polkadot-based apps which span multiple chains.
- Connects to multiple chains at once via multiple light client instances.
Hermit Relay
All user-level functionality moves into system chains.
- Balances
- Staking
- Governance & Identity
- Core rental
Polkadot functionality spans over multiple parachains, freeing up the Relay-chain.
Resilience
Building a Resilient Application Platform
To Build a Resilient World
Resilience
Being delivered by a combination of things:
- Preponderance of light-client usage
- ZK primitives
- Sassafras consensus
- Mixnet/onion-routing
- Social decentralisation
Light-client usage
- Centralised RPCs are too susceptible
- RPC usage is too common
- Smoldot & CAPI allow performance light-client-based UIs
ZK Primitives
High compute time can lead to centralisation.
ZK Primitives
✅ Simpler stuff
- Build a library of richly featured, high-performance ZK primitives.
- First is almost completed, providing privacy for on-chain collectives (including Fellowship).
Sassafras Consensus
New forkless block-production consensus algorithm.
- Improved security & randomness.
- High-performance transaction routing.
- Improved parachain performance & UX.
- Encrypted transactions prevents front-runners.
- Potential MEV benefits.
Internode Mixnet
Shielded transport for short messages.
- Avoids leaking IP information for transactions.
- General messaging system between users, chains and OCWs.
Human decentralisation
As long as we rely on decentralisation, we need to involve many disparate actors to gain resilience.
- Governance (exceptional decisions).
- Spending, salaries, grants, wealth management.
- Collective-expertise and maintenance.
- Oraclisation and administration.