The Interledger Protocol (ILP) has been compared with the Internet Protocol (IP).
I noticed there have been multiple versions of IP:
IP versions 0 to 3 were experimental versions, used between 1977 and 1979. The following Internet Experiment Note (IEN) documents describe versions of the Internet Protocol prior to the modern version of IPv4 …
The dominant internetworking protocol in the Internet Layer in use today is IPv4; the number 4 is the protocol version number carried in every IP datagram. …
Version 5 was used by the Internet Stream Protocol, an experimental streaming protocol.
The successor to IPv4 is IPv6. IPv6 was a result of several years of experimentation and dialog …
Could you give us a summary of the different versions of ILP?
1 Like
They’re both light interoperability protocols that specify no more than needed for networks to intercommunicate and permit innovation on protocol layers both above and below them. ILP encapsulates value, as well as growing the market for all digital assets.
ILP wasn’t stable enough to build production code on when RippleNet protocols needed to be locked down with Ripple network of banks using the open ledger. So RippleNet are using an older version that was ready before. As time comes (at least a year away) Convergence will be doable when use cases emerge and banks can connect to the open interledger
this is just my opinion, hope it helps
1 Like
The first version of ILP had a focus on HTLAs and assumed that the settlement ledger between any two nodes was using these AND that the condition and fulfillment used in the ILP payment was the same one used in each transfer on each intermediary ledger.
As a result the format of the ILP packet was very different and we also experimented with pre-payment protocols to do quoting and liquidity checks.
There were some experiments done to change this and ILP v2 and ILP v3 pretty much died before they really lived.
ILP v4 (the version we are currently working from) was born of the idea that we should abstract away the ledger and assume that any two peers on the network have “some” way to settle but that ILP doesn’t require that settlement ledgers use HTLAs because sometimes two peers trust each other or have some other enforcement mechanism that ensures if they exchange packets and create settlement obligations between one another then these will be honoured.
This also makes ILP MUCH faster as the flow of packets happens over-the-top of the ledgers/settlement systems and doesn’t wait for them lock up funds etc.
Given that an ILP packet can therefor be routed from sender to receiver very fast the idea of focusing on very small amounts became more viable and instead of burdening the protocol with quoting and liquidity measurement logic we focused on “penny switching”.
So ILPv4 is designed to work well if:
- The amounts in each packet are very small (the risk associated with a single packet taking an expensive path is limited so no need for quoting up front, also see how STREAM deals with costing a route).
- The transfer of packets is very fast (implying that nodes use short expiries and also reduce their risk)
Some projects that use ILP like RippleNet and Mojaloop are using ILPv1 style HTLAs in the payment flow because they are operated in environments where this makes sense (controlled ecosystems where reliable quotes and large packet values are possible).
What is interesting is that it is possible for ILPv4 to be used to stream small payments through nodes that settle using ILPv1-style payments.
The reality is that those ILPv1 systems can move to using ILPv4 packet formats easily. They can even send large payments in each packet and route the packets via the ledgers (Mojaloop is already doing this). Nothing is technically preventing this, however, if those packets are routed over the “open Interledger” they will likely be rejected as they won’t find a path through connectors that are prepared to route large packets or route packets with long expiries.
So, while ILPv1 and ILPv4 do have some technical differences the real differences are in the expected properties of the network (fast responses and small per packet amounts) which will result in packets being rejected if they have:
- Long expiries, and/or
- Large amounts
6 Likes