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?

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.