Size of messages in hare protocol are too large for P2P network (esp. SVP)

[barakshani]

Listed some potential issues to address once we run the hare protocol on a large scale. The protocol specifies running that hare with committees of size N= 800, and so f=401.

• [ ] 1. size of messages. most messages contain a certificate assembled of f messages. SVP is even larger. A recommended solution is to implement references (pointers) in hare messages, that would significantly reduce the size of messages.

• [x] 2. VRF. We would need to run the VRF over N messages every round (expect for proposal). We use the BLS signature scheme, as our choice of VRF, and its implementation is not optimised; see https://github.com/spacemeshos/go-spacemesh/issues/1648 and https://github.com/spacemeshos/go-spacemesh/issues/975. There were thoughts of choosing a different construction for our VRF (https://github.com/spacemeshos/research/issues/15). Note that sticking with BLS may allow us to aggregate signatures (and public keys), which may be useful for syncing the hare results (see https://github.com/spacemeshos/go-spacemesh/issues/1825).

• [x] 3. active set calculation. this is not necessarily relevant for a large scale, but for long epochs. The hare traverses over a full epoch to get the number (and set of ids) of total active miners in consensus. Once epochs become 4032 layers, this may take a long time.

[jonZlotnik]

#3287 would give us more insight into how much we need to reduce the message sizes by, and whether the current sizes are truly problematic.

Note: the only message that actually contains a "certificate", as per the current implementation, is the notify message https://github.com/spacemeshos/go-spacemesh/blob/develop/hare/algorithm.go#L655 That is the only time the SetCertificate method is called on the hare message builder.

Certificates are currently not included in the status messages because (1) in the first iteration, preround messages (and thus the preround certificates) are assumed to have been seen (and constructed) by the beginning of the status round, and (2) the commit certificates from previous iterations of a consensus process are constructed and then broadcasted by the end of the notify round.