## 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