Proposal for ILP v4.1 (postponed indefinitely)

ILP v4.1.md

EDIT: This proposal has been postponed until more people are interested on working on it again.

Here's a proposal to amend ILP v4, so that it can still do everything we want it to do, but doesn't send the original Interledger vision to the proverbial graveyard. ILP v4.1 is identical to ILP v4.0, with an extra to field added to the Prepare. This extra field can be used for two things:

for hosted ledgers

I discussed this with Evan, and he replied that hosted ledger operators will not allow third-party connectors on their ledger. But who are we to restrict that? I think it would be great to be able to trust one party for the ledger role and multiple unrelated parties for the connector role, with rollback to the ledger's safety - that's what the original Interledger dream was, and that's the more generic setup. And note that enlightened hosted ledgers, where there is just one connector (operated, or at least elected, by the ledger operator), will still be supported just as easily in ILP v4.1! :)

for distributed ledgers

For ledgers like XRP, it doesn't make sense to have just one connector. The to field would specify the connector of your choice.

ILP v4.0 proposes to avoid on-ledger escrow, and use a payment-channel-backed account at a connector instead, for fast small payments, and this will still be supported by ILP v4.1.

We're only adding one nullable field, so everything that can be done with ILP v4.0 can also be done with ILP v4.1. But the opposite is not true. ILP v4.0 gives up on the original Interledger dream of payments (tiny or otherwise) to any receiver on any ledger through a trustless connector.

Of course, ILP v4 introduces an awesome new dream, namely fast payments for tiny amounts. But having a new dream isn't a good reason for giving up on the existing dream of any-size payments to anywhere, and I, for one, prefer 4.1 over 4.0. Is there is at least one other person in the research team who feels the same way?

I am strongly against this proposal.

Right now there are no ledgers that are fast and cheap enough to make on-ledger transfers as part of an ILP flow practical, so this is purely for ledgers that could theoretically be built in the future. If someone were going to build a system to integrate with ILP, I think it is much more likely that they would build a connector instead of a ledger anyway (because then they're also part of Interledger routing). If someone wanted to build a fast, cheap ledger that was unaware of Interledger routing, they could trivially add a to field to the protocol you use to speak to it so this field definitely does not need to be in the core ILP protocol packet.

I am strongly against this proposal.

I agree to disagree. :) I'm curious where the others stand on this.

Right now there are no ledgers that are fast and cheap enough to make on-ledger transfers as part of an ILP flow practical

For tiny amounts, I agree that connector accounts (where the ILP flow is trust-based/unsecured, and settlement happens outside the payment flow) are faster than on-ledger escrow, but for hosted ledgers, restricting the number of connectors to one will not change the speed of that ledger.

restricting the number of connectors to one will not change the speed of that ledger

What is the point of talking about or designing for ledgers that are too slow to participate in the transaction flow anyway?

Personally I would prefer an ILSP that does a good job of maintaining competitive connections and using all of the information at their disposal to figure out the best routes for me, rather than one that makes me choose the next hop for myself.

As I understand this proposal, it sounds like you're proposing a move closer to source routing. While the current version of the protocol allows each participant to pick the next hop (by choosing which link to send the packet over), this would allow each participant to pick the next two hops (by choosing who the next link should send to).

If we assume the sender has better information than their ILSP does, this would make sense. The ILSP would hold balances with many customers, but would know nothing about routing. When you ask it to send to someone who isn't their customer you need to tell them which of their clients to forward to. I think this is a pretty rare case, though, because the ILSP offers connectivity as their main business.

I discussed this with Evan, and he replied that hosted ledger operators will not allow third-party connectors on their ledger. But who are we to restrict that?

I don't think that's the right way to put it. Regardless of whether we're talking about ILPv1 or ILPv4, the ledger is a connector. The ledger can always charge a fee to send from one account to another. The only difference brought up here is whether the ledger operator keeps routing information, or whether the customer keeps routing information.

The purported advantage that ILPv4.1 offers is the ability to have routing information that overrides the ledger operator's. But there's no way to prove that the ledger operator forwarded to the connector you asked for, so you can't actually override their routing decision. It's more of a routing hint. So it doesn't work for the case where the users want to overthrow an unfair connector; they still have to switch ILSPs.

If we imagine the ILSP wants to allow their users to specify routing information, I think that's possible within the current setup. You could go to your account with your ILSP and tell them "forward my traffic to this client of yours instead of your ordinary routes". This could be something like an advanced feature. You just wouldn't be doing it in the flow of every payment, because then every client application you run would need to have special routing information.

In short, I think there's definitely use cases for some user-specified routing hints, but I don't think they belong in our core protocol, nor would they meaningfully affect the incentives or security guarantees of the network.

@sharafian thanks for writing up your position statement! I think you are trying to fit everything into enlightened interledger (which I agree, doesn't fit, but that's the fault of the enlightenment restriction, not of interledger). To compare, one of the first sentences of the original whitepaper is "Ledger-provided escrow removes the need to trust these connectors.", so definitely multiple connectors per ledger.

Yeah, the pre-enlightenment view is that the ledger had many accounts and some of these could be connectors.

The post-enlightenment view is also that the ledger (which is now just another connector) has many accounts and some of these can also be connectors.

The only difference in the post-enlightenment view is that you speak ILP to your connector-formerly-known-as-ledger, rather than a ledger protocol with a to field.

You can see these old ledger protocols with to fields as one routing protocol, which describes how to do a single hop payment (from one account to the ledger to the next account). ILP has another routing protocol, which describes how to do an arbitrary number of hops using Interledger routing. ILPv1 essentially used two routing protocols, because everyone would alternate between ledger-routing to pick the next account and interledger-routing to pick the next connector.

Now we're just unifying them into one. I agree that the ILPv1 way enables you to separate good ledger operators from good connectors, and there could potentially be scenarios where that would be desirable, but I think in almost all practical cases those are going to be the same people.

I agree that the ILPv1 way enables you to separate good ledger operators from good connectors, and there could potentially be scenarios where that would be desirable, but I think in almost all practical cases those are going to be the same people.

Good, so then at least you agree that 4.1 is strictly better than 4.0 in at least some cases. At the same time, 4.0 offers nothing that 4.1 cannot do. So that's an easy choice, then. :)

Even if what we are currently building with ilp-kit, tf-connector, amundsen and quilt are nodes in a peer-to-peer network as described in my Berlin slides about enlightenment, and even if it's sometimes hard to find ledgers which we can interconnect, I don't want to give up on our vision of interledger as a internetworking gateways that connect ledgers, as described in our main slide deck from last year (and no, saying that peers can choose which ledger they settle over is not the same as actually interconnecting those ledgers securely).

However: unless there are more people within the research team who feel the same way, I'll just give up on this, and then the internetworking project will just be "paused indefinitely", maybe to be revived some day, maybe not, while we work on the new peer-to-peer network vision instead. If really want to stop working on the internetworking vision, then the 4.0 option is good enough.

You can still get the benefit you want (selecting a connector) without adding a to field. All you need is to do the routing in the plugin, the same way we do with ilp-plugin-mini-accounts for example.

On five-bells-ledger, for instance, when you get a prepared payment, you simply look at the connectors field and route the packet to the first entry. (That was the behavior in ILPv1.)

Whatever logic you want for choosing a connector can just as well reside in the plugin. Only the plugin knows what connectors there are anyway, so there is no benefit in telling the connector such that the connector can then tell the plugin which one to use.

I don't want to give up on our vision of interledger as a internetworking gateways that connect ledgers

We are not giving up on that vision in my opinion so let's be specific. If you're just worried about being able to select the connector, see my explanation above on how to do that in the plugin. If you're worried about other losing other specific benefits, let's talk about them.

The reality is that existing ledgers are slow and expensive. That leaves us with several options:

1. We can use the slow and expensive ledgers as they are, thereby making ILP itself slow and expensive.
2. We can wait for ledgers to improve, provide native escrow, get fast, etc.
3. We can net settle, using payment channels to reduce risk where possible.

In my opinion, option 1 is just not acceptable. There is no point in working on a protocol that provides a poor user experience for most people because most people will not adopt it.

Options 2 and 3 are compatible with one another and this is what we're betting on with ILPv4. We can net settle for now which gives us a good user experience today. As ledgers get faster and cheaper we can add them to the flow. Presumably, if they are getting faster and cheaper it will be in part because they want to be in the flow of ILP payments, so it's not much of an ask for them to also speak ILP and just be connectors. But even if they aren't, ILPv4 can still support them using a virtual connector in the plugin.

There is an interesting social/psychological phenomenon happening here I think. The phrase "connecting ledgers" was a symbol we created to capture how we were planning to achieve the ultimate goal of making people's lives better by making it easier, faster, cheaper to move money and other forms of value around. Are we still "connecting ledgers" - maybe yes, maybe not, that's semantics. But what's important is that this was never a "good" in its own right. "Connecting ledgers" is only a virtue insofar it is a link in a chain with some ultimate goals such as making more people healthier, happier and so on.

The same thing happened with blockchain. For a while, I and a few like-minded people thought that decentralization was key to lowering the cost of payments. So I would go around praising decentralization and listing the benefits that it would have. Nowadays, I think that the benefits that decentralization is associated with largely derive from competition which may or may not coincide with decentralization. But I find myself arguing with people who are arguing for "decentralization" itself as if it were a virtue all on its own.

That's why I think it's important in discussions like this to make very explicit the full logical chain leading to the ultimate goals we are trying to achieve. If you like interconnecting ledgers because it gives users control over one more hop - that is absolutely something that we can support in ILPv4 if we can agree that it leads to further important goals down the line.