Zilliqa has a blacklisting feature implemented in
libNetwork. The idea is to keep track of IP addresses of peers that, for conditions listed below, can potentially disrupt the operation of the node. Once blacklisted, the peer is effectively excluded from further interactions with the node.
- Socket write failure (according to
- Socket connect failure (according to
- Gossip message from peer exceeds
- Bytes read from peer exceeds
Adding exclusion privilege
- DS guards
NEWDSGUARDNETWORKINFOis received (new IP)
- Whenever DS committee is updated
- Lookup nodes
- Every time a message is sent out
- Manual addition of an IP using
Removing exclusion privilege
- DS guards
NEWDSGUARDNETWORKINFOis received (old IP)
- Manual removal of an IP using
Blacklist Removal and Clearing
- Non-lookup nodes remove
BLACKLIST_NUM_TO_POPnumber of peers from the blacklist at the start of the DS epoch
- Non-lookup nodes also remove all blacklisted seed nodes from the blacklist at the start of the DS epoch
- Lookup nodes clear the entire blacklist upon receiving the DS Block
Blacklist is enabled by default, and is only temporarily disabled when doing node recovery (
RECOVERY_ALL_SYNC). In that situation, the blacklist is re-enabled once the Tx block is processed.
A peer can become unreachable if it temporarily goes down. In this case, socket connections to that peer would usually return
ECONNREFUSED as the error message. When this occurs, we avoid blacklisting the peer in the "strict" sense as in the previously listed conditions. Instead, we blacklist the peer in the "relaxed" category.
While all incoming and outgoing messages from/to a peer that is strictly blacklisted are blocked, only outgoing messages to the peer are blocked for a peer that is in the relaxed blacklist. This allows the peer to have itself be removed from everyone's blacklist by sending the request for removal once it has come back online. Such a request will be accepted if the peer is found to be in the relaxed blacklist.