Open Problem: Avoid DoS attacks in Alastria

As you may all know, Alastria is based on Quorum. Quorum enables the use of many consensus mechanisms, removing the need of PoW or PoS. In Alastria, we recently adopted Istanbul BFT (a PBFT-inspired consensus algorithm with transaction finality, by AMIS, and introduced in the latest versions of Quorum). IBFT is an adaptation of a 3-phase consensus algorithm for distributed system published in a paper from the 90s.

All this sounds great, but, what are the consequences of adopting IBFT in Alastria? With IBFT we are pushing the transaction limit increasing the amount of blocks that can be validated per second; and we are making the blockchain more secure against attacks, after removing the inherent protection of PoW and PoS algorithms. By definition, BFT (Byzantine Fault Tolerant) algorithms are designed to avoid malicious attacks of this kind over a distributed system. Traditional blockchains are protected by PoW and PoS consensus algorithms through two main mechanisms:

• The need of significant amounts of computational resources to mine the blockchain, and consequently the need of a majority of the computational pool in the network to perform attacks over it.
• The use of a currency or token, that is spent every time a transaction is performed, and that lure malicious nodes from sending an unlimited amount of fake (or even real) transactions to the network, that could lead to an overload of the infrastructure, with its consequent denial of service in the network.

With IBFT, we removed PoW/PoS, and with it, we removed tokens as a mean of reward and protection from malicious nodes. And you may think, “but we are developing a permissioned blockchain for a consortium. We can trust all of the members and nodes in the system”. And you may be completely right, but imagine that, by chance, one of our “trusted nodes” is attacked and grants access to the network to other “less-trusted” nodes; or that these “trusted nodes” unintentionally misbehave. Without tokens in the system these could do anything and collapse the network. Alastria is being designed as a critical infrastructure so we must avoid, protect or, in the worst case, minimize the consequence of any these attacks or misbehaviors.

In fact, in the description about IBFT, the following interesting questions are brought by its authors:

Does it still make sense to use gas? Yes. We still need gas to prevent infinite loops and any kind of EVM exhaustion.

Does it make sense to charge gas in a consortium chain? The network would be vulnerable if every account has unlimited gas or unlimited transaction sending power. However, to enable so, one can run all validators with gas price flag --gasprice 0 to accept gas price at zero.

And this last question is a key point for us. Right now in Alastria, we are enabling a gasprice=0and this makes sense for now, in a “test-net state”. Every partner in the network can perform unlimited transactions, and it is a good way of testing the limits of the system and “play” with its capabilities. However, we need to address this problem ASAP if we want to release Alastria’s main-net.

We may think several ways to solve this problem, either technically or “regulatively”:

(Disclaimer: this proposals do not represent the opinion of Alastria’s Technical Committee or any other institution, it is a personal overview)

• Limit the amount of transactions per participant per day
• Enable a gas system where partners are automatically rewarded with fixed amounts of gas every day according to its contribution to the system (in terms of validator nodes, infrastructure, development contribution, infrastructure management, needs of tokens, etc)
• Design a gas market where partners can increase their daily gas rate or sell their leftovers (not necessarily with money)
• Monitor the activity of every node in the system to “spy” them and detect a misbehavior
• Design an alarm system for the infrastructure, to automatically detect traffic anomalies (here some buzzword technologies such as machine learning, deep learning, big data, etc. could suit perfectly)
• ….

We could think about loads alternatives. And the core technical group, or even Alastria’s Committee, could decide the solutions that seem better for everyone and implement it. But what better than a solution agreed by a majority of the partners involved in the development of the infrastructure? So I call for your help. Which solution is for you the best to avoid this DoS attacks, i.e. a node of the network sending an unlimited amount of transactions to the network?

You can send us your feedback commenting this post, through an AIP or issue in our github repos, through our forum, or personally to me (I love to discuss about open problems in technology and beyond, so let’s take advantage of it ;) ).