What are some known potential attack vectors for EOS such as delaying or clogging the network?

Question

Cryptokitties stalled ethereum for a specific amount of time. And Bitcoin miners intentionally mined blocks with 0 transactions in it. Can any of these things happen to EOS or something similar? How much EOS would an attacker need to hold in order to do a similar attack?

Answer 1

Can any of these things happen to EOS or something similar?

BPs can certainly decide not to include transactions. This is particularly dangerous because not including transactions means the BPs cannot be voted out, as votes are communicated through transactions. If 1/2+1 BPs refuse to include transactions, a hardfork would be required to address the issue.

Indeed, every blockchain is vulnerable to 51% attacks, but in PoW, pool miners can redirect their hash power away from the malicious mining pool, while voters in DPoS cannot vote out malicious BPs. However, this does not necessarily need to be a bigger issue because the two designs operate on different principles, and EOS embraces on-chain governance and social contracts, while many PoW designs are often meant to reduce or remove input from the human layer.

What are some known potential attack vectors for EOS such as delaying or clogging the network?

To delay or clog the network in its current state, one's best bet may be attempting to trigger congestion handling every block.

To understand this mechanism, one should first know that when the network is not busy ("relaxed state" or "idle state") a user is entitled to at most 1000x their stake. In other words, a user who delegated 1 EOS for NET, while the network is in the relaxed state, they can use resources as if they had delegated 1 < EOS ≤ 1,000 EOS, depending on load. This creates a fractional reserve of resources where "virtual resources" perceived by the users are much larger than the real resources that the network owns.

This is often fine, because CPU and NET are ephemeral resources: if they're not used right away, they cannot be saved and used later by the user entitled to those resources. Therefore, most of the time, the network actually operates in the relaxed state where users have access to much more resources than they can objectively claim in a stake-weighted system.

However, at the moment, the parameter target_block_cpu_usage_pct in genesis.json decides the threshold that triggers the congestion handling mechanism every block. If the target is set to 10%, then, when a block has filled up 20ms CPU, the rest of 180ms (assuming 200ms max CPU/block) of the block is allocated in congestion mode (stake-weighted.) Therefore if an attacker managed to fill up to reach the threshold in every block, every user would be entitled only to the amount of resources that their stake can legitimately claim. This can often be prohibitively expensive, stopping many users from being able to execute any transactions. Note that every user will always be entitled to their fair share of resources, but this could be insignificant under heavy loads.

How much EOS would an attacker need to hold in order to do a similar attack?

To trigger congestion every block, one would need to push the usage over the threshold. Assuming no other activity and a threshold of 10%, a greylisted attacker would need roughly 10% of the staked CPU to be guaranteed to trigger congestion handling every block. However, these conditions are overly artificial as there will likely be some other activity in the network, and the threshold may be programmed dynamically to respond to load, so it's difficult to put a number on it.