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

2. Blockchain Academy
A community for technologists looking to learn more
about crypto and Blockchain technology
Blockchain AcademyOry Band Aug 13, 2018

3. 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

4. The Stellar Blockchain
And the story of Federated Consensus
Blockchain AcademyOry Band Aug 13, 2018

5. ● Introduction: Decentralized Consensus
● Requirements: Product, Stellar
● Define: Permissioned Blockchain
● Compare: Permissionless VS Permissioned
● Implementation: Federated Byzantine Agreement
● Ecosystem: Core, Apps

6. ● 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

7. ● Introduction
● Requirements
● Permissioned
● Permissionless vs. Permissioned
● Implementation
● Ecosystem

8. Consensus?

9. 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.

10. Consensus
● Node suggests value “X”
● Other nodes agree on value on value “X”
● A client asks “What is the value?”
● The system answers: “X”

11. Fault Tolerance

12. Fault tolerance is a property
that enables a system
to continue operating properly
in the event of a failure
In some of its components.

13. Fault Tolerance
● A node dies
● System can still agree on value “X”
● A client asks “What is the value?”
● The system answers: “X”

14. Byzantine Fault Tolerance
(aka BFT)

15. Byzantine Fault Tolerance
is a fault tolerant system,
where there is imperfect information whether
a component has failed.
Specifically,
Components can be unpredictable.

17. Story:
Decentralized Consensus

18. Centralized

19. Centralized World
● No collaboration
between entities with possible
conflicting interest
● Result: Middlemen and fees

20. Centralized BFT
● Solutions: PBFT, Paxos, Raft
● Owners are predefined
● Usually belong to the same entity
● Result: Systems are centralized

21. Decentralized Consensus

22. Nakamoto Consensus - Bitcoin
● Enforce set of rules
● Distributed
● Byzantine Fault Tolerant
● Decentralized
● Result: No middlemen

23. Additional Features
● No Double-Spend
● Replication, Record Consistency
● Immutability, Integrity
● Transparency, Anonymity, Auditability
● Authorization (Cryptography)
● Permissionless

24. Permissionless?

25. In a permissionless blockchain,
anyone can join the network,
and participate in consensus,
without censorship.

26. Why Permissionless?

27. Permissionless is not a feature,
but a requirement for PoW
for achieving decentralized consensus.
The larger the network,
The more secure it becomes.

28. 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

29. Permissionless is a compromise of PoW,
which achieves security
while sacrificing other properties.

30. Compromise
● Scalability - Block size, Rate limiting
● Energy consumption
● Inflexible incentive model - Mining
● “Trend towards centralization” - Miners
○ Pools
○ Politics

31. Why is it OK for PoW
to have this compromise?

32. What is the product?

33. Product
● Bitcoin
○ Medium of Exchange - Digital Cash
○ Store of Value
● Ethereum
○ “World Computer”
○ Decentralized App + Contract Platform

34. These properties require Bitcoin and Ethereum
to be inherently permissionless.
However,
Not all products that can benefit from
decentralized consensus require the same
thing.

35. Products do not have to compromise on
the same things as Bitcoin and Ethereum.
Specifically, the permissionless part.

36. Stellar

37. History
● Founded by Jed McCaleb
● eDonkey2000 (eMule) - 2000
● Mt. Gox - 2010
● Co-Founded Ripple - 2011

38. Timeline
● Launch - 2014
○ Forked from Ripple
● New consensus algorithm - 2015
● Partnerships - 2016 - 2018
○ IBM
○ Keybase

39. Business
● Payment Platform
● Financial Institutions
○ Developing countries
○ Banks, Non-Profits, Microfinance
● Distributed Money Exchange
● ICO Platform

40. Stellar can benefit from decentralization.
However, It mostly requires
institutions joining the network.

41. Introducing
Permissioned
Decentralized Consensus

42. In a permissioned blockchain,
entities require privilege
to join the network
and participate in consensus.

43. 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

45. Let’s Compare

46. 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

47. ● Decentralized Consensus
● Product
● Permissioned
● Permissionless vs. Permissioned
● Implementation
● Ecosystem

48. Background

49. Remember
Stellar forked from Ripple?

50. 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

51. FLP Impossibility

52. Safety, Liveness, Fault Tolerance
● Fault Tolerance
● Agreement (Safety)
● Termination (Liveness)
● Pick 2 out of 3. That’s life.

53. Ripple + Stellar (before SCP)

54. Why did this happen?

55. 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

56. SCP, Apr. 2015

57. Federated Byzantine Agreement

58. Properties
● Byzantine Fault Tolerant
● Decentralized Control
● Low Latency
● Flexible Trust
○ Nodes don’t require familiarity with entire network
● Asymptotic Security
○ Majority attack irrelevant

59. Whitepaper

60. Whitepaper Definition

61. 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.

62. “Considers Important” ?

63. ● 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

66. ● System-Wide consensus
○ Results from quorum intersections (overlapping)
● No intersection results in disjoint quorum
○ Result: No Consensus
Quorum Interestection

67. Disjoint Quorums Quorum Intersection

68. ● Construct correct and responsible quorums
● Slices are large enough
● Slice nodes important enough not to risk their reputation
Quorum Recommendation

69. What about bad nodes?

70. 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)

71. 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

72. Federated Voting

73. Federated Voting - Steps
1.Vote
2.Accept
3.Confirm

76. 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

77. Vote Blocking

78. 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

79. V-Blocking
● Quorum slices influence one another
● Node’s quorum slice can block voting for certain actions

80. Peer Pressure

81. 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)

82. Accepting is not enough

83. 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)

84. Stellar Consensus Protocol
(AKA SCP)

85. SCP - Protocol
1.Nominate
2.Ballot - Commit

86. SCP
Nominate

87. SCP - Nominate
1.Produce candidates (transactions) for ledger update
2.Union of transactions submitted
3.Federated Voting on candidates

88. What happens in case of 50/50?

89. SCP - Ballot
1.Starts when candidate nominations are confirmed
2.Commit or Abort candidates

90. There’s always a sequence of events
through which intact nodes
can reach agreement on
and commit a value

91. Ballot - Neutralization
● Allows for removing disputable arguments
○ Example: ABORT(HAMBURGER)
○ Only PIZZA argument is left

92. 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

93. ● Decentralized Consensus
● Requirements
● Permissioned
● Permissionless vs. Permissioned
● Implementation
● Ecosystem

94. 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

96. Links
● SCP, Blog Post
● SCP, Youtube (David Mazières)
● BFT + FLP Impossibiliy
● Consensus Models Summary - Dr. Arati Baliga

97. Summary
● Decentralized Consensus
● Product
● Introduced Stellar
● Permissioned
● Compared Permissionless vs. Permissioned
● FBA, SCP Implementation
● Ecosystem

98. We’re Hiring
● Backend
● Devops
● Mobile
● Content (Product)
● Design
● careers@kinecosystem.com (LABS, Azrieli Sarona, TLV)

99. Blockchain AcademyOry Band Aug 13, 2018
Thank You
Questions?
(Slides + video will be shared in a few days)