A solution to desyncing nodes problem

My understanding is the nodes failed to sync because of the block synchronization attack.

Even if that wasn't the case, the ledger wasn't bloating more than a gb a day, and intuitively, the nodes should have been able to 'download' the ledger.

I think a solution could be:

Instead of gossip-about-gossip communication, the PR only broadcasts the block to the node that had sent the block, the rest of the nodes will download the ledger from a PR.

So, basically, a representative node will have a permanent connection with a PR to download the ledger, and will also have the ability to broadcast and be broadcasted a block.

The transaction flooding made weaker nodes fall behind and stronger nodes lowered their bandwidth.
From here:

Lowering the bandwidth allows nodes to keep up while still allowing throughput multiple times over what was being used in practice. Since the activity in the last week looks like a coordinated ledger bloat attack, the network operating at a lower tps is alleviating those concerns.

With the bandwidth being limited, downloading the ledger is limited as well.

is used only for voting.
From Protocol Design - ORV Consensus - Nano Documentation

To make a Nano transaction, a node publishes a block [...] and those PRs then generate their vote (another small network packet) and publish it to each other and a subset of non-PR peers (who then publish to a subset of their peers). This pattern of communication is known as gossip-about-gossip.

All nodes are monitoring blocks, receiving and storing them.
It's way more efficient to watch out for the confirmation of a block and cement it rather than dump the block and download it from other nodes by bootstrapping later.
Admittedly this is more or less the way the bounded block backlog will work. But it's then a setting per node and can (and needs to!) be tied to the capabilities of the node.

2 Likes