,
25 tweets,
5 min read
Read on Twitter
1/ Algorand was in the news (theblockcrypto.com/tiny/algorand-…) recently. They raised over $60M in token sales at an implied valuation of $24B.
2/ They implemented the Algorand consensus algorithm (dl.acm.org/citation.cfm?i…) to evaluate its performance on 1,000 Amazon EC2 virtual machines, simulating up to 500,000 users.
3/ Experimental results show that Algorand confirms transactions in under a minute and achieves 125 × Bitcoin’s throughput.
4/ In this thread we share practical security implications of Algorand's consensus algorithm based on our analysis.
5/ The core of Algorand uses a Byzantine agreement protocol called BA that scales to many users and is fork-free.
6/ These properties are similar to Storecoin's own BlockFin consensus algorithm (research.storecoin.com/blockfin), so it is interesting to compare the security properties of the two.
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.
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%.
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.
10/ A large number of nodes sounds impressive, but doesn't affect the block approval speed because of the fixed size committee.
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.
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. 
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.
14/ If sufficient number of users with more than 1/3 of the total money collude, they can approve chain forks or double spending.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
