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