ggutoski
commented
3 years ago Depends on #42 . In order to blame someone for a deserialization fault we need to know who the message is from. Right now the from field is part of serialized data, so we cannot learn this unless we successfully deserialize. After #42 is fixed we'll have from information independent of serialized data---we'll know whom to blame if deserialization fails.
Check for deserialization should probably happen before the round begins, and should be generic across all rounds.
The most obvious spot is in set_msg_in. Ideally, we would wait until all incoming messages have been received and then blame all parties who failed to deserialize. Unfortunately, this isn't so easy to do in set_msg_in. Perhaps we can set flags in set_msg_in that we check in next_round before running the round's code.
Unfortunately, our current design makes this ugly. We already store messages as Option and use the presence of None to decide whether we're expecting more messages this round, so we can't commandeer the Option for deserialization failures. To pursue this idea, we'd need either
- a multi-state
Option-like enum withSome,None, andDeserializationFailurevariants, or - a separate
Vec<bool>indicating which messages failed to deserialize.
Because messages are assumed to be authenticated, any failure to deserialize a message from party P is deemed to be a fault of P. Thus, deserialization failures should trigger the appropriate sad path.