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

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

Blockchain Academy
A community for technologists looking to learn more
about crypto and Blockchain technology
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

The Stellar Blockchain
And the story of Federated Consensus

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

● 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

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

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.

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

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

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

Byzantine Fault Tolerance
(aka BFT)

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

Story:
Decentralized Consensus

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

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

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

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

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

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

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

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

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

Why is it OK for PoW
to have this compromise?

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

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

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

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

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

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

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

Introducing
Permissioned
Decentralized Consensus

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

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

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

● Decentralized Consensus
● Product
● Permissioned
● Implementation
● Ecosystem

Remember
Stellar forked from Ripple?

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

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

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

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

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.

● 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

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

Disjoint Quorums Quorum Intersection

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

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)

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

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

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

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

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

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)

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)

Stellar Consensus Protocol
(AKA SCP)

SCP - Protocol
1.Nominate
2.Ballot - Commit

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

What happens in case of 50/50?

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

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

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

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

● Requirements
● Permissioned
● Implementation
● Ecosystem

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

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

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

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

Thank You
Questions?
(Slides + video will be shared in a few days)

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

More Related Content

What's hot (20)

Similar to The Stellar Blockchain and The Story of the Federated Consensus — Blockchain Academy (20)

Recently uploaded (20)

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