First Attack on Tour de SOL

Published in

Node A-Team

4 min readFeb 12, 2020

While enjoying a peaceful weekend, the first attack happened and stopped Tour de SOL network. The attacker was present in the Discord chat, and was there to describe how the attack happened. As mentioned in the previous post, the first stage of Tour de SOL mainly focuses on critical issues and attacks which could halt the network. Marking this first attack as a very important part of the Tour de SOL, we decided to provide summarized details which was shared within the chatroom.

What happened?

As a result of this 10 minutes long attack sent by Certus One, we were able to witness some reports on TDS Discord chat, saying that some validators did not proceed after approximately 798000 slot, while the slots on the network kept on increasing.

In fact, a fork was created by this attack at slot 797572. While the bootstrap validator, which had 37% of the stake remained on the left (picture below), all other validators forked right.

After this fork, the network never came back up

Certus One used this line of command, and added that it watches gossip network to send packets to live nodes only, until those nodes are off the gossip network.

Through this attack, among 57 nodes, 10 fell out of the gossip network. The network eventually halted, and never came back online as the attack was made during the weekend, and not everyone was able to be on their computer to restart their validator nodes on TDS. (Also, it was 6AM in Korea, when this conversation was happening).

Why didn’t the network come back up live?

The attack did not target bootstrap leader on purpose (if the attack successfully took down the bootstrap leader, who currently owns most of the stakes in the network, the cluster will go down just by attacking the bootstrap leader). But for some reason, the network did not go back up immediately, with only 10 gossip nodes going down.

The reasons for this issue seems to be one of the two:

Simply, because it is the weekend, and people were away from their computer
Rapid disk usage, causing no disk space for the reboot

For the first issue, due to different timezones, and the fact that the attack was made on a Saturday did not help the network get back up immediately. But, this could be solved just by doing an auto-restart on the validator nodes.

The second issue is a more complicated one. Excessive disk usage was happening on some participants. The expected disk usage was approximately 100GB / month, but Staking Fund, one of the participating validators of TDS, was experiencing a 47GB / hour disk usage and was unable to restart immediately after the attack since the 200GB disk was already full.

One attack found, but found two issues that needed to be fixed.

What is happening now?

As of now, issue regarding the first attack has been uploaded on Github. Also, since restarting the network with the same version could lead to repeated attakcs, the Solana team is working on a new release with this issue tackled. Participants have stopped their nodes and are anticipating for v0.23.3.