ILPv4 makes some trade-offs compared to ILPv1. However, mixed in with these trade-offs are some - imho - pure improvements. This document describes what it would look like if I had to redesign ILPv1 given what we know now, but weren't willing to make some of the more controversial trade-offs. This work also revealed the surprising conclusion that ILPv1 transactional semantics (non-chunked or "universal mode quasi-atomic") are possible to achieve using ILPv4.
There are two main differences that are relevant for this discussion:
- ILPv4 assumes that all parties in the chain of an ILP transaction understand ILP. ILPv1 is designed around "ledgers" which are systems that act like an ILP connector, but do not understand ILP.
- ILPv4 assumes that all payments are small. ILPv1 is designed to support larger payments as well, which requires support for additional features, such as liquidity curves to deal with different rates for differently sized payments.
As noted in the original ILPv4 ticket, it is possible to model an ILPv1 ledger as a connector whereby the sending party pre-funds with the connector and the connector post-funds with the receiving party. That way, both sides trust the connector.
We also have the concept of simulating a connector in the plugin for example in ilp-plugin-mini-accounts. Putting these ideas together, we can actually use an escrowing ledger like five-bells-ledger in ILPv4.
To use this ilp-plugin-bells-escrow, you would configure the hosting connector to settle with every payment. Then you would add the following behavior in the plugin. On the sending side, you would prepare on ILPv4-prepare, ignore sendMoney, return successfully on ledger fulfill and throw on ledger reject/cancel. On the receiving side you would emit data on ledger prepare and emit money on ledger fulfill.
Other escrowing ledgers such as blockchains could be used the same way.
ILPv4 generally assumes that larger payments will be split into smaller chunks. However, this is only necessary when the maximum packet size is small. In order to get ILPv1 behavior, we simply need to configure connectors with a large packet size.
ILPv1 has various functionality related to handling different exchange rates for differently sized payments. This includes liquidity curves in the routing protocol and the quoting protocol ILQP. This functionality serves two important goals:
- Performance improvements / quote caching
- Quoting by destination amount
When we originally designed ILPv1, we anticipated that quoting would add significant overhead to the payment process. However, in practice, we found that even when doing a one hop payment over the fastest real-money ledger (XRP Ledger), the latency added due to quoting was negligible. As a result, I would say today that all of the caching functionality in the quoting and routing protocols was horribly overengineered and it is better to just quote ahead of every payment. The payment will take one or more orders of magnitude longer anyway and this removes a tremendous amount of complexity.
Quoting by destination amount is difficult without ILQP. It would be possible to create increasingly large prepared payments in an iterative process similar to chunked payments in ILPv4. However, we have to assume that preparing payments is slow and expensive in this context, so this would probably not work for a ILPv1 style network. (It is still an interesting option for doing non-chunked payments quoted by destination amount in ILPv4.)
Based on the considerations above, I would remove the quote-liquidity functionality from ILQP since it presents an unnecessary optimization and keep only the quote-by-source and quote-by-destination messages.
If implemented this way, I believe the resulting solution would be better than canonical ILPv1, but worse than canonical ILPv4. It retains many of ILPv4's architectural and protocol simplifications and contains the workarounds for legacy ledgers to the respective ledger plugins.
Writing this document lead to some interesting realizations for doing non-chunked payments in ILPv4. Iteratively preparing a payment in chunks (which all contain the same condition) is a novel idea which effectively provides a way for receivers to atomically receive a payment, yet allows the sender to "quote by destination amount" without needing ILQP.
It seems worthwhile further exploring the space between and around ILPv1 and ILPv4. That said, my strong recommendation is to focus our efforts on ILPv4 because it is overall the most promising approach and provides the greatest benefit to users: extremely fast and cheap payments, even when payment size is very small - i.e. the Internet of Value.
Yes! That's the best summary I've heard!
I responded in that thread with an alternative that allows you to choose the next connector without any changes to ILPv4.
I don't think that that will be a common use case, but it is certainly nice that it is possible for a ledger + ledger plugin to offer this feature without any special support in ILP.
Push distribution of exchange rate information:
Does not provide a meaningful benefit to overall payment latency
I would refer to my point about performance from the doc above. Quoting is already so much faster than execution that optimizing it via things like push distribution of exchange rates provides no meaningful benefit.
Picture the Seven Ledger Demo (~60s) and now picture it with 50% faster quoting (still ~60s). It's just not a meaningful difference in the context of ILPv1.
Means that rates are less up-to-date than with quoting
An exchange rate that is an hour old is necessarily less accurate than one that is only a few seconds old. That means I have to include more slippage in my payment. In ILPv1, the deliverable amount was visible, so slippage was lost as fees. (In ILPv4, connectors can still try to steal the slippage for themselves, but at least they don't see the amount under which the receiver will reject so it's impossible to steal all of it and stealing most of it risks a higher rate of failure.)
Creates higher (possibly prohibitive) load on the routing layer
Every node needs to tell every other node about new rates on a frequent interval, let's say once an hour. This is a substantial load for a routing protocol.
In the BGP world, some people think that even a 24 hour update interval is too much:
I would echo this sentiment based on my own tests. Even with a tiny number of nodes (I tested 500 connectors on my laptop) it takes a couple of minutes to reach convergence. (The ilp-kit 3.0 version supports nowhere near 500 nodes.)
Suppose we had 8-bit amounts.
Binary search would mean that I would quote a source of amount of b10000000. If the receiver rejects with "too high" I would try b01000000 next. If I get back "too low" I would try b11000000 next. And so on. This takes O(log n) time.
An immediate improvement would be interpolation search. In the case of a linear exchange rate and using linear interpolation, this improves the performance to O(log log n). The client could use polynomial interpolation to converge more quickly when the exchange rate is not linear.
What I was suggesting is an alternative for situations where you want a "quasi-atomic" payment, but don't need a prior informational quote. The way it would work is that the recipient would keep packets that undershoot the target amount prepared and respond using a zero-amount packet (or an out of band message) instead of a rejection. When a combination of packets that matches the target amount closely enough is prepared, the recipient fulfills all of them in one go.
What's neat is that this is parallelizable.
Suppose I'm the sender and my maximum source amount for this payment is 40 sender units. I'm trying to deliver a destination amount of 150 receiver units to the recipient. The fee policies between me and the receiver are non-linear.
I prepare a twenty unit (source amount) packet, a ten unit packet, a five unit packet, a three unit packet and two one unit packets. The receiver sees prepared packets with the amounts 180, 90, 45, 15, 5, and 5. Note that the exchange rate was not linear. The receiver fulfills the 90, 45 and 15 unit packets for a total of 150 units and rejects the rest.
The receiver can of course fulfill more than the destination amount, but that's not that different than them quoting a higher destination amount to begin with. Either way, they can't exceed the maximum source amount. Generally, in practice, we've seen two cases. 1) Where a human users reviews the quoted amount. In that case, to achieve atomicity we'd get an informational quote, so we would use interpolation search with unfulfillable packets and not this scheme. 2) Where a computer is making the purchase decision, e.g. ilp-curl. In that case, there is probably some maximum configured and otherwise it's up to the receiver to charge whatever they want. This protocol would work for this case. What stops the receiver from overcharging is repeat business. AWS can overcharge me for my S3 files anytime they like - they have my credit card. But if I notice they're charging more than their pricing page says I'll probably stop using them and they'll get shamed on Twitter.
ILPv1 also requires test payments because 1) the destination amount does not allow detection whether another connector is honoring its quotes (a malicious connector can selectively honor its quotes which is undetectable by its peers even when the destination amount is known) and 2) there are other reasons that ILP requires test payments, such as detecting high packet loss, high latency, high quoted rates, and so on.