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.

The Stellar Blockchain and The Story of the Federated Consensus — Blockchain Academy

2,096 views

Published on

We'll dive deeper into the Federated consensus networks, focusing on Stellar and Ripple,
and discuss how they differ from other popular decentralized consensus solutions such as Proof-of-Work and Proof-of-Stake.

We'll assess their pros and cons, and discuss the business requirements that drive companies to adopt these solutions over others.

Video of the presentation is available here: https://www.youtube.com/watch?v=QSpG6a9bmu0

Related blog post in Blockchain Academy TLV: https://medium.com/kinblog/the-stellar-blockchain-and-the-story-of-the-federated-consensus-blockchain-academy-f332eaadefc1

Published in: Software
  • There are over 16,000 woodworking plans that comes with step-by-step instructions and detailed photos, Click here to take a look ◆◆◆ http://tinyurl.com/yy9yh8fu
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Want to preview some of our plans? You can get 50 Woodworking Plans and a 440-Page "The Art of Woodworking" Book... Absolutely FREE ■■■ http://tinyurl.com/yy9yh8fu
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Video of the presentation can be seen here: https://www.youtube.com/watch?v=QSpG6a9bmu0
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

The Stellar Blockchain and The Story of the Federated Consensus — Blockchain Academy

  1. 1. Blockchain Academy A community for technologists looking to learn more about crypto and Blockchain technology Blockchain AcademyOry Band Aug 13, 2018
  2. 2. Blockchain Academy A community for technologists looking to learn more about crypto and Blockchain technology Blockchain AcademyOry Band Aug 13, 2018 3 Kin - A cryptocurrency that’s out to change how we create, share, and distribute value online. Samsung Next - VC for early stage software startups
  3. 3. The Stellar Blockchain And the story of Federated Consensus Blockchain AcademyOry Band Aug 13, 2018
  4. 4. ● Introduction: Decentralized Consensus ● Requirements: Product, Stellar ● Define: Permissioned Blockchain ● Compare: Permissionless VS Permissioned ● Implementation: Federated Byzantine Agreement ● Ecosystem: Core, Apps
  5. 5. ● Backend Engineer @ Blockchain team @ Kin ● Working on Stellar since end of 2017 ● Kin token sale on Ethereum ○ Smart Contracts: Sale, Vesting, Multisig ● Kin blockchain migration to Stellar ○ Topics: Anti-Spam, Scaling, Swap (Migrate) About Me - http://ory.band
  6. 6. ● Introduction ● Requirements ● Permissioned ● Permissionless vs. Permissioned ● Implementation ● Ecosystem
  7. 7. Consensus?
  8. 8. Consensus means to reach an agreement between multiple components in a system. In the Blockchain industry, It means nodes agreeing on the ledger contents and updates.
  9. 9. Consensus ● Node suggests value “X” ● Other nodes agree on value on value “X” ● A client asks “What is the value?” ● The system answers: “X”
  10. 10. Fault Tolerance
  11. 11. Fault tolerance is a property that enables a system to continue operating properly in the event of a failure In some of its components.
  12. 12. Fault Tolerance ● A node dies ● System can still agree on value “X” ● A client asks “What is the value?” ● The system answers: “X”
  13. 13. Byzantine Fault Tolerance (aka BFT)
  14. 14. Byzantine Fault Tolerance is a fault tolerant system, where there is imperfect information whether a component has failed. Specifically, Components can be unpredictable.
  15. 15. Story: Decentralized Consensus
  16. 16. Centralized
  17. 17. Centralized World ● No collaboration between entities with possible conflicting interest ● Result: Middlemen and fees
  18. 18. Centralized BFT ● Solutions: PBFT, Paxos, Raft ● Owners are predefined ● Usually belong to the same entity ● Result: Systems are centralized
  19. 19. Decentralized Consensus
  20. 20. Nakamoto Consensus - Bitcoin ● Enforce set of rules ● Distributed ● Byzantine Fault Tolerant ● Decentralized ● Result: No middlemen
  21. 21. Additional Features ● No Double-Spend ● Replication, Record Consistency ● Immutability, Integrity ● Transparency, Anonymity, Auditability ● Authorization (Cryptography) ● Permissionless
  22. 22. Permissionless?
  23. 23. In a permissionless blockchain, anyone can join the network, and participate in consensus, without censorship.
  24. 24. Why Permissionless?
  25. 25. Permissionless is not a feature, but a requirement for PoW for achieving decentralized consensus. The larger the network, The more secure it becomes.
  26. 26. Majority Attack - “51%” ● Attacker gains network majority ● Force agreement on malicious content ○ Change history (double-spend) ○ Block new transactions ● Network size decides difficulty ○ Small network = Less resources to attack ○ Large network = More resources
  27. 27. Permissionless is a compromise of PoW, which achieves security while sacrificing other properties.
  28. 28. Compromise ● Scalability - Block size, Rate limiting ● Energy consumption ● Inflexible incentive model - Mining ● “Trend towards centralization” - Miners ○ Pools ○ Politics
  29. 29. Why is it OK for PoW to have this compromise?
  30. 30. What is the product?
  31. 31. Product ● Bitcoin ○ Medium of Exchange - Digital Cash ○ Store of Value ● Ethereum ○ “World Computer” ○ Decentralized App + Contract Platform
  32. 32. These properties require Bitcoin and Ethereum to be inherently permissionless. However, Not all products that can benefit from decentralized consensus require the same thing.
  33. 33. Products do not have to compromise on the same things as Bitcoin and Ethereum. Specifically, the permissionless part.
  34. 34. Stellar
  35. 35. History ● Founded by Jed McCaleb ● eDonkey2000 (eMule) - 2000 ● Mt. Gox - 2010 ● Co-Founded Ripple - 2011
  36. 36. Timeline ● Launch - 2014 ○ Forked from Ripple ● New consensus algorithm - 2015 ● Partnerships - 2016 - 2018 ○ IBM ○ Keybase
  37. 37. Business ● Payment Platform ● Financial Institutions ○ Developing countries ○ Banks, Non-Profits, Microfinance ● Distributed Money Exchange ● ICO Platform
  38. 38. Stellar can benefit from decentralization. However, It mostly requires institutions joining the network.
  39. 39. Introducing Permissioned Decentralized Consensus
  40. 40. In a permissioned blockchain, entities require privilege to join the network and participate in consensus.
  41. 41. Permissioned ● Predefined list of known nodes ● Verified and registered before hand ● A trusts [B, C, D] B trusts [A, C, D] etc. ● Trust is predefined / flexible depending on platform
  42. 42. Let’s Compare
  43. 43. Compare ● Secure the network ○ Low participation cost - no mining / stake ○ Network doesn’t have to be large to be secure ● High scale ○ Low block time ○ High throughput ● Token not required to incentivise consensus ● Flexible incentive model
  44. 44. ● Decentralized Consensus ● Product ● Permissioned ● Permissionless vs. Permissioned ● Implementation ● Ecosystem
  45. 45. Background
  46. 46. Remember Stellar forked from Ripple?
  47. 47. Hard Fork Incident ● Dec. 2014 ● Prioritize ledger closes over everyone agreeing ledger contents. ● Few hours of diverged transactions, eventually rollbacked ● Forced to run network using a single (centralized) node until fixed
  48. 48. FLP Impossibility
  49. 49. Safety, Liveness, Fault Tolerance ● Fault Tolerance ● Agreement (Safety) ● Termination (Liveness) ● Pick 2 out of 3. That’s life.
  50. 50. Ripple + Stellar (before SCP)
  51. 51. Why did this happen?
  52. 52. Stellar vs. Ripple ● Ripple favors Fault Tolerance and Termination ○ Repeat process if no agreement was made ○ High probability. of success ● Stellar favors Fault Tolerance and Agreement ○ Wait until termination
  53. 53. SCP, Apr. 2015
  54. 54. Federated Byzantine Agreement
  55. 55. Properties ● Byzantine Fault Tolerant ● Decentralized Control ● Low Latency ● Flexible Trust ○ Nodes don’t require familiarity with entire network ● Asymptotic Security ○ Majority attack irrelevant
  56. 56. Whitepaper
  57. 57. Whitepaper Definition
  58. 58. SCP whitepaper, David Mazieres, Stellar Development Foundation Each participant knows of others it considers important. It waits for the vast majority of those others to agree on any transaction before considering the transaction settled. In turn, those important participants do not agree to the transaction until the participants they consider important agree as well, and so on. Eventually, enough of the network accepts a transaction that it becomes infeasible for an attacker to roll it back. Only then do any participants consider the transaction settled.
  59. 59. “Considers Important” ?
  60. 60. ● Quorum Slice ○ “Trust group” ○ Open membership - Each node chooses its own slice ○ Can have more than one slice ● Select slices based on reputation or financial arrangement: ○ Business “A”, reputable bank “B”, Credit union “C” ○ “A” requires “B” and “C” to acknowledge all transactions Flexible Trust
  61. 61. ● System-Wide consensus ○ Results from quorum intersections (overlapping) ● No intersection results in disjoint quorum ○ Result: No Consensus Quorum Interestection
  62. 62. Disjoint Quorums Quorum Intersection
  63. 63. ● Construct correct and responsible quorums ● Slices are large enough ● Slice nodes important enough not to risk their reputation Quorum Recommendation
  64. 64. What about bad nodes?
  65. 65. Problem: Befouled Nodes ● Befouled nodes can undermine agreement ● Includes: ○ Faulty nodes ○ Malicious nodes ○ Good nodes entirely surrounded by bad nodes etc. ● Nodes are either “intact” or “befouled” (ill-behaved, faulty)
  66. 66. Solution: Befouled Nodes ● Remove befouled nodes from slices (under reasonable conditions) ● A befouled node cannot undermine agreement, as long as ○ It doesn’t undermine quorum intersection ■ i.e. inconsistent answers ○ It doesn’t undermine intact nodes from a quorum ■ i.e. not answering
  67. 67. Federated Voting
  68. 68. Federated Voting - Steps 1.Vote 2.Accept 3.Confirm
  69. 69. Step 1: Initial Voting ● Votes are preliminary ● Example: PIZZA or HAMBURGER ● Vanessa votes for Hamburger ○ Vote for ACCEPT(HAMBURGER) ■ Meaning: Open to the idea of HAMBURGER as valid option ○ Promise never to vote for options contradicting ACCEPT(HAMBURGER) ● Possible to end up ACCEPT(PIZZA) instead
  70. 70. Vote Blocking
  71. 71. Given node A, with defined quorum slices, A’s v-blocking set is a node set containing at least one node from each of A’s quorum slices
  72. 72. V-Blocking ● Quorum slices influence one another ● Node’s quorum slice can block voting for certain actions
  73. 73. Peer Pressure
  74. 74. Step 2: Accept ● A v-blocking sets prevents Vanessa from voting HAMBURGER, causing her to ACCEPT(PIZZA) instead ● Vanessa ACCEPT(PIZZA) if … ○ Never accepted a statement contradicting PIZZA e.g. ACCEPT(BURRITO) ○ 1 of 2 happens ■ Each quorum votes for ACCEPT(PIZZA) or already ACCEPT(PIZZA) ■ Each member of a v-blocking set ACCEPT(PIZZA) ● Quorum votes the same → ratify ACCEPT(PIZZA)
  75. 75. Accepting is not enough
  76. 76. Step 3: Confirm ● Broadcast ACCEPT(PIZZA) ○ Exchange confirmation messages ● Causes others to ratify and ACCEPT(PIZZA) as well ○ Step 2 / Peer Pressure ● Example: ○ Vanessa and entire quorum broadcasts ACCEPT(PIZZA)
  77. 77. Stellar Consensus Protocol (AKA SCP)
  78. 78. SCP - Protocol 1.Nominate 2.Ballot - Commit
  79. 79. SCP Nominate
  80. 80. SCP - Nominate 1.Produce candidates (transactions) for ledger update 2.Union of transactions submitted 3.Federated Voting on candidates
  81. 81. What happens in case of 50/50?
  82. 82. SCP - Ballot 1.Starts when candidate nominations are confirmed 2.Commit or Abort candidates
  83. 83. There’s always a sequence of events through which intact nodes can reach agreement on and commit a value
  84. 84. Ballot - Neutralization ● Allows for removing disputable arguments ○ Example: ABORT(HAMBURGER) ○ Only PIZZA argument is left
  85. 85. SCP - Summary 1.Nomination: Produce candidate via Federated Voting 2.Ballot: Commit candidate via Federated Voting ○ If a ballot fails → Neutralize → New Ballot ○ Taking care not to contradict previously failed ballots ■ Makes sure new valuable ballots are suggested ○ All disputes can be resolved … ■ … Given enough time and retries
  86. 86. ● Decentralized Consensus ● Requirements ● Permissioned ● Permissionless vs. Permissioned ● Implementation ● Ecosystem
  87. 87. Ecosystem ● Developer Docs ● Core ○ Performance: 1000 TX/s, ~5s Block Time, Network size: ~50 ● DEX - Distributed Exchange ● API Frontend ● Crypto Address - Readable ID (e.g. Email) ● Compliance / KYC / AML
  88. 88. Links ● SCP, Blog Post ● SCP, Youtube (David Mazières) ● BFT + FLP Impossibiliy ● Consensus Models Summary - Dr. Arati Baliga
  89. 89. Summary ● Decentralized Consensus ● Product ● Introduced Stellar ● Permissioned ● Compared Permissionless vs. Permissioned ● FBA, SCP Implementation ● Ecosystem
  90. 90. We’re Hiring ● Backend ● Devops ● Mobile ● Content (Product) ● Design ● careers@kinecosystem.com (LABS, Azrieli Sarona, TLV)
  91. 91. Blockchain AcademyOry Band Aug 13, 2018 Thank You Questions? (Slides + video will be shared in a few days)

×