define enlightenment

[michielbdejong]

Maybe something for the glossary -
The way I would describe the 'interledger enlightenment' is the insight that a piece of software like ilp-kit doesn't need to run a connector plus a ledger, it can just run a connector plus many peer ledgers. On each of these ledgers, there would be exactly two accounts: the user's account, and the connector's account. This means the ledger plugin interface does not need to specify to and from, because they would always be implied (from is the party sending the message, to is the other one of the two). So this is only the insight of "let's remove five-bells-ledger from ilp-kit", and the behavior of ledgers that have more than two accounts would not be affected by enlightenment.

@justmoon I noticed that in recent github comments you seem to be using a different definition, namely as an extra constraint on all ledgers, saying that although they can have two or more accounts, one of those accounts is the default connector, of which there is always exactly one per ledger, and all non-local transfers are handled by that default connector.

[justmoon]

Yeah, the original realization was that a connector with a bunch of asymmetric trustlines to other connectors is exactly equivalent to a ledger. So there is no point in implementing a dedicated ledger component (like five-bells-ledger) because a connector with trustlines is exactly the same thing.

The idea of using ledgers as the fundamental primitive was inspired by the Internet, which uses networks as the fundamental primitive. In the case of the Internet, however, this is now considered an unfortunate legacy design choice that we are stuck with.

Avery Penwarr explains what a world without this mistake would look like:

Imagine that we lived in such a world: wifi repeaters would just be IPv6 routers. So would wifi access points. So would ethernet switches. So would SDN. ARP storms would be gone. "IGMP snooping bridges" would be gone. Bridging loops would be gone. Every routing problem would be traceroute-able. And best of all, we could drop 12 bytes (source/dest ethernet addresses) from every ethernet packet, and 18 bytes (source/dest/AP addresses) from every wifi packet. Sure, IPv6 adds an extra 24 bytes of address (vs IPv4), but you're dropping 12 bytes of ethernet, so the added overhead is only 12 bytes - pretty comparable to using two 64-bit IP addresses but having to keep the ethernet header. The idea that we could someday drop ethernet addresses helped to justify the oversized IPv6 addresses.

(Credit to @emschwartz for digging up this awesome post)

Let me translate some of these into ILP-speak:

wifi repeaters would just be IPv6 routers

Ledgers would just be connectors.

we could drop 12 bytes (source/dest ethernet addresses) from every ethernet packet

We could drop the to/from fields from the ledger plugin interface and ledger protocols.

---

The only question that remains is: What if you do need to integrate with a ledger? A ledger being a thing that can do local transfers, but doesn't know anything about ILP. It turns out that you can do this, at the cost of some complexity, in the ledger plugin. ilp-plugin-bells for instance, once it upgrades to LPI2, will need the following logic:

• Check if the ILP destination address is on the ledger. If so, pop the next element after the ledger prefix off of the address and send the transfer to that account.
• If not, send the transfer to the default connector.

In essence, what we are doing is adding a mini-connector to the plugin, because the ledger doesn't understand ILP. This is still much simpler than what we were doing before which essentially amounted to the connector being a "second-order connector". It routed first according to its routing table to the right plugin and then within that plugin to the right to address.

[michielbdejong]

OK, good to know! Thanks.

Then we should probably use two different names for these two concepts ('original/weak enlightenment' and 'advanced/strong enlightenment').

I would argue that the strongly enlightened interledger is compatible with unenlightened interledger, but it only forms one of its regions, for the following reason:

As a user, I have my money stored on a ledger. From there, I want to pay other people, through (in the original interledger vision) trustless connectors. I trust the ledger more than the connector. The worst a connector can do to me when I try to send money through it, is waste my time.

Now imagine the ledger that holds my money decides to upgrade to strongly enlightened interledger. Suddenly, there is only one way to move my money off the ledger: through that default connector. The ledger that I trusted merged with the connector that I previously did not have to trust.

So that's why I would always put my money on a ledger that has several independently run connectors on there; unless all of them fail, my money on that ledger will always be worth something.

[michielbdejong]

Btw, this makes me think of a topic that came up in my 1:1 with @emschwartz, of building a network of ILSPs, all of which only support unconditional payment channels (sender->ILSP, ILSP->ILSP, ILSP->receiver). The users of this network would park their money at one of the ILSPs, and be able to reach all other users of all those ILSPs from there. The maximum payment size in this network would be small, but these small payments could be repeated quickly after each other, because of the fast automatic settlement offered by the unconditional payment channels over which they travel. This would allow users to efficiently send chunked payments, and for this kind of network (in which all ledgers are of a specific type), advanced enlightenment makes sense because each ILSP is essentially a ledger on which only one connector is allowed to operate.

[adrianhopebailie]

I think this discussion is clouded by the fact that distributed ledgers with no counter-party are very different to any other ledger.

With a distributed ledger like BTC, XRP etc account holders trust "the ledger". With any other ledger they actually trust the counter-party that maintains the ledger. i.e. Even if I want to make transfers on that ledger to a connector that also holds an account there, what I am really doing is making a transfer to the ledger owner and they are making a transfer to the other connector.

This is what @justmoon means when he points out that a ledger is often just a connector if you are evaluating the relationships based on trust.

So @michielbdejong 's thesis holds with DLTs but not with other ledgers.

I agree mostly with @justmoon that the key realization we made (and is often referred to as the enlightenment) is that if you look at the Interledger as a graph of nodes and edges then the nodes are connectors (not ledgers) and the edges are actually payment channels/trustlines/accounts between those two connectors (underwritten by a ledger).

[michielbdejong]

A key difference that's introduced by considering the ledger as a first connector is that choosing the first connector after the ledger is then no longer a choice the user (sender) can influence independently from their choice of where they store their money.

[adrianhopebailie]

choosing the first connector after the ledger is then no longer a choice the user (sender) can influence independently from their choice of where they store their money.

They can influence it but need to trust the ledger to follow their instructions unless they use a counter-party-less ledger like a DLT.

There are two different models that seem to be getting mixed up here. There is a trust model and an operating model.

If your ledger is a bank or some other counter-party maintained system then you are trusting that counter-party to not only store your money but also perform transfers as you instruct. You can't just ignore the fact that they also control where your transfers go.

E.g. If you ask your bank to do a transfer to Chloe (the connector) as part of a payment to Bob (the receiver) but instead they do the transfer via Connie (another connector) and the payment still gets to Bob and you get the fulfillment it's possible you'll never know that the payment didn't go via Chloe.

From a technical architecture perspective, most ledgers ARE connectors. The fact that they expose a ledger interface to their peers is an operating decision.

In fact, any connector COULD aggregate all of the accounts it holds with others and expose these as a ledger interface.

[michielbdejong]

Right. I still don't see what you win by making this only-one-connector-per-ledger restriction. It makes interledger more like a specific peer-to-peer payment system, and less like a generic and secure way to interconnect a wide variety of ledgers. A lot of the security of Interledger Classic comes from the fact that if a connector fails you, your money rolls back to the ledger, and you can try a competing connector.

[michielbdejong]

I guess the difference can be interpreted as whether the first hop is source-routed or not, in a way :)

[adrianhopebailie]

@michielbdejong I honestly don't understand what you are discussing here. Nothing changes. You are trying to come up with an explanation for what "Interledger enlightenment" means not change anything about the protocol.

The point that has been made is that the characteristics of a ledger are the same as a connector with multiple asymmetric trustlines. That's only relevant to how a ledger could be implemented (as a specialization of a connector). None of this changes how the entities in these roles interact as part of ILP.

[michielbdejong]

I tried to think of how you would model any ledger as a post-strong-enlightenment "node"; for a receiver this is easy, you can imagine that the ledger itself is a connector, that adds an imaginary extra transfer. For a sender it's harder, you would have to imagine that each connector on the ledger would be on a different "copy" of the ledger, and these copies, which you treat as though they were independent ledgers, are somehow linked so their balances go up and down in unison. I don't find that a very useful way to model the different connectors which may be reachable through what is really just one ledger, so that's why I would reject the vision of "post-strong-enlightenment interledger", and rather speak of "strongly-enlightened ledgers" as a specific kind of ledgers in which some ledger functionalities have been restricted. So let's define:

• weak enlightenment: "in systems like ilp-kit, the use of per-user trustlines instead of a hosted ledger"
• strongly-enlightened ledgers: "ledgers which are only connected to the Interledger through one designated connector; furthermore, users of a strongly-enlightened ledger can only send transfers to this connector (not locally to any of the other ledger users) and can only receive transfers from the connector (not locally from other ledger users)"

[adrianhopebailie]

I still don't understand what you are trying to prove/explain.

When discussing ledgers and connectors we are talking about roles in a system not pieces of software.

You seem to be trying to apply labels to specific ledger architectures but the labels come from logical models. I'm not sure what your goal is.

[michielbdejong]

Let's talk about it on chat tomorrow, I'll try to clarify further.

[justmoon]

I agree mostly with @justmoon that the key realization we made (and is often referred to as the enlightenment) is that if you look at the Interledger as a graph of nodes and edges then the nodes are connectors (not ledgers) and the edges are actually payment channels/trustlines/accounts between those two connectors (underwritten by a ledger).

@adrianhopebailie: Great way to put it 👍

[michielbdejong]

Note that we just changed our definition of the word 'ledger' in the context of Inter-~. It used to mean the medium on which the Interledger transfer happen. Now, it means whatever is the level 1 relationship between two peers (regardless of whether their Interledger relationship is happening on level 1 (on-ledger escrow)
or on level 2 (level 2 = trustline for sendData, level 1 = on-ledger settlement for sendMoney, e.g. Siren)
or on level 3 (level 3 = trustline for sendData, level 2 = paychan claim updates for sendMoney, level 1 = ledger to back the paychan).

If we're mainly going to be working on one-to-one Interledger relationships for the foreseeable future, then I guess it's ok to temporarily deprecate the to field which is only needed if there is a one-to-many relationships at the Interledger level.