STORE compares practical security implications of Algorand's BFT consensus algorithm with BlockfinBFT's.

1/ Algorand was in the news (https://t.co/0YuQV1emmy) recently. They raised over $60M in token sales at an implied valuation of $24B.

— $STORE Engineering (@STOREdevs) June 21, 2019

2/ They implemented the Algorand consensus algorithm (https://t.co/EmM3ergyqe) to evaluate its performance on 1,000 Amazon EC2 virtual machines, simulating up to 500,000 users.

— $STORE Engineering (@STOREdevs) June 21, 2019

3/ Experimental results show that Algorand confirms transactions in under a minute and achieves 125 × Bitcoin’s throughput.

— $STORE Engineering (@STOREdevs) June 21, 2019

4/ In this thread we share practical security implications of Algorand's consensus algorithm based on our analysis.

— $STORE Engineering (@STOREdevs) June 21, 2019

5/ The core of Algorand uses a Byzantine agreement protocol called BA that scales to many users and is fork-free.

— $STORE Engineering (@STOREdevs) June 21, 2019

6/ These properties are similar to Storecoin's own BlockFin consensus algorithm (https://t.co/W3soo3yYIp), so it is interesting to compare the security properties of the two.

— $STORE Engineering (@STOREdevs) June 21, 2019

7/ A key technique in BA is the use of verifiable random functions (VRFs) to randomly select users in a private and non-interactive way. The randomly chosen user proposes the new block.

— $STORE Engineering (@STOREdevs) June 21, 2019

8/ Then a small set of representatives are chosen randomly from the total set of users to form a committee. The proposed block is approved if the committee votes with > 2/3 majority. This threshold itself is a protocol defined parameter and their experiment uses a value of 80%.

— $STORE Engineering (@STOREdevs) June 21, 2019

9/ This means, the proposed block is approved by a committee with a constant membership size, irrespective of the total number of users. In other words, network size doesn't matter.

— $STORE Engineering (@STOREdevs) June 21, 2019

10/ A large number of nodes sounds impressive, but doesn't affect the block approval speed because of the fixed size committee.

— $STORE Engineering (@STOREdevs) June 21, 2019

11/ This also means, Byzantine tolerance is scoped to the committee. If the committee size is 1,000 and the threshold is 80%, the block is approved as long than > 800 users vote for it.

— $STORE Engineering (@STOREdevs) June 21, 2019

12/ The BA protocol is designed to scale to millions of users, as per Algorand's white paper. The probability of finding 200+ Byzantine actors in a random of sample of 1,000 increases as the total number of users increases. pic.twitter.com/O5B7V7r1jX

— $STORE Engineering (@STOREdevs) June 21, 2019

13/ While their Sybil protection with assigning weights to users based on the balance in their accounts serves that purpose, it doesn't address collusion among malicious actors. pic.twitter.com/Ty3UloUMxp

— $STORE Engineering (@STOREdevs) June 21, 2019

14/ If sufficient number of users with more than 1/3 of the total money collude, they can approve chain forks or double spending.

— $STORE Engineering (@STOREdevs) June 21, 2019

15/ The probability of the above happening increases as more number of users exist in the network or a population of users controls large percentage of the total money.

— $STORE Engineering (@STOREdevs) June 21, 2019

16/ The committee selection process is based on the users' weights, which may result in users with large account balances getting selected more often. This in turn incentivizes them to act maliciously, especially if they control more than 2/3 of the total money. pic.twitter.com/XKShBqWVEe

— $STORE Engineering (@STOREdevs) June 21, 2019

17/ Of course, malicious behaviors result in slashing, but the point is that the protocol, by itself, doesn't discourage or prevent such behaviors. External consequences like slashing must be used for adherence to protocol rules.

— $STORE Engineering (@STOREdevs) June 21, 2019

18/ "Strong synchrony" is challenging to achieve in real world environments where nodes (users) are distributed geographically across the globe. A committee of 1,000 users need 950 or more them to be reachable within a known timeout, which is a tall order in real world scenarios. pic.twitter.com/3rCh3RrOs5

— $STORE Engineering (@STOREdevs) June 21, 2019

19/ If the committee cannot agree on the block, the process is repeated with no guarantees of success the next time. The safety is guaranteed only if there is a period of "strong synchrony" of sufficient length, which again, it hard to guarantee in real world scenarios. pic.twitter.com/X0mWz0DoYN

— $STORE Engineering (@STOREdevs) June 21, 2019

20/ When a committee is elected their network characteristics are unknown. The necessary quorum may not be reached if the required number of users are not online or have poor connectivity.

— $STORE Engineering (@STOREdevs) June 21, 2019

21/ Our assertion is that no matter how innovative the consensus algorithms are (VRFs are state of the art), distributed computing related problems will surface sooner or later.

— $STORE Engineering (@STOREdevs) June 21, 2019

22/ If there is an economic incentive to cheat, people do cheat as long as the reward eclipses the penalty. The problem with distributed computing problems or malicious behaviors due to economic incentives is that it is hard to model them and they show up in unexpected places.

— $STORE Engineering (@STOREdevs) June 21, 2019

23/ BlockFin attempts to avoid some of these pitfalls in its design. It doesn't assume strong synchrony. The consensus rounds make progress without repeating the work at the speed of respective nodes.

— $STORE Engineering (@STOREdevs) June 21, 2019

24/ There is no "waste" arising from new committees being formed, who repeatedly try to validate a proposed block, but couldn't do so because of poor synchrony.

— $STORE Engineering (@STOREdevs) June 21, 2019

25/ BlockFin extends Storecoin's "one entity, one vote" governance model to "one entity, one signature" during consensus. The votes are not weighed based on the users' account balance or stake, but purely by their count.

— $STORE Engineering (@STOREdevs) June 21, 2019