Suggestion: Reduce Relaying

[JoelKatz]

The XRP Ledger currently uses flooding to propagate transactions, proposals, and validations. This means a typical server either receives, transmits, or both every one of these objects over every connection that it has. This has a large number of disadvantages:

• Adding additional server connections means a significant increase in bandwidth consumption.
• Lots of messages are relayed unnecessarily costing both CPU and bandwidth on both sides.
• The network diameter is larger than it needs to be.
• Link latency is higher than it needs to be, making it harder for a server that has lost sync to catch up.

We propose a system of slots and “squelches”. Each server would create a “slot” for each validator it chose to relay. Each slot would have a list of uplinks and downlinks. When a server receives a proposal or validation message, it would check the “slot” for the validator that originated it. If it had already received enough copies of that message, it would send a “squelch” to the sender of that message which would suppress further messages from that source being sent to it over this connection. When a server gets a “squelch” it would add the sender to its list of non-downlinks for the corresponding slot.

This would allow each server to maintain a set of three uplinks for each slot. If a server lost an uplink, it could send an “unsquelch” to each server to recover its uplink. Squelches would be time limited to allow for network topology changes.

This approach requires some tweaks for transaction. Every validation from the same validator comes from the same source and so can follow the same tree to spread over the network. But transactions can originate anywhere. To handle transactions, they can simply be relayed both up and down the tree. So while validations and proposals would only be sent to your downlinks, transactions would be sent to both uplinks and downlinks.

This change will allow servers to have more connections, reducing network diameter. CPU and bandwidth costs would be reduced and link latency would be significantly improved.

This post is one suggestion for an enhancement to the XRP Ledger. See this post for context:
https://www.xrpchat.com/topic/33070-suggestions-for-xrp-ledger-enhancements/

You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ 

[Guest]

In a semi related issue (OK, OK - tenuously related) , I have noticed that peers connect to multiple servers in hub pools such as r.ripple.com and zaphod.alloy.ee .

It would be nice to have some kind of hub cluster logic to mitigate this. Since these hubs are primarily for discovery, it is not beneficial to have slots on multiple servers occupied by the same peer. 

[EMacBrough]

I definitely support sparser message-relaying, but I think we need to be pretty careful to avoid attacks here. For instance, if I understand correctly, a naive implementation of the slot/squelch idea would enable an attack that works for example as follows: suppose there are 100 hubs, the attacker controls 5 of them, and nodes are configured to only maintain 5 open slots for each originator. Then the attacker sends a message to its 5 hubs which relay that message to every node. Then all the other hubs will be squelched so that the attacker can ensure that only the nodes it controls will be listened to for messages coming from it, breaking Byzantine accountability.

There's probably a reasonable way to make it work using per-node squelches that are random among the nodes that passed a message within a moderate interval (rather than first-come-first-serve), but I my main point is just that we should be careful, formalize the idea, and find some specification that's both safe and not overly complicated.

[Sukrim]

This sounds like an implementation detail of rippled to me, not an issue with the XRP Ledger (there could be other implementations that solve message relaying differently). That being said, I think I remember Vinnie was already building something about "Supernodes" into the protocol which seems to have been abandoned later. What happened to this approach?

Also, nearly everything (except transactions in-flight) can already be attributed to a ledger height. Maybe this can be used somehow to reduce network traffic instead or in addition to a rather generic approach, if you know the ledger height of your peers (which would just be a single broadcast to /from all peers every few seconds to communicate)?

[tulo]

I also support the sparse communication, which clearly have big advantages, but as @EMacBrough said, we need to be very careful. When designing decentralized systems, the sparse communication is always a very critical point. The problem should be tacked theoretically first, to understand the limits of the consensus protocol when this kind of communication is present.

Again I'd put more resources into making a new consensus mechanism from scratch that takes into account this kind of communication, instead of implementing something for a consensus that wasn't built for it.