search

nspcc-dev / neo-go

Go Node and SDK for the Neo blockchain
MIT License
123 stars 79 forks source link

Improve consensus message delivery #2881

Open roman-khimov opened 1 year ago

roman-khimov commented 1 year ago

dBFT inevitably relies on eventual message delivery, so in presence of some communication issues it can be delayed, but not subverted. Yet the degree of this delay can be somewhat impractical (as in #2803), so we may want to improve our retransmission mechanisms.

There is a concept of recovery messages already, it can be extended to re-request messages more often (wrt regular dBFT timeouts). That's the first option, using a new set of P2P messages.

Another one is to retransmit in a fashion somewhat similar to transactions, where we just repeat ExtensiblePayloads we have in a pool. It's somewhat more efficient network-wise, but it's hard to formulate strict conditions for when this should happen (dBFT timers and stages are hidden in the consensus process).

roman-khimov commented 1 year ago

Another thing that can be done is sending all extensibles to the new peer (should also be helpful for the #2803 case).