Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Introduction to Blockchain Governance Models


Published on

The presentation on the history and emergence of distributed consensus and the contemporary aspects of Blockchain Governance presented for the Global FinTech and Blockchain Forum organised by Pyramid Learning Platforms.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Introduction to Blockchain Governance Models

  1. 1. SUCCESS BUSINESS Date: 31st January 2019, Courtyard by Marriot Bangalore GLOBAL FINTECH & BLOCKCHAIN FORUM 2019
  2. 2. Slide Engage Educate Excel Blockchain Governance Building Simple, Secure, Scalable Distributed Ledgers 1 •Agenda •Blockchain Design Principles •Blockchain Security Best Practices •Blockchain Scalability Approaches •Blockchain Governance Architectures
  3. 3. Blockchain Simplicity Need for first principles approach
  4. 4. Slide Engage Educate Excel Blockchain Design Principles •Blockchain is a distributed ledger system •As it is distributed across all of the nodes, “blockchain technology” is often swapped with “distributed ledger technology” •As it is distributed across all the nodes, distributed consensus algorithms come to the prominence 2
  5. 5. Blockchain Information Architecture The essential power of Blockchain technology is its ability to distribute information
  6. 6. Blockchain Database Properties A blockchain’s database is not held in a single location
  7. 7. Blockchain as a self auditing system The blockchain network automatically verifies itself at certain intervals, creating a self- auditing system that guarantees the accuracy of the data it holds.
  8. 8. Why is it called a Blockchain ? The group of data automatically verified in a defined interval is called blocks. These blocks are cryptographically chained together, making them hard to manipulate. Altering any piece of data on the Blockchain would require a huge amount of computing power.
  9. 9. A Mutual distributed ledger ! An idea dating back to 1976, published by Diffie and Hellman in the paper ‘New Directions in Cryptography’ A ledger is an invention of the Italian Renaissance originally developed to support double-entry book keeping.
  10. 10. Fault Tolerant Algorithms The algorithms that maintain ledgers must be fault tolerant, ensuring the ledger remains secure even if some parties misbehave, whether accidentally or maliciously
  11. 11. Wait Free synchronisation Universal Construction for lock free data structures Wait free implementation of a concurrent data object is one that can guarantee that any process can complete any operation in finite number of steps Constructing a wait free implementation of one data object from another lies at the heart of much recent work in concurrent algorithms, concurrent data structures, and multiprocess architectures
  12. 12. Wait Free synchronisation •An in-memory table where concurrent data from multiple channels are indexed for retrieval •Using a lock to synchronise concurrent access to the table •Every now and then, the thread holding the lock would take a page fault or a scheduling interrupt •Thus the concurrent data is inaccessible for long •Need for eliminating lock based vulnerabilities
  13. 13. Lock Free data structure implementation Approach •Implementation of a ledger as a LinkedList •Each list entry includes the data and the link to the entry before it •When the data arrives, it is placed in a shared pool •A set of dedicated threads, collectively run a repeated protocol called consensus •This is to select which data gets appended to the ledger
  14. 14. Consensus Problem • A set of processes each start with an input value from some domain D and communicate with each other by applying operations on shared objects. They must eventually agree on a common input value and halt. • A consensus protocol is required to be • Valid: common decision value was an input value • Consistent: never decided on distinct values • Wait-free: finite number of steps
  15. 15. Consensus protocol • Each thread creates a list entry • Then calls a compare and swap instruction • This attempts to make the entry the new head of the list
  16. 16. Querying the Blockchain • A thread scans the linked list ledger • To add a new block, a thread adds a new block to the shared pool • Then waits for the threads to append it to the ledger
  17. 17. Consensus Models • A consensus protocol involves a collection of parties, some of whom are honest, and follow the protocol, and some of whom are dishonest, and may depart from the protocol for any reason. • Crash failure is when dishonest parties might simply halt arbitrarily • Byzantine Failure is when some dishonest parties behave maliciously
  18. 18. Consensus Outcomes • Agreement : all honest parties agree on which transaction was selected • Termination : all honest parties eventually learn the selected transaction • Validity : The selected transaction was actually proposed by some party
  19. 19. Ledgers and consensus • As ledgers are long lived, they require the ability to do repeated consensus to append the stream of transactions to the ledger • Consensus is usually organised in discrete rounds, where parties start round r+1 after round r is complete
  20. 20. Advantages of Blockchain Approach for the wait synchronisation • It is universal: it can be implemented for any type of data structure • All questions of concurrency and fault tolerance are compartmentalised in the consensus protocol
  21. 21. Private Blockchain Ledgers •Byzantine fault tolerant consensus protocols are used •It uses several rounds of voting to ensure that data cannot be distorted by a small number of faulty or corrupt nodes or members. At regular intervals the nodes reach consensus on the required data value. •The ordering nodes time stamp the data and hash of the previous data so that any attempt to tamper with the earlier records will be detected when the hashes do not match. •The validating nodes sign the record to establish the authenticity and they append the record to the list of records
  22. 22. Security considerations for Permissioned blockchains Capabilities, Risks
  23. 23. Permissioned Blockchain Capabilities •Distributed Architecture •Consensus validation mechanism •Encryption •Transparency •Administrative risk controls
  24. 24. Permissioned Blockchain Risks •Key management •Software coding errors •Protocol vulnerabilities •External data sources •End point risks •Identity based attacks •Evolving attack vectors
  25. 25. Blockchain Security Methods •Identity Protection •Data Protection •Device Protection •Transaction Anonymity •Entitlements
  26. 26. Blockchain Security Aspects •Content security •Cloud security •Network security •Device security •Data security •Data governance
  27. 27. Blockchain Security Architecture Considerations •System archiecture •Layers and tiers •On chain and off chain components •Type of ledger access control •Type of consensus protocol •Stakeholders
  28. 28. Blockchain Trilemma
  29. 29. Blockchain Best Practices •Secure today does not mean secure tomorrow •Never store large files on Blockchain •If you don’t want the data to be be public, use a permissioned blockchain •Create a governance structure for the blockchain •Decide on performance and scalability requirements
  30. 30. Blockchain Success Factors •Digital Business Models •Convergence of Blockchain and Messaging Technologies •Increasing use and importance of cloud based services
  31. 31. Enterprise Blockchain Roadmap •Choose a platform •Start experimenting •Get security and scalability right •Build a legal framework for engagement •Set up smart contracts •Understand value exchange and gamification •Model out network ecosystems
  32. 32. . •Assurance •Users need to be assured that blockchain will keep their data protected •Timing •Users should be notified that average Blockchain transaction takes longer than the centralised networks and databases. It is important to get their feedback •Hashes •Enable users to copy the hash in the easiest way possible •Password •Losing private key could be a serious issue in mainstream blockchain platforms. Let the users be aware of this constraint.
  33. 33. Blockchain Scalability : Factors and Constraints •Size of transactions •Size of a block •How many transactions in a block •How often blocks get added to the chain •How nodes collaborate in the chain •How nodes add transactions to the chain
  34. 34. Blockchain Scalability Approaches •Off chain computations •Side chains •State Channels •Sharding Protocols •New Consensus Protocols •Reducing the Block size
  35. 35. Blockchain Scalability Measures and Metrics •Maximum throughput •Rate at which the blockchain can confirm transactions •Latency •Time for the transaction to be confirmed •Bootstrap time •The time it takes for a new computer node to download the history to validate a new transaction
  36. 36. Blockchain Scalability Dimensions •Node identity management •Consensus finality •Node scalability •Client scalability •Performance throughput •Performance latency •Power consumption •Tolerated power of an adversary •Network synchrony •Correctness proofs
  37. 37. Blockchain Governance Elements and Factors •Consensus •Incentives •Information •Structure
  38. 38. Blockchain Governance ModeLs •On-chain Governance •Bitcoin, Ethereum, IOTA •Off-chain Governance •EOS, Tezos, Dfinity, Decred •Cross-Chain Governance •Cosmos, Interledger, Arky •Meta-Chain Governance •Loom, IOTA, Hedera Hashgraph •Micro-Chain Governance •Lightning Network, Plasma, Raiden
  39. 39. Governance Models Best Practices •In cross chain projects, multiple governance models can be used •Malign changes are inevitable; thus having a roll back process in place is crucial •A Blockchain token is very useful in incentivising good behaviour •Liquid democracy can prevent voting centralisation but still includes many votes •Governance models can be improved through algorithmic decisions •Requirement based governance is useful for refining the governance model •Governance models can range from zero to full automation and have all kind of variations in between •Governance models can start as off-chain and move on-chain over time •Off chain governance model can be complex
  40. 40. Thank you !