Protect against Resync replay attacks

[loongy]

Currently, a Process will handle Resync messages by resending the latest relevant blocks. This has a non-trivial amount of overhead, and Hyperdrive expects the user to implement rate-limiting of messages to prevent this kind of attack.

However, we can implement some basic rate-limiting within Hyperdrive itself by relying on approximately close clocks.

• The Resync message includes a Timestamp.
• When sending a Resync message, the Timestamp is set to the current time as seen by the node.
• When receiving a Resync message, the node will drop the message if it is more than 2 seconds in the future, or more than 8 seconds in the past.

We should also introduce bloom filters for Resync messages. If the Resync message appears in the bloom filter, it gets dropped. If not, it is processed and added to the bloom filter. This filter is periodically cleaned (once per minute). This protects against replays of the exact same Resync message within a one minute window without requiring a large amount of space to remember all Resync messages ever seen.

• Add two in-memory bloom filters to the Replica: frontResyncBF, and backResyncBF (moved to Introduce Resync bloom filter #72).
• Check the Resync message against both bloom filters and drop the message if it appears in either filter (moved to Introduce Resync bloom filter #72).
• Add the Resync message to the front bloom filter if it does not appear in the previous check (moved to Introduce Resync bloom filter #72).
• Add ResyncBloomFilterCycleInterval to the options (moved to Introduce Resync bloom filter #72).
• When receiving a Resync message, check a lastCycledResyncBF variable. If it is older than the configured interval, set backResyncBF = frontResyncBF and frontResyncBF = empty (moved to Introduce Resync bloom filter #72).

To prevent a malicious node from constructing a Resync message that, when put into a bloom filter, causes the bloom filter to return as many false positives as possible, we need to make the hash generated from the Resync message unknowable. This is easy to do on a node-by-node basis. A boot, a node will generate a random in-memory hash that it combines with all Resync message hashes before adding/checking against the bloom filter. Since this hash doesn’t change, it will not affect the effectiveness of the bloom filter. Since it is only known by the node (and is different for all nodes), a malicious node will not be able to perform this attack.

Notes

• It is not necessary to use any persistent storage for the bloom filters.
• The bloom filter can create false positives. However, these messages are not a critical part of the consensus algorithm (only F nodes need to have their Resync messages respected, and nodes can send their Resync messages to a random subset of nodes).
• It is still recommended for users of Hyperdrive to implement rate-limiting of each message type. For Resync messages, one per IP-address per minute should be more than sufficient (these messages are only required during reboots).

[loongy]

Moving bloom filter to #72. It is not necessary for v1.3.0, since timestamp restrictions should provide sufficient protection.