---
title: Entering New Perspectives
tags: Polkadot
description: Gavin Woods presentation at Polkadot Decoded 2023
type: slide
---
## A New Perspective on Polkadot
### Gavin Wood
#### `@gavofyork`
https://hackmd.io/@polkadot/Decoded2023
---
## 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)
<div style="text-align: right">→ time</div>
---
### Dumb Core Usage (Affinity Unimportant)
<div style="text-align: right">→ time</div>
---
# Agile Core Usage
### Exotic Scheduling
---
## Ranges can be Split
Owners of a range can split and trade.
<div style="text-align: right">→ time</div>
---
## Ranges can be Strided
Chains can take turns on a core to share cost.
<div style="text-align: right">→ time</div>
---
## Cores can be Compressed
Verify many blocks on a core to allow higher block rates and lower apparent latency.
<div style="text-align: right">→ time</div>
---
## Cores can be Combined
Use multiple cores for greater compute power; either a instantaneously or longer-term.
<div style="text-align: right">→ time</div>
---
## Possible Future Directions
Chains share a core to share costs with no reduction in latency
<div style="text-align: right">→ time</div>
---
## Possible Future Directions
Putting it all together
<div style="text-align: right">→ time</div>
---
# 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.
---
# Remember Why
Google Drive
Gist
Clipboard
Sign in with Wallet
