How is money currently routed through the network if there exist multiple paths between a sender and receiver and how much control do users have over the routes that their payments take? For example, if I wanted to send money through a particular connector or a particular set of connectors, could I do that?
Each connector decides where to forward packets next. The sender determines which connector they sent the packet to first and the destination address it is addressed to. The sender does not know the full path the packet will take and cannot force it to go through a particular set of connectors.
See How does routing work in Interledger? for more details on the routing protocol itself and how connectors populate the routing tables that help them determine which next hop to forward a packet to.
1 Like
If there were a particular set of business logic that needed to accompany the transaction, how do you ensure that your transaction flows through connectors that are capable and willing to also process that business logic? (I assume through an offline discussion with various connectors followed by coordination of connector relationships prior to initiating the tx?)
As a followon – if connectors are incentivized to handle packets through taking a cut, isn’t there an incentive to choose routes that go through your friends/are longer?
1 Like
These were my thoughts. Suppose the relationship you’ve developed with a connector entitles you to a specific set rate but that connector needs to establish their own relationship with a 3rd connector to offer all available currencies to the original customer at the pre-negotiated rate. I assumed since finding a path by price isn’t an option, that the ability to determine route would be possible so a predictable rate could be used.
I believe there’s more incentive for connectors to take a larger fee for themselves instead, since routing information is not advertised to preserve business interest. This is likely only a problem if a merchant (the receiver) cooperates with connectors in a specific payment path. However, the value of a single packet should remain negligible to minimize risk. The relationship between sender and receiver is implicit; however, it seems like it would be in the receiver’s best interests to be “honest” since they want to receive payment for the goods or service. Skimming additional fees could lead to a bad user experience and lessened demand, thus not sustainable for the service provider.
That being said, this could be an issue when an application built on Interledger becomes ubiquitous, but according to basic market principles, a competing service could take its place and margins would become smaller over time. I don’t want to speculate too much on market factors, but I believe there are strong economic arguments against crippling user experience.
Most connections on Interledger are not predicated on a strict contractual obligation in the same way smart contracts are, but connections are backed by social consequence at a minimum. In other words, the fulfillment often serves as a pseudo-receipt in order to approximate network costs. Most commonly, Interledger payments are predicated on credit relationships between peers. Intermediate connections can also subsidize network fees in order to guarantee an advertised rate, but I am not aware of any connector providing this kind of functionality.
There are a few proposals that have been discussed to prevent griefing on the network. I believe @emschwartz proposed multi-path payments (similar to multi-cast TCP in design), but the specification did not make it into ILPv4. In the current protocol specification, connectors in a payment path can adjust the fee rate on per-packet basis. If the connectors in a payment path collude with a receiver, it is possible for participants to increase the routing fee over time to grief the sender. Sending packets across multiple paths can partially address this issue but a malicious receiver still dictates incoming connections. There are other advantages and disadvantages to multi-path routing, but it was determined that its proposed design exceeded the scope of ILPv4.
In the current specification, fee scalping can be minimized by the receiver by withholding the condition for fulfillment. During payment setup, the sender and receiver negotiate an acceptable fee rate (using STREAM, PSKv2, etc) for each packet. In order to receive payment, the receiver responsibly discloses the fulfillment condition if and only if the incoming packet from a connector does not exceed the negotiated rate. It is conceivable that the receiver collects the remaining “fee balance” without disclosing it in the fulfillment as long as the pre-negotiated rate is satisfied, thus it is important for the sender to use a rate-limiting algorithm for streaming payments over the network. In the Rust implementation, this is called the congestion controller.