Possible Algorand Attack? 'Continuing Attack'

Hello all. I was wondering if Algo is built to withstand the following hypothethical attack: a continuing attack.

When I saw that Algorand works with random committees, that idea really clicked for me. It reminds me of how randomised, blind tests are used in scientific trials to accurately get an impression of the general population. This is especially powerful in a situation where the question asked (what transactions took place?) is not very complex, and the system works if everyone is simply honest.

HOWEVER I must say that I have one misgiving about random trials. It would seem that, if a randomized trial takes place long enough, eventually you will have a committee with a supermajority of dishonest agents if they are mine and I have them be dishonest EVERY. SINGLE. TIME. The Algo security presentation doesn’t really discuss this scenario.

Imagine I hold 20% of all stake. I set up 700/1500 accounts or something along those numbers. Just a large number that is bigger than what I need to overrule a committee. The chance that my bad accounts will ‘rule’ a committee one round is exceedingly small. BUT if I set them to acting dishonestly EVERY. SINGLE. TIME. (like saying 1,000,000,000,000 ALGO should really be in my account), shouldn’t I be able, by simple law of chance, to just have to have committee majority ONE TIME to make this amount of ALGO appear in my account? Like what is the amount of havoc I can cause, or gain to win, from just winning one round?

If this is truly a problem, the solutions I could come up with is a combination of bonding/slashing and multiple rounds, where a committee is formed randomly say, 6 times, and backchecks the previous conclusions. Majority of checks is final. That would increase security massively. With bonding/slashing, I could perform my continous attack theoretically, but lose massive amounts of money by being punished again, and again, and again…

(Of course, if ALGO is built to withstand this hypothethical, do tell. That’d be a relief).

Well… I am not the expert here, but i think it works this way:

  1. The committee is not quite random… If you have account 1,2,3,4,5 there is a randomized function which tells that in the iteration 1, the committee is 1,2 , in iteration 2: 2,4; in itteration 3: 1,5 … and so on… it means that everybody knows every time with which block who will be the committee… the number of assigned account changes, and it also depends on the weight of the balance they represent… So it does not make sense to make 700 accounts, you can have just one big one (or half plus one of the committee size)

  2. Please define what is the bad behavior… by my understanding the only bad thing can be not including transaction to the blockchain… every transaction is signed, so if you would push the transaction with bad signature to the blockchain, you will stop blockchain right next block because next committee will not approve the previous block. Stopping the blockchain is the most worse behavior that someone may do in my opinion. And btw, there is no plan atm what happens if someone bombs (or disconnect) few datacenters where the next huge stake committee members are.

  3. so the real question is, how much stake you must have in order to be selected as the leader of the committee who creates the block, and more then 50% of the committee members who validates the block… and the question is if you have more then for example 30% of all algos if that is in your interest… Also it would be nice to have information how the committee works like how many committee members did not approve the block. i have not seen such stats, but if someone tries to attack the blockchain it shall be this

  4. btw, if someone is harmfull and does not include the block to the blockchain, i believe it might be included in the next block … instead of 4 seconds there would be 8 seconds, which is still quite good, and the harmfull committee leader would get exposed (i have not seen also stats how many blocks may have been included in the block but they have not been because of the decision of someone on the blockchain)

1 Like

Thanks for your answer. I’m not sure if a block added to the chain can be reverted in Algorand, didn’t really see that. But I do see that Algo has multiple rounds of voting built in, which is good.

‘so the real question is, how much stake you must have in order to be selected as the leader of the committee who creates the block, and more then 50% of the committee members who validates the block…’

Yeah so what I was wondering is, if I can get a block in the chain where it’s said that I own 1 trillion or 20 % extra Algorand now, whatever, can anyone stop me or revert that block once it’s in? If I own 10% or even 5% of ALGO, and I just keep spamming bad behavior for a year or more, is it really impossible for me to dominate a couple voting rounds every once in a while?

‘and the question is if you have more then for example 30% of all algos if that is in your interest…’
If you’re a purely malicious government or terrorist group, then perhaps!

Please read this paper of Prof Micali from 2017: Algorand: Scaling Byzantine Agreements for Cryptocurrencies

2 Likes

‘as long as the attacker controls less than 1/3 of the monetary value,
Algorand can guarantee that the probability for forks is negligible. Algorand may be extended to “detect and punish malicious users, but this is not required to prevent forks or double spending.’

It would still be good to have hard number on ‘negligible’ probability of forks in different scenarios. Rules of chance are, if you continue long enough, it’ll happen. If I control 20% of ALGO and have to overrule say 4 rounds of voting, that seems like something that would happen in time if I attack long enough continually. But maybe I misread something.

‘Algorand achieves safety with a “weak synchrony” assumption: the network can be asynchronous (i.e., entirely
controlled by the adversary) for a long but bounded period
of time (e.g., at most 1 day or 1 week). After an asynchrony
period, the network must be strongly synchronous for a reasonably long period again (e.g., a few hours or a day) for
Algorand to ensure safety. More formally, the weak synchrony assumption is that in every period of length b (think
of b as a day or a week), there must be a strongly synchronous
period of length s < b (an s of a few hours suffices).’

Ah, I think this is the answer I was looking for. Ty.

1 Like

Actually, Algorand provides a much higher security than that.
According to https://www.algorand.com/resources/blog/algorands-core-technology-in-a-nutshell, if there was one block produced since the big bang, you would have only a single fork event over the age of the universe.

In addition, Algorand recovers almost instantly after a network partition: https://www.algorand.com/resources/algorand-announcements/algorands-instant-consensus-protocol

3 Likes