Liquidity Curve - ILP Quoting

[KarmaCoverage]

https://github.com/interledgerjs/ilp-routing/blob/master/src/lib/liquidity-curve.js

https://github.com/interledgerjs/ilp-connector/issues/344 - This is a great read if interested in ILP quoting.

Quote towards the bottom...

Quote

 

TL;DR: There is little debate about the ILQP and CCP protocols but still debate about how the reference connector implementation should use CCP, answer quote requests, and route payments.

Interledger Quoting Protocol (ILQP)

This includes:

• Quote for fixed source amount
• Quote for fixed destination amount
• Quote for liquidity curve

The quoting protocol should not change from this and we should consider the binary format @sentientwaffle has recently been implementing pretty much done.

For clarity’s sake we should only talk about “quoting” as the process of asking a connector for the rate to a given destination. How a connector decides to answer a quote request is not part of the quoting protocol.

Connector-to-Connector Protocol (CCP)

This is a protocol that connectors use to communicate with one another.

Based in part on @justmoon's conclusions and a suggestion from @bbock, this protocol should probably remain JSON or at least a format that allows arbitrary key-value pairs to be added. Connectors will likely have different policies for routing payments and the communication protocol should just make it easy to include whatever information connectors want in there.

ilp-connector implementation

Even if in the future everyone will be running custom connector implementations with proprietary logic, we need something that works out of the box now. Given the above conclusions about the protocols, most of the current debate is about how the reference implementation of the connector should work.

Options for what our implementation puts into CCP and expects to find in there:

1. Reachable destination prefixes
2. Number of hops
3. List of autonomous systems to destination (ledgers or connectors?)
4. Liquidity curves to destination prefixes
5. Max liquidity (bandwidth)

Options for when CCP broadcasts happen:

1. When liquidity curve changes
2. When routes (e.g. number of hops) change

Options for how the connector answers quote requests and routes payments:

1. Remote quote to a single connector with the shortest path to the destination
2. Remote quote to a single connector marked as the best in the routing table by a statistics-based heuristic or machine learning algorithm
3. Remote quotes to multiple connectors with either the shortest path or one hop more
4. Cached remote quotes
5. Liquidity curves broadcasted by peers
6. Pluggable module that can manipulate the routing table so everyone can implement their own prefered solution (this still leaves the question of what information is included in CCP)

Options for how routes and curves are stored:

1. Current routing table design that is a map of destination prefixes and liquidity curves
2. Routing table only stores destination prefixes, next hop, and number of hops and there may be a separate remote quote cache

Scalability considerations

• Assume 200 total nodes, 5 connections per node
• Blast radius of attractive rates
• Blast radius of liquidity curve updates
• Network chattiness
• Malicious connector attracting all traffic
• Malicious connector making another connector look bad
• Design for micropayments (maybe don’t need better paths for different size payments or liquidity curve combinations)

 

 

Edited January 24, 2018 by KarmaCoverage

[KarmaCoverage]

Video has a bit of conversation on liquidity curves & routing.

This also has some useful info  https://github.com/interledger/rfcs/blob/master/0010-connector-to-connector-protocol/0010-connector-to-connector-protocol.md

[mDuo13]

A "liquidity curve" is just a rate for a single pair—one hop of an interledger payment. It's just, not a fixed rate regardless of what amount you want to transfer. So I guess in another way, you could say a liquidity curve is an "amount-aware exchange rate"—whether costs become higher or lower at larger amounts, the liquidity curve allows you to express that in at least rough terms.

Here, this picture should illustrate what I mean.

 

 

 

[KarmaCoverage]

Quote

 

-- Liquidity curves describe the relationship between input and output amount

-- for a given path between a pair of ledgers.

--

-- The curve is expressed as a series of points given as coordinates of the form

-- <inputAmount, outputAmount>. If a sender sends `inputAmount` units to the

-- connector, the recipient will receive `outputAmount`. The curve may represent

-- the liquidity through a single connector, or multiple liquidity curves can be

-- combined into one to represent the liquidity through a given path of

-- connectors.

--

-- Points are ordered by inputAmount. The inputAmount is strictly increasing

-- from point to point. The outputAmount is monotonically increasing, meaning

-- each successively point must have an equal or greater outputAmount.

--

-- The first point represents the minimum amount that can be transacted, while

-- the final point represents the maximum amount that can be transacted.

--

-- If a query does not match a point exactly, implementations MUST use linear

-- interpolation. When querying by outputAmount, if multiple points match

-- exactly, the lowest inputAmount of any of these points MUST be returned.

 

https://github.com/interledger/rfcs/blob/51e2ec229085ddef1606b2848953901c61d5ae2f/asn1/InterledgerTypes.asn#L44-L68

I wondered why the bottom chart looked like that, without a smooth curve. Ok, this makes sense now.

I also found this very interesting from Evan Schwartz  post

Quote

 

11. The Surfer: Liquidity Curves and Large Packets

Died: September, 2017. Age: 9 months.
Cause of Death: Small is beautiful.

Should Interledger be built for small packet amounts, large amounts, or both? Since the goal was to support nearly all use cases, and thus all possible amounts, we needed a way to express how the exchange rate would depend on the payment size. We designed the Liquidity Curve, which used a series of points to represent the input and output amounts. Liquidity Curves were used in both the routing and quoting protocols to represent the potentially complex exchange rates.

For some time, there were discussions about killing Liquidity Curves because they were the most complicated feature in the core ILP. But they would ultimately be killed off by a more fundamental realization: that all Interledger payments would be small. Splitting larger payments down into smaller ones would make packets going over the network more homogenous. Exchange rates could be expressed as a single number and Interledger would actually use Internet-style packet switching.