mirror of
https://github.com/nspcc-dev/neo-go.git
synced 2026-03-01 04:28:51 +00:00
Improve consensus message delivery #1058
Labels
No labels
I1
I2
I3
I4
S1
S2
S3
S4
U0
U1
U2
U3
U3
U4
blocked
bug
bug
cli
compiler
config
config
consensus
dependencies
discussion
documentation
enhancement
epic
feature
go
good first issue
help wanted
neotest
network
oracle
performance
question
rpc
security
smartcontract
task
task
task
test
vm
wallet
windows
windows
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
nspcc-dev/neo-go#1058
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @roman-khimov on GitHub (Jan 18, 2023).
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 on GitHub (Jan 28, 2023):
Another thing that can be done is sending all extensibles to the new peer (should also be helpful for the #2803 case).
@AnnaShaleva commented on GitHub (Jul 17, 2025):
Here's an example of how this issue can be reproduced on privnet:
TimePerBlock: 1s,MaxTimePerBlock: 20s) viamake env_startfrom scratch.Eventually primary node will start as the first node in the setup, immediately create proposal and won't relay it because there's no peers yet. It will request CV:
The rest of nodes won't receive proposal, but will receive CV:
If there are no transactions in the network, then on backup timer timeout backup nodes will request CV. CV happens, new primary creates proposal immedieately and the block is accepted ASAP.