From TG (@smitop)
Wouldn’t it be possible for one bad actor to easily wipe out Albatross’s optimisticness? How hard would that be for an attacker
From Telegram (@terorie):
If an attacker tries hard enough, he can slow down the network a bit. But nothing dramatic or permanent.
There are two possible consensus-level attacks on Albatross we need to worry about.
Forking/Double-Spend: The attacker publishes two or more different blocks to the network when he is supposed to only create one. Each validator always looks out for such forks though and reports them when seen (”trust but verify“ attitude), slashing the attacker pretty much instantly. The next honest validator would simply pick one side of the fork and abandon the other. The more validators collude or the higher the stake of a single validator is, the larger forks can be created. Although forks cause zero delays in block time, they might force services to wait for more confirmations before accepting a transaction.
Timeout: The attacker might just not create any block when it’s his turn. To not delay block production indefinitely, each node waits a short amount of time (~5-10s) before proposing to the other nodes to switch to a different validator (view change). The view change is executed if more than two thirds agree. The total possible delay caused by the attacker is (timeout + view_change_duration). It shouldn’t be more than 15s.
Currently, we intend to enforce penalites by redistributing a part of the attacker’s stake to the honest nodes that reported the misbehaviour (slashing). With each slash the attacker’s stake decreases and so do his chances of being a validator in the next epoch. If the attacker has no stake left, he is kicked out of the validator set.
We can conclude that attacking Albatross is not only costly but also not very effective.
And the TL;DR version:
No, an attacker can’t slow down Albatross without spending a good amount of NIM.
Under regular BFT security assumptions, the slowdowns aren’t more than a few seconds at a time
1 Like