go-spacemesh
go-spacemesh copied to clipboard
spacemeshos
preround status optimization
We made optimization to the size of status messages. Instead of sending the preround certificate as in the original article, we count on the fact that preround messages will arrive no later than the following round, hence each participant is expected to be able to find proof of status messages at the end of the status round.
Thi optimization required a few tweaks like moving status message validation to the end of the round (instead of instantly) and doing union over preround messages from the same sender. Both are not trivial from the security aspect and actually expose us to some attacks (like a union of messages that can grow bigger and bigger).
The research team was not intimidated nor worried about the implications of that optimization. Dr. Barak & Gavrad were concerned about it.
A follow up to this optimization is a wider optimization. The certificate of preround messages is no special and it can be done also for SVP and commit certificate.
IMO, this should be thoroughly considered and analyzed by the research time before proceeding. I do recommend that we do find some way to optimize the size of Hare messages. Graphene is or just using IDs of messages are also good candidates.
@barakshani wrote:
Recall that our implementation deviates from the original protocol by not including inĀ statusĀ messages a certificate (withĀ preroundĀ messages). It's a computation-wired data tradeoff, since one could validate a status message givenĀ allĀ of the preround messages. (a side note: in one of the summits we went over why we cannot to do this forĀ proposalĀ messages.) Hence, we first allow receiving preround messages during the entire execution; secondly, we propagate status messages without verifying their validity, which is done at the end of the status round.
Basically there are several issues here: allowing preround at all times, we take union of the sets if an adversarial miner sends more than one preround message (which may blow up our memory), it (not verifying status) may spam the entire network. We discussed this briefly in the last summit, and you didn't seem to be concerned about these issues. I think it will be good to consider it more deeply. It is possible that a resolution will come from adding refences to hare messages, as we discussed in the past, because then the wired data won't be that significant.
Note, the optimisation could not be done to SVP.Ā
@gavraz wrote:
Just adding to what Barak said:
before - we could limit the receiver to hold no more than one preround message per sender (pubkey). A participant that wants to send a preround message could simply use the information he gathered to create a preround certificate. Attaching the certificates allows each receiver to validate it independently of what he witnessed.
after - since there are no preround certificates in status messages, a participant must have received all preround messages used to form the status message (assuming the status message is valid and provable). This situation required us to receive preround messages even after the preround round and even hold more than one message per sender. We optimized it a bit by holding only the union of preround message per sender and not the actual message but we are exposed to the same issue, we can be spammed over the union...
@jonZlotnik curious to get your take on this once you've had a chance to consider it
