Polkadot

Reference: Berlin Parity Ethereum https://www.youtube.com/watch?v=gbXEcNTgNco
- Polkadot Core Properties
  - Extensibility / Flexible / Modularity
    - Polkadot is system designed to allow differently designed parts to be introduced at later stages (i.e. different future Consensus Architectures)
    - Polkadot Protocol updatable with first class citizens the outcomes of discovering more interesting, performant and effective means of forming Consensus that achieve solutions we want blockchain to deliver
  - Scalability
    - Scalability over next 10 years
    - Parachains (Parallelised Chains) whereby Parallelising transactions (run multiple chains in parallel) across the network
  - Heteregenality
    - Polkadot allows each part blockchain that is running in parallel to be fundamentally differently kind of design (i.e. some like Bitcoin, some like Ethereum, etc)
    - Homogenous Shards (problem space i.e. db) are split up into equal bits from same cloth
- Polkadot Services Provided (to its Community of Constituants/Users)
  - Pooled Security (Free)
    - Checks and guarantees Validity of transactions in your Parachain against Consensus Protocol Rules (Rules) equally secure for all Constituant member chains of Polkadot Community implementing the Parachain (under the Polkadot Protocol)
      - Rules
        
        Bitcoin (original blockchain, a currency)
        
        Removing and increasing value of equal and opposite amount script
        
        Ethereum
        
        Turing Complete scripting language
    - Polkadot allows arbitrary Rules decidable at a later time, with different Rules for different parts of the system of Parachains
  - Trust-free Transactions/Interactions Relaying (Free)
    - Interactive chains leveraging Parallelism so Constituent Chains may send transactions to each other (instead of many isolated chains having to go through a Decentralised Exchange (DEX) or Intermediary)
- Polkadot Functionality (how it works)
  - Relay-Chain
    - Connected to all Parachains and shuffles transactions around between them
    - Relays transactions at top-level by coordinating Consensus and transaction delivery between Constituents
    - Facilitates Finalisation of transactions since cannot shuffle messages from transactions onto other Parachains unless know the source transaction (comprising the message) is definately Final (otherwise must revert an entire dependency graph)
      - Loosely ties the Finality together by using Validation Function
        
        Finality (i.e. where if two mutually exclusive and equally valid transactions to pay out, only want one to go through
    - Fees levied to Parachains for management of voting, moving staking tokens between Parachains
    - Governance Structure for movement in correct direction with mechanism to deliver stability in real world (i.e. like existing political structure, bi-cameral/multi-role with referendum mechanism built-in so stakeholders have final say)
    - No other functionality (not accept any external transactions, does not host smart contracts)
  - Parachains
    - Parachains are governed by Validation functions but their Finality is determined by Relay-Chain (give up their minor sovereignty of determining their own Finality for increased ability to gether and process transactions)
    - Retain sovereignty of determining their own Validity
- Polkadot Consensus (forming)
  - Relay-Chain Proof-of-Stake System
    - Guarantees shared canonicality o Parachains
    - Structured state machine performing several BFT Consensus’ in parallel such that as the state machine progresses it converges on a solution but solution is not just a single block (from many valid candidates) since validity of candidate blocks occurs over multiple dimensions, where each Parachain is a dimension, so the validity of candidates is determined by Validity and Availability of transactions being processed on a Parachain that all the Validators vote upon using particular Rules mentioned in the Polkadot Paper of turning votes into alternate Consensus)
  - Structured State Machine
    - In R&D not yet finalised (PBFT-derivative likely)
      - Practical Byzantine Fault Tolerance (PBFT) https://en.wikipedia.org/wiki/Byzantine_fault_tolerance
  - Parallel Validation Groups
    - Validation and Consensus-forming canonicalisation is partitioned to allow scaling and occur in Parallel and at end they all sign-off on Final amalgum of the Parachain State Transitions
  - Approval Voting System Group for Nominators and Validators
    - Approval voting system for Nominators and Validators
      - i.e. Validators may say will vote for themself
      - i.e. Nominators may say they will vote for x, y, z Validators
    - Group Membership requires input of staking tokens to bond into the group
      - Removal from group takes 3 months since is timeframe where may still perform malicious actions on the network (short- and long-range attacks)
  - Approval Voting
    - Vote/Nominate for single or multiple Validators deemed acceptable
  - Constraint Optimiser
    - Configuration of Validators/Nominators for best fitting together using Maximum Lowest-Bonded, Minimum Total Inflation so everyone votes for someone else they actually approve of so choose the one with the most votes
  - Adaptive Rewards and Desired Level of Security
    - Rewards alter to target % of capital bonded
      - Set target % that we want to be bonded, for instance want 50% of staking capital in the system to be utilised (bonded)
      - Target reflects the security guarantees of the system
      - Target could be potentially removed from Validators upon misbehaviour (i.e. voting together for something bad/invalid)
    - Set Target for what Bonds we want to reach
    - Increasing/Decreasing Inflation through a market mechanism through the Approval Voting and the Contraint Optimiser to ensure have desired level of security (dynamical system with governance to determine values that make it work)
    - Bonds are used to pay for anything that could be broken
- Relaying Transactions
  - Peer-to-peer
    - Ensure outgoing transactions from a Parachain reach their destination
    - Validators and Collators self-organise to arrange delivery of data
    - Logistics of Delivering Data
      - Obtain data from Parachain wishing to send messages
      - Transfer message data to destination Parachain bound for using Network Protocol ensuring Destination Validators (for the next block) can connect to the Source Validators (for the previous block) and arrange the transfer, where the Consensus Mechanism can only go from previous block to the next block if the Destination Validators agree they have all info they need (i.e. both Available and Valid) to enact Incoming messages
  - Tries and Proofs
    - Ensure trust-free transactions whereby organiser of Relaying transactions behaves accurately and do not arbitrarily drop or include new (i.e. their own) transactions (bad since destination would believe it happened in source chain when it did not)
    - Tries used to encode Ingress/Egress queues, allowing compact Proofs of Misbehaviour
  - Merkel Trees
    - Allow us to state that Leaf X is part of Tree if root is Y
    - Validators must agree on the root
      - If Validator agrees on Invalid root, we can prove it if we calculate that Input plus block transitions equal these Output roots, but does not agree with what they voted on
      - Punish Validators that agree on some eventual delivery that is deemed invalid, but does not deliver the data
    - State transition that happens with full knowledge of different Parachains at a point in the Consensus Process
- Polkadot Diagram
  - Relay-Chain
    - Parachains
      - shown on each of 7x sides with posted transactions (messages) between the Parachains
    - Maintainers
      - Validators is triangles
        
        Police the system, deployed often to different Parachains, Verify/sign-off witness statement that system parts are ok and transactions valid, Finalise Parachain PoV candidates into blocks
        
        Not specific to any Parachain, they float around, are instructed as to what Parachain to Validate at a time, randomly assigned changing every 1, 10, or 16 blocks
        
        aka Light-Client mechanisms built into Validation Function that is part of the Relay Chain (with no synchronisation with any Parachain), that take PoV blocks, verify they are correct (in legacy blockchain terminology)
        
        Note: When adding a Parachain you add a Validation Function (like a Lite-Client mechanism for the Parachain allowing Validators to take the PoV block candidate and confirm as Yes valid or No invalid and throw out
        
        Incentive Rewarded for work without cheating
      - Nominators (similar to Miners)
        
        Passively oversee Validators and fund sound Validators with staking tokens
        
        Incentive Rewarded for work without cheating
      - Blocks Properties to be Valid in Parachains
        
        Note: Parachain blocks may only become canonical when the transactions are Available to any of the Validators (whose job it is to ensure the data/transactions is available)
        
        Availability and Punishments
        
        Validators must confirm that External block data/transactions are Available as part of Consensus Mechanism
        
        Collators must report to Validators if data/transactions associated with External block is Not Available or nonsense
        
        Ensuring Availability is difficult since data is split between many (i.e. 150) different closely bonded Validators (Stakeholders/Actors) that interact with each other and sign-off on Availability of data guarantees for Consensus.
        
        Forcing all to have all data it does not scale
        
        Individually handing out data makes hard to check if any behaving maliciously (invalid data or not having data so not able to reproduce it) Instead we rely on Collators (since may be many and do not need interact with each other), but we do not want to bond Collators, so Collators need ability to police the Availability of data on their Parachain, and count on them even if they’re not paid well
        
        Proof-of-Collator where registered collators can challege data availability
        
        i.e. Validators assigned to a specific Parachain, which has important Incoming transactions (external data) to compute block of Parachain (i.e. classic Ethereum/Bitcoin, etc) so must be Available, and Validators agree to make it Available, but unfortunately not all Validators, only a few (otherwise all need data and not easily scalable). Blockchains are deterministic so need all Inputs to process into all Outputs But since have many Collators for block who may obtain data, and set of Collators easily identifiable if any blocks signed with their address in the past on the Parachain. If Collator says they can’t get data to sync a chain, we identify them by their address as Collator, Validator then investigates with another Validator (that they are assigned every block to complain to), who is bound to check if they may obtain data from other Validator that promised to make it Available. If cannot get data, they initiate a Tribunal resulting in Mild Punishment of Validator having its bond struck or just reduce its rewards, and if repeat occurence of Complaints from different parts of system their bonds are reduced substantially more, since different Validators assigned each time (if it eventually provides data we do not know if bad validator or just bad network connection). Mass Punishment (entire bond removal) if never provide data (i.e. forgot or never had data)
        
        Fairness
        
        Control Collator Set
        
        Golden Ticket (Mild Reward)
        
        Incentive for Validators to prefer Collators with address close to magic ticket. This approaches Proof of Work without waste of power
        
        1:05:50 ????? Preserves bandwidth, avoiding Validators having to include Proof of Validity with every block, which reduces risk of Sybil attack (reputation subverted by forging identities in p2p network) of someone hosting 1000’s of nodes trying to wash away good Validators and Collators
        
        Golden Ticket is a Polkadot address in every block for each Parachain, and every Collator has a Polkadot address which denotes what Validator/Collator will be treated above all with a shared Reward
        
        (so when Validators come with PoV candidate blocks fed by Collators that are checked as Valid then the one signed by a Collator with block with closest address to ticket wins
        
        Avoids Collators challenging Validators but ensuring a few Collators from last 3000 blocks were behaving correctly (i.e. want to find data and complain if cannot find data)
        
        Validity
        
        Voted on to ensure External data/transactions are real (to prevent instances where block is Finalised, but where its data/transactions are Not Available, then cannot Verify the block in the future, and the State Transition is Invalid too, since its Input data is nonsense).
  - Parachain Community
    - Maintainers
      - Collators
        
        Maintainers of a specific Parachain by looking for transactions, gather/collating a specific Parachain’s transactions into Proof of Validity (PoV) candidate blocks (with all info of Parachain made available), show results of executing blocks, then sufficiently prove to the Validator that transactions are Valid and have Executed Correctly when providing PoV for block (and wait to see if their ticket wins). If their ticket wins and goes in, any transaction fees they collected from creating the PoV candidate block will be paid to them when the PoV candidate blocks become canonical/Finalised
        
        Collators must report to Validators if data/transactions associated with External block is Not Available or nonsense otherwise they cannot continue synchronising their Parachain (which is the only way they obtain transaction fees). This is similar to if Miners on legacy blockchain like Bitcoin or Ethereum produced solution but did not include transactions as part of the block, it would be rejected (both by software, and because without transactions we are unable to change the state to what its meant to be, so may built a block ontop of that block)
        
        aka Full-nodes sitting on the Parachain (in legacy blockchain terminology)
        
        Incentive is Parachain transaction fees for creating PoV candidate blocks
      - Fisherman
        
        Monitor/discover network transactions for bad behaviour
        
        Incentive is proportion of bond of the Validator they take to tribunal and demonstrate behaved badly
  - Parachain Bridge (fake Parachain)
    - Prevents Parachains from just being a Stubs by pretending to be a Parachain with transactions, incoming messages and validatable.
    - Other side of Parachain Bridge is Other Blockchain Network
    - Issue with Parachain Bridges is potential Double-Spend is they do not share Finality (i.e. do not share the Consensus mechanism)
      - Example of Issue:
        
        If Relay Chain comes to Final decision that blocks from Other Blockchain Network are Valid, labels the transaction as canonical and will not be rolled back so allows transaction to transition into the next Blockchain Network, but then the Other Blockchain Network on other side of Parachain Bridge they say no it was not Final and they will go another direction.
      - Solution:
        
        Allow external side-effects to proceed with some security by wait say 1000 blocks (i.e. 1 hr to 1 day) and if not reverted label it as fine (what Decentralised Exchanges DEX do)
    - Validation Function checks that blocks from Other Blockchain Network are actually Valid
  - Second-Order Relay Chain
    - In 2nd phase of Polkadot Protocol R&D scalability
    - Appears like a Parachain but works like a Relay-Chain (with its own Parachains on its sides)
  - Closed vs Open Parachains
    - Open Parachains
      - Previously discussed mechanisms ensuring security of Open Parachains
    - Closed Parachains
      - Same as Open Parachain Mechanism toward overarching Finalisation and Consensus Mechanism
      - BUT DO NOT allow PoV to execute transactions and ensuring they end up at expected result as part of Validation Function
      - INSTEAD whilst Validation Function still Validates, it uses Mechanism of only checking that a transactions signatories are valid and signed-off by set of Authorities and that message is being delivered (i.e. Stakeholders from other chain or consortium of named Authorities), it opens opportunity to Encrypting the contents of the State, since no longer need to know the State, Inputs, Outputs (since no longer executing transactions)
      - Allows inclusion of Consortiums, Private Chains, and Internal Chains into the Polkadot Community able to interact with Public and Open Chains
      - Allows trust-less services to get on Public and Open Chains
  - Bridge Chains (opposite diagonal of matrix)
    - Retain the Validation portion, has PoV block to check the transaction works properly
    - BUT IGNORES the canonicalisation
    - Useful for:
      - Incorporating existing Legacy Chains into Polkadot Community of Parachains
      - Extensible Parachains (where insufficient freedom within Standard Parachain Validity Function Architecture) offering additional freedoms in terms of Technical Development made possible if allowed their own canonicalisation mechanism
- Questions
  - In relation to Constraint Optimiser, what does Maximum Lowest-Bonded, Minimum Total Inflation mean?
  - Are Collators given rewards (from the transaction fees for creating PoV candidate blocks that are Valid and Available) even if tickets submitted to Validators are not winners (i.e. do not become canonical/Finalised)?
  - What is meant by Tries used to encode Ingress/Egress queues, allowing compact Proofs of Misbehaviour?
  - What is Proof-of-Collator where registered collators can challege data availability?
Polkadot Paper Summary
- Non-Core Polkadot framework aspects
  - APIs
  - Bindings
  - Languages
  - Usage
- Architecture
  - Existing Blockchain
    - Problems
      - Extensibility
      - Scalability
        
        Resources spent globally on Processing, Bandwidth, Storage
        
        Existing Current real-world blockchain networks limited to 30 transactions per second due to:
        
        Synchronous Consensus Mechanisms currently require wide timing margins of safety on expected processing time
        
        Slower implementations supported
      - Isolatability
        
        Same framework near-optimally address divergent needs of multiple parties and apps
      - Developability
        
        Performance of development tools including APIs, educational documentation, integrations
      - Governance
        
        Flexibility to evolve and adapt
        
        Leadership Effective Decision Making
        
        Inclusivity
        
        Legitimacy
        
        Transparency
      - Applicability
        
        Technology addresses needs on its own or middleware required to bridge gap to actual applications
      - Lack of Real-world Deployment of Blockchain Utility over fields:
        
        IoT
        
        Finance
        
        Governance
        
        Identity Management
        
        Web Decentralisation
        
        Asset Tracking
      - Affected Systems
        
        Proof of Work (PoW)
        
        Bitcoin
        
        Ethereum
        
        Proof of Stake (PoS)
        
        NXT https://bitcoinmagazine.com/articles/nxt-proof-stake-new-alternative-altcoin-1391226906/
        
        Bitshares https://bitshares.org/technology/delegated-proof-of-stake-consensus/
    - Causes
      - Too Tightly-coupled Consensus Architecture mechanisms (into single unit of the Protocol)
        
        Canonicality
        
        State Transition mechanism using a Shared State-Machine (means for parties to collate and execute transaction) has logic too closely tied
        
        Validity
        
        Agreement between parties on possible valid histories has logic too closely tied
        
        Note: These mechanisms Too Tightly-coupled due to one-size-fits-all Conservatism of bundling together Actors, Apps with different Risk Profiles, Scalability, and Privacy requirements at the expense of Innovation, Performance, and Adaptability
  - New Polkadot Framework for Blockchain (Heterogenous Multi-Chain)
    - In-Situ Core Extensibility
      - Decoupled Consensus Architecture and Compartmentalising
        
        Canonicality
        
        Validity
      - Minimising Functionality to only:
        
        Security
        
        Transport
      - Scalability using Divide-and-Conquer Approach of Scaling Out of its bonded core through Incentivisation:
        
        Security
        
        Transport
        
        Decoupling between the Consensus Architecture and the State-Transition Mechanism to achieve a Scalable Decentralised Compute Platform
        
        Prior Work
        
        Max Kaye
        
        Chain Fibres
        
        Similar Proposals
        
        Systems without Global Coherent State Machine
        
        i.e.
        
        Factom https://www.factom.com/
        
        Built on Bitcoin, applications voting systems, legal applications, medical records
        
        Tangle https://www.iotatoken.com/
        
        Scalable solution since avoids Global State
        
        Canonicality without Validity
        
        Solves smaller problems
        
        Systems with Global Coherent Singleton Machine through Homogeneous Shards
        
        Systems solely targeting Heterogeneity
    - Consensus Systems diversity of types interoperating in Trust-less, Decentralised, with both Open and Closed Networks with Trust-free access to each other
    - Backwards Compatibility of system with pre-existing networks (i.e. Ethereum) improving on blockchain technology serving as base-level component capable of global-commerce levels of:
      - Scalability
        
        Support Modern efficient blockchain implementations
        
        Parity Ethereum Client - processes over 3000 transactions per second
      - Privacy
- Protocol Core
  - Core Description
    - Protocol, Implementation, Network
      - Primary Public Network
        
        Network Protocol
        
        Note: Similar to Bitcoin and Ethereum
        
        License of Protocol
        
        Creative Commons - free and open
        
        License of Code
        
        FLOSS (Free-Libre and Open Source Software License
        
        Contributions from Public Collaborating over Protocol Changes and Upgrades
        
        RFCs System similar to Python Improvement Process
      - Implementation
        
        Parity Polkadot Platform (PPP)
        
        Full Protocol Implementation
        
        API Bindings
        
        General Purpose Blockchain Technology Stack for operation by:
        
        Public Network - superset of Private/Consortium requirements
        
        Private/Consortium (“Permissioned”)
        
        Initial Funding
        
        British Government
  - Proof of Concept (based on core description)
  - Ideas for Directions to Improve
  - Definitions:
    - UXTO - https://medium.com/@ConsenSys/thoughts-on-utxo-by-vitalik-buterin-2bb782c67e53
    - Cosmos - multi-chain system (similar to side-chains)
    - Nakamoto PoW - consensus method
    - Jae Kwon’s Tendermint Algorithm
    - Casper
    - Z-Cash - secure Bitcoin
    - Wasm - Ethereum WebAssembly https://github.com/ewasm
    - Yellow Paper Council - https://github.com/gavofyork/curly-engine

UP TO 2.2.1 IN THE POLKADOT WHITEPAPER

Other Link
- Blockchain
  - https://keepingstock.net/a-dummies-guide-to-polkadot-and-parachains-93708bd90775
  - https://www.youtube.com/watch?v=ygZWhQXZtl4
  - https://www.youtube.com/watch?v=U_LK0t_qaPo
- Ethcore * Parity Client - accessible through web interface * https://www.youtube.com/watch?v=2aI3HXSDFy8 * Dev * https://github.com/paritytech/parity/wiki * https://github.com/paritytech/parity/releases * Parity written in Rust
- BTCRelay (fees)
  - http://btcrelay.org/
- Chain Interoperability
  - https://static1.squarespace.com/static/55f73743e4b051cfcc0b02cf/t/5886800ecd0f68de303349b1/1485209617040/Chain+Interoperability.pdf
- Hyperledger
  - https://www.hyperledger.org/projects/fabric
Parity Passport Process
- https://picops.parity.io/#/
DAO etc https://ethereum.gitbooks.io/frontier-guide/content/contract_democracy.html

Written on June 9, 2017