@klaus keen to hear your thoughts on this…
https://modernconsensus-com.cdn.ampproject.org/c/s/modernconsensus.com/technology/bison-trails-tries-to-de-risk-staking-with-double-signing-protection-software/amp/
1 Like
The problem they’re addressing is to prevent honest parties from being accused of being malicious due to a bug (or synchronisation issue) that makes them briefly act like a malicious party. In some blockchains (at the moment not us as far as I know, but in the future this will likely be added in some form) try to detect malicious behaviour and punish validators as soon as that malicious behaviour is spotted. One of the easy ways to spot someone misbehaving (and one of the easier ways a malicious party can try to derail a protocol) is if they sign contradictory messages (e.g., propose different blocks for the same blockheight in a longest chain protocol, or voting contradictory voting based protocol like Tendermint).
The problem with such punishment is that there might be an honest accident - someone running a parallelised version of the validator (or having a backup in case their node crashes) and their different servers not coordinating properly, or a validator crashing just after sending a signed message, forgetting that it did sign the message, and running through the signing process again (the latter has already been looked at on a protocol level in the crash-revocery failure model, but I’m not aware of that model having gained much traction in popular implementations). What Bison Trails seem to do (on the first sight) is that they block the signature key in a way that prevents a backup server from re-signing a message, and thus - if you use it - preventing a validator from accidentally doing something that makes them behave/look malicious (this is the example they mentioned, I can’t see what other sources of double signatures they cover; would be good to see more details to see where the approach works and where the limits are). This is a useful tool for serious validators, and it definitively
it would make sense to include some protection on the validator side against such synchronisation issues.
It’s not clear at this point if this is our job as Vega though; for one, we need to be careful to avoid forcing our validators into any licensing issues (if that exists, I couldn’t see if the usage is free); in addition, while we should support parallelization and backup servers, managing such would be more the job of the validator rather than part of the Vega package, the most I would see in the spirit of modular design to offer hooks into such a system on the blockchain level - my guess is that this would be easiest by including a specialised crypto library.
On the Vega protocol level, another mitigation would be to be a little more tolerant against failures - a validator that once issued a double signature doesn’t need their stake confiscated right away, but could be subject to a “three strikes and you’re out” rule, or a temporary suspension and a community vote.