The Hashgraph technology is aimed to be a fair censorship resistant, byzantine fault tolerant technology having a public network as well, where theoretically there is no need to ask a permission form the company Swilrds or from consortium members of Hedera and the network will eventually as public as for instance Ethereum. Recent achievements suggest however that the situation wont't be so clean and simple. The recent direction is to censor social media appearance that do not match into certain corporate policies, certainly the official names are "quality improvement" and "policy compliance", but actually most dictatorial governments have the same names censoring the local social media for filtering out the content that they do not like. Such a censorship raises some serious ethical questions even if it is carried out by a corporation, but it is surely not acceptable at an open distributed ledger platform. Censorship of the social media will very fast result in the censoring of individual transactions and decentralized applications on the platform.
So, let we see how Hashgraph can censor your transactions:
- The easiest way is blocking incoming transaction at peer level, simply not including into the Hashgraph by dropping the incoming transaction. For that actually it is not necessary to modify the Hedera software itself, incoming transactions can be filtered out on the operation system or on the network level, like filtering out certain transactions from a certain IP address. Certainly, a customer will eventually recognize if a transaction is dropped and will resend, possibly eventual to another node. As a consequence censoring at peer level works theoretically only if all of the peers drop the transaction. However, from a practical point of view a customer will probably give up including the transaction in the Hashgraph after a certain number of attempts. On the other hand, resending too many, like 20, times is probably not acceptable for most of the applications and use cases, so from a practical point of view blocking transactions at several peers, like in a geographical area can make certain applications not-usable, even if from a theoretical point of the transaction is 100% blocked.
- A similar censorship attack is to introducing a random delay for incoming transaction at the peer level. It is again something that can be carried out without modifying the official source code. If a transaction is 100% blocked, the customer will recognize it and resend it, possibly for another node. However if the transaction only delayed randomly it is more difficult to recognize. As a couple of minutes or hours random delay in the transaction processing is not acceptable for most of the decentralized applications, this can be an efficient denial of service attack for most of the distributed apps even if it is realized by one or two nodes.
- As the transaction is included in an event, it is propagated with a gossip protocol throughout the network. You can use similar techniques here as well, like blocking event propagation that contains a certain transaction, or delaying and random blocking events containing a transaction. As the peers are connected with TSL, such an attack is difficult to realize by an external attacker, however it can be easily realized by the operators of the nodes as a censorship attack, again without modifying the code itself, implementing everything on the operation system or network side. Blocking a transaction or event will be efficient if more than one third will actively block, however at random delaying a much smaller number of number of censors could effectively make a DApp unusable.
- There might be some further possible censorship possibilities at the state level and at the point as a transaction is applied to the state. As the implementation details are not known here, such attack vectors need further investigation.
- Last but not least, Hedera is basically a consortium that controls the code. It is pretty much an open question how the software upgrade mechanism will work what is sure that if the consortium votes against your transactions or DApp, a new software version can be delivered that will efficiently block your transactions and DApps. In practice, this process might be accelerated, as upgrading a new software version can be a slow process. I would probably create a configurable element in the software code itself where operators can individually set the blacklisted applications. It probably provides a further censorship attack vector.
