JoelKatz Posted October 2, 2019 Share Posted October 2, 2019 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 wojake, Skylerbigs, Mpolnet and 1 other 4 Link to comment Share on other sites More sharing options...
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!Register a new account
Already have an account? Sign in here.Sign In Now