owned this note changed 2 years ago
Linked with GitHub

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)

→ time

Dumb Core Usage (Affinity Unimportant)

→ time

Agile Core Usage

Exotic Scheduling


Ranges can be Split

Owners of a range can split and trade.

→ time

Ranges can be Strided

Chains can take turns on a core to share cost.

→ time

Cores can be Compressed

Verify many blocks on a core to allow higher block rates and lower apparent latency.

→ time

Cores can be Combined

Use multiple cores for greater compute power; either a instantaneously or longer-term.

→ time

Possible Future Directions

Chains share a core to share costs with no reduction in latency

→ time

Possible Future Directions

Putting it all together

→ time

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

Select a repo