Summary of Micali's Algorand

1. Algorand: Scaling Byzantine
Agreements for
Cryptocurrencies
Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, Nickolai Zeldovich
MIT CSAIL
SOSP '17
Presented by Andrew Huang

2. The Dream
• Shared Ledger: sequence of organized data
• Readable by All
• Writeable by All
• Tamperproof for all

3. The Dream Infrastructure
How can we implement it?

4. Bitcoin
Communication: Gossip
Main assumption: Honesty Majority of
Compute
Main idea: Consensus via proof of work (PoW)
Problems:
Computational waste
Concentration of power
Scalability
Ambiguity

5. Communication: Gossip
Main assumption: Honesty Majority of Money
Main idea: Byzantine Agreement* (BA*)
Goals:
• Trivial Computation
• True Decentralization
• Finality of Payment
• Scalability
• Security

6. BA Overview
• Handle malicious failures or Adversaries
• Agreement: All participants agree on the same value
• Validity: If proposer is correct, every correct participant agrees on the
value general sends
Challenges:
• Slow
• Players are fixed and known in advance
Solution: BA*

7. Algorand Features (1/4)
• Problem: BA* & Sybil Attack
• Solution: Weighted users
• Users are weighted by the money in
their account
• Algorand can avoid forks and double
spending
• Assumes honest majority of money
P
p_i p_j p_k
$
$/3 $/3 $/3

8. Weighted Users vs Proof of Stake (PoS)
• Both avoid computation of PoW
• Main difference: Ambiguity
• PoS flaw in a nutshell:
• Malicious leader (who assembles new block) can create a fork in the network
• Can be caught (e.g., since two versions of the new block are signed with his
key) => the leader loses his money
• in Algorand
• Weights ensure that the attacker cannot amplify his power by using
pseudonyms
• as long as the attacker controls less than 1/3 of the monetary value of system
• Guarantee that the probability for forks is negligible

9. Algorand Features
(2/4)
• Problem: BA is not scalable
• Solution: BA* uses consensus by
committee
• Randomly select a small set of representatives
from the total set of users
• Committee members will publicly broadcast
messages allowing others to learn agreed-upon
block
• Concerns
• How to randomly choose committee members?
• How to ensure adversary cannot fake being a
committee member?
• How to ensure committee members are not
targeted?

10. Algorand Features (3/4)
• Problem:
• How to randomly choose committee members
• Ensure adversary cannot fake being a committee member
• Solution: Cryptographic sortition
• Users can independently and privately determine if they are chosen
• Sortition will choose users randomly based on their weight
• Randomness comes from publicly known seed

11. Algorand Features (3/4)
• Problem:
• How to randomly choose committee members
• Ensure adversary cannot fake being a committee member
• Solution: Cryptographic sortition
• Users have (pk, sk) Blockchain has a random Seed
• Every user will execute 𝐹𝑠𝑘
• 𝐹𝑠𝑘 𝑆𝑒𝑒𝑑 ⇒ (ℎ𝑎𝑠ℎ 𝒉, 𝑝𝑟𝑜𝑜𝑓 𝝅)
• Algorand will set criteria (based on weight)
• ⇒ If User’s 𝒉 fulfills criteria ⇒ User in committee
• Committee members attach ℎ, 𝜋, pk to messages
• 𝑉𝑒𝑟𝑖𝑓𝑦 𝑆𝑒𝑒𝑑, ℎ, 𝜋, 𝑝𝑘

12. Algorand Features (4/4)
• Problem: Adversary may target a committee member once that
member sends a message
• Solution: Participant replacement
• Committee members only speak once
• Immediately becomes irrelevant to BA*
• BA* avoids any private state
• New committee is elected every step of BA*
• All users can become committee members

13. Overview
• Communicate via gossip
• Each user collects a block of transactions they hear
about
• Algorand will initiate a round starting w/ block proposal
• Create committee using Sortition
• All committee members will propose their block
• Users will wait for a time period to receive blocks
• only keep highest priority block
• All users who received some block will initiate BA* to
reach majority consensus and commit a block

14. BA*
• Goals:
• Safety: All users agree on the same value
• Liveness: The system makes progress
• Assumptions:
• Strong synchrony assumption
• Assumes most honest users can send messages to other users within a known time bound
• This assumption allows the adversary to control the network of a few honest users
• Achieve liveness
• Weak synchrony assumption
• The network can be asynchronous for a long but bounded period of time
• After an asynchrony period (b), the network must be strongly synchronous (s) for a
reasonably long period again for Algorand to ensure safety
• s < b

15. BA*
• Phase 1: Reduction()
• Reach consensus on one of two values,
a proposed block or an empty block
• Phase 2: BinaryBA()
• Reach consensus on either the block
from reduction or an empty block
• Relies on Reduction() to ensure that at
most one-non empty block is passed to
BinaryBA() by all honest users
Reduction()
B1
B2
B3
BinaryBA()
Decide
between
received block
and ∅
𝐵𝑖 || ∅
Bn+1Bn

16. Brief Overview
• Each phase runs in steps
• Phase 1: 2 steps
• Phase 2: 2 – 13 steps
• All users should a block
• Each step calls sortition to create a committee
• Each committee member will broadcast their vote for their block
• Users that receive more than t votes for a block will hold onto that
block
• All users can see messages

17. BA*- Reduction()
• Context: Users have received a
block from block proposal
• Step 1: Each committee member
votes for their block
• All users will see these votes and
tally them up and adopt the
majority or the empty block
• Step 2: Each committee member
votes for their block
Pass on B2
B1
B2
B1
B1
B2
Sees majority vote for B2
Sees majority for B2 Sees no majority
Sees majority for B2 Sees no majority
B2 ∅
B2
∅
B2

18. BA* - BinaryBA()
• Receive a single block from Reduction()
• In examples, assume nonempty block
• We will now choose either the empty
block or the block from reduction
• In synchronous system
• Simple case:
• Step 1: Most committee members send the
same block
• Nodes notice they are passing a large
threshold, they will invoke a special final vote
• Step FINAL: Large threshold of users vote for
the same block and commit to block chain
B2
B2
∅
B2
B2 B2
B2

19. BA* - BinaryBA()
Synchronous system
• Adversary case:
• Step 1: Adversary tells User_A its vote,
and remaining Users nothing
• Other Users timeout
• If chosen for committee, does not adopt
Empty Block, instead times out
• User_A reaches consensus
• Guaranteed to remain in next three steps
• Step 2: Anyone who time’d out will
adopt User_A’s block
• Step N: Continue until special FINAL
round
B2
B2
E
B2
E
B2
TO
TO
TO
B2
B2
B2
NODE A

20. BA* - BinaryBA()
Asynchronous System
Similar scenario:
Step 1: Committee share their votes
• User A hears all the votes and reaches
consensus on Block B
• All other users time out
Step 2: User A votes for B, but everyone
times out a 2nd time
• Time’d out users will adopt empty block E
and gossip to their network
We’ve reached two consensus’s on B and E
E
EB2
B2
B2
TO
TO
TO
NODE A
B2TO
E
E
E
E

21. BinaryBA() - Getting unstuck
Two Groups A, B vote for two different values B and E
• Adversary could control network causing groups to remain split
Solution: 3rd Step Binary Coin

22. BinaryBA() - Getting unstuck
• Committee members will agree on binary value
(coin) from their hash
• Choose the least significant bit of the lowest hash
amongst committee
• Attach coin to messages, as means of reaching
consensus
• As long as enough users observe the same bit,
BinaryBA () will reach consensus in the next iteration
of the loop with Probability ½
• Adversary consistently having lowest hash is
extremely unlikely

23. Evaluation setup
• Deploy prototype on 1,000 EC2 instances
• m4.2xlarge VM’s, 1 Gbps
• Simulate 50 users running Algorand
• 50,000 total users
• 1 MB block
• Cap bandwidth for each process to 20 Mbps
• Each machine is assigned to one of 20 major cities around the world
• Equal share of money for each user
• Maximizes number of messages that a user needs to process

24. Evaluation: Latency
What is the latency for txn?
• Well under a minute
• BTC: 30 min to 16 hr
How does it scale as the number
of users grows?
• Near constant
• Committee size is set to 10K

25. Evaluation: Latency & Throughput
• What throughput can Algorand
achieve in terms of transactions
per second?
• Block Proposal: linear increase
• BA*: close to constant
• Bitcoin
• Commits 1 MByte block/10min
• 6 MBytes of transactions per hour
• Algorand
• 2 MByte block / 22 seconds
• 327 MBytes of transactions per
hour

26. Future Work
• Incentives
• Bitcoin gives miners some BTC
• Cost of joining
• To join Alogrand, users must fetch blocks and their certificates
• Other cryptocurrencies face this problem, but don’t have Algorand’s
throughput
• Forward security
• Adversaries could corrupt users over time

27. Communication: Gossip
Main idea: Byzantine Agreement* (BA*)
Main assumption: Honesty Majority of Money
Advantages:
Trivial Computation
True Decentralization
Finality of Payment
Scalability
Security
CONCLUSION: