Jump to content
Atomic1221

Simplifying the ILP: The Graveyard of Possible Protocol Features

Recommended Posts

https://medium.com/@emschwartz/simplifying-interledger-the-graveyard-of-possible-protocol-features-b35bf67439be

Very interesting read about ILP. I believe ILP will be absolutely key for FI to use whatever internal blockchain or token they wish (privacy reasons/competitive advantage/regulation), whilst simultaneously benefiting from xRPL.

Share this post


Link to post
Share on other sites

That was an excellent read, well written! Anyone who wants to understand a quick history of the conversations going on in the W3C Community group for ILP should read this.

Quote

However, the shift to smaller, faster payments ultimately led to the realization that it would be connectors, rather than ledgers, that would implement the conditions.

Oh, yeah.. duh :dash1: could have thought of that earlier.

Still worth having gone through the discovery / thought process.

Quote

The idea of “Atomic Mode,” as described in the Interledger whitepaper, was to use a group of “notaries” or validators to ensure that transfers on multiple systems would be atomic, meaning they would be executed or rolled back together..... We prioritized the other mode, called Universal. Intermediaries take some manageable risk but, the protocol does not require agreement on who to trust, making it more… universal.

Ok, that answers that question.

---

Liquidity Curves are out, Interledger Quoting Protocol is out, on ledger Escrow is out, Atomic mode and Notary are out, among others.

So in the end we have a multi ledger payment who's route can be determined as it moves forward to the next step in the path. Wow, very impressed yet again :good:!

When is ILPv4?

 

Edited by KarmaCoverage

Share this post


Link to post
Share on other sites

 

3 hours ago, KarmaCoverage said:

So in the end we have a multi ledger payment who's route can be determined as it moves forward to the next step in the path.

Isn't that the SWIFT model where you have no idea how much and when something will arrive at the final destination? :-/

Share this post


Link to post
Share on other sites
1 hour ago, Sukrim said:

 

Isn't that the SWIFT model where you have no idea how much and when something will arrive at the final destination? :-/

I'd assume this would be addressed in the messaging layer. At that step where the kyc is done, and the fees are communicated.

This would go xVia > xCurrent > ILP > xRapid : Exchange fiat for XRP > ILP > XRPL tx > ILP > xRapid : Exchange XRP for fiat > ILP > xCurrent > xVia

I don't know if "RippleNet" has some routing table in the messaging layer, sort of doubt it, traders would want to compete here, not disclose...

However, if you think about stringing a bunch of RCLs together, each has it's own pathfinding built in.

So, depending on how banks link up with each others' RCL, ILP can be routing dumb...

...If the nostro/vostro relationships are set up as IOUs on each bank's xCurrent RCL, and if each bank had multi nostro/vostro relationships..

Then maybe (?) the messaging layer can ping each ledger's pathfinding for IOU Quality in/out for fee estimation, and each individual ledger only has to contribute 1 hop to the next part of the ILP address. Almost like "ILP rippling" but rippling ledger to ledger, instead of address to address on a RCL.

You can't get a payment through, if you can't get a message through, so sender and reciever have to be on the same page somehow outside of ILP.

[This could all be completely inaccurate, I'm 1/2 guessing]

Ditching Escrow was a shocker to me, I thought that set up was nice. But by avoiding the all the Escrow txs you keep the ledger open for payment txs.

This in exchange for Payment Channels, which are like prefunded ILP trustlines. IOUs could be used to avoid the prefunding (nostro/vostro credit). A mix of the two is probably optimal. 

Edited by KarmaCoverage

Share this post


Link to post
Share on other sites

I doubt that ILP is actually used in xCurrent (it is a custom, ILP-like protocol in atomic mode).

I aslo did NOT talk about xCurrent/Rapid/Via but about ILP: sending a payment on its way sounds a lot more vague now than before, especially after cutting features that are desirable to minimize risks.

Share this post


Link to post
Share on other sites
46 minutes ago, Sukrim said:

I doubt that ILP is actually used in xCurrent (it is a custom, ILP-like protocol in atomic mode).

I have been paying attention to if xCurrent /RippleNet is using atomic or universal mode, and I think this is the 3rd time I've seen ILP Universal mode be the answer.

Although that does not need to be true of RippleNet. Why do you say that is atomic mode?

46 minutes ago, Sukrim said:

I aslo did NOT talk about xCurrent/Rapid/Via but about ILP: sending a payment on its way sounds a lot more vague now than before, especially after cutting features that are desirable to minimize risks.

Right, but the pathfinding/ routing has to be done somewhere, and its clearly not done in ILP alone... we know the set up for xCurrent has a messaging layer in addition to the ledger layer, on top of the ILP layer.

I'm guessing the path is determined at the messaging layer (using all 3 xProducts combined + XRPL).

Then the actual payment only needs to travel forward.. unlike pathfinding which I assume you are familiar with how it goes backwards 1st, then forward. (Same with the Escrow and hashlock set up that is now dead, backward, then forward)

Another thought, for each hop that goes through a banks xCurrent RCL ledger, there can be multi hops within that one ledger (depending on banks relationships) potentially reducing the total ILP hops.

The more I think about it, this set up could actually take advantage of a lot of RCL's features.

Routing done on each ledger, while ILP is just transport.

String a bunch of ledgers' routing efforts together and... seems like it would get the job done?

The Connectors will be making arbitrage / pathfinding / routing, as a function of their businesd on their own ledger anyway. So this makes sense to just let it be, and just let ILP be transport.

Edited by KarmaCoverage

Share this post


Link to post
Share on other sites
8 minutes ago, KarmaCoverage said:

Why do you say that is atomic mode?

 

13 minutes ago, KarmaCoverage said:

Right, but the pathfinding/ routing has to be done somewhere, and its clearly not done in ILP alone...

As far as I understand it, automatic routing is part of Interledger or at least the responsibility of connectors: https://github.com/interledger/rfcs/blob/master/0003-interledger-protocol/0003-interledger-protocol.md

Share this post


Link to post
Share on other sites

That is a good post for any one who has not seen this stuff, from that post.

On 9/28/2017 at 5:32 PM, mDuo13 said:

What may surprise you is that the public ILP specs don't define atomic mode; Stefan, Evan, et al. came to the conclusion that, in order to use Atomic mode, all the participants had to agree on a set of validators and how to choose them. And if you're going so far as to do that, you could also agree on any number of other modifications to the protocol, so honestly, it doesn't really make sense to define a standard that needs you to agree on some other stuff anyway.

Here he says they took our the "routing decisions can happen in the background"...

  • If you back this up for a few minutes before this spot, he explains the Escrow method that they apparently ditched. 
  • Edit: FYI, to avoid confusion, know that this video example is using the now dead escrow method. I think we have to wait for ILPv4 to see the new set up, unless any Ripple folks want to chime in here, probably not for good reasons.

 

...which is why I am saying...

32 minutes ago, Sukrim said:

As far as I understand it, automatic routing is part of Interledger or at least  (routing is) the responsibility of connectors

The connectors are the only ones that know their cost of capital, they are the only ones who can properly price something like a Liquidity Curve, they are the ones with money on 2+ ledgers, they are the ones that are in the business of arbitrage, aka pathfinding/routing, so I think it makes sense to just let them do it.

XRPL can also function as a type of Connector because a lot of ledgers are connected to it, XRPL.... XRPL is the Bridge Connector "bridge currency" in an xRapid payment path.

Edited by KarmaCoverage

Share this post


Link to post
Share on other sites

How can you make sure your payment takes the fastest or cheapest route then or if it for example can't work out at all since there were too many hops (and thus too many fees) in between?

Share this post


Link to post
Share on other sites

You only need to pass it to the next guy and make sure you keep the spread you quoted to the messaging layer. Next connector, the same.

There still has to be some way for the connectors to publish their liquidity and routes, or at a minimum which corridors they have liquidity for, but still got to communicate that spread so the sender knows how much to send to cover fees.

Idk?

Share this post


Link to post
Share on other sites

Still has the risk that while the first hops execute, the path dries up and the payment has to be reversed/sent back. Since there is no 2 phase commit/lockup any more(?) this means that actual settlements happen along the way which are costly.

I get the focus on minimal features, but it seems too minimal for my taste now, since there are now fewer guarantees than what I would expect from payments (either deliver the amount somehow or give the full amount back to me, don't send it around in circles and maybe hand me back less with an error message...).

Share this post


Link to post
Share on other sites
3 hours ago, Sukrim said:

I doubt that ILP is actually used in xCurrent (it is a custom, ILP-like protocol in atomic mode).

I aslo did NOT talk about xCurrent/Rapid/Via but about ILP: sending a payment on its way sounds a lot more vague now than before, especially after cutting features that are desirable to minimize risks.

Adrian and Stefan have been talking a bit about streaming micropayments whereby the consequence of dropping any packet of value failing is small. Smaller, streaming packets distribute volatility over the payment stream as a possible benefit but I agree, this ILP  system looks very different than the coordinated escrow and release along a defined path that was so promising in earlier versions. 

Share this post


Link to post
Share on other sites

If they want to do microtransactions with ILP, they should specify a cross-ledger payment channel mode...

The protocol description in the main repo still contains the 2 phase commit part, but I'm not sure if that's legacy or not. I hope not.

Share this post


Link to post
Share on other sites
20 minutes ago, Sukrim said:

The protocol description in the main repo still contains the 2 phase commit part, but I'm not sure if that's legacy or not. I hope not.

I think it is now.

...and I thought the 2 phase commit was an elegant solution.

Seemed to me he was saying Payment Channels are going to step up to the main stage now, not Escrow.

Edited by KarmaCoverage

Share this post


Link to post
Share on other sites

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

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...