Network Ledger Technology
Fifteen years ago, I used to live in Spain, and pay my rent on foot. Online banking existed, but costed one euro per bank transfer - and (ridiculously) 1.50 if part of a recurring payment. I didn't want to pay 1.50 to my bank each month, so instead I would exchange my bank account balance for actual bank notes, walk to the closest branch of my landlord's bank, and deposit it there, making his bank account balance go up.
The value bank notes have is already a social construct. But when you pay your rent using online banking, or with a recurring payment, your bank does not even transfer such bank notes to your landlord's bank. Instead, a network transfer is executed, and debt amounts in the databases ("ledgers") of both banks change, but you're not directly using currency when you make a payment through the banking network.
In 2004, Ryan Fugger wrote a paper explaining how payments through a social network could work in the same way as payments in the banking network. A ledger is just a database that keeps track of debt between people. It works with an append-only list of transactions that change the account balance. Your bank keeps a ledger with all the bank accounts of all its customers. But a tab behind the bar in your favorite cafe, a piece of paper tracking what you owe your friends while you're on holidays together, or the database of a community currency ("LETS") system, can also be seen as a ledger.
What Fugger realized is that by exchanging messages, a network of ledgers could work together to create an experience as if you were transacting on a single network-wide ledger. He first implemented RipplePay, a single-server version of this idea. Although it didn't send network messages yet, it demonstrated his idea that the trust that is inherent in a (social) trade network can be used to coordinate that same trade, without the need for a separate network of banks. And with that, the field of Network Ledger Technology was born.
Multihop
In its most basic form, Network Ledger Technology (NLT) is any form of messaging that allows for "money transfer withouth money movement": Alice pays her agent, who does not forward the money itself, but instead sends a message to Bob's agent, and Bob's agents pays out an equivalent amount of money to Bob. The Hawala network already implemented this, and of course, so does the correspondent banking system.
But the true power of NLT becomes apparent when three or more agents can sit inbetween Alice and Bob, so that there are multiple message hops involved.
In 2008, it was again Ryan Fugger who first proposed the two-phase commit system, using conditional transfers and staggered timeouts: first, each node along the route promises to pay the next node if a delivery receipt is presented. The destination node presents the delivery receipt, and this receipt is passed back along the path. If no valid receipt from the destination is presented within a certain timeout, all conditional transfers are rolled back. A good explanation is found in Adrian Hope-Bailie's blogpost "the power of conditional payments".
Although the delivery receipt could be implemented using a cryptographic signature, in 2012 Gregory Maxwell invented hashlocks as a simpler option, and nowadays, most message-based NLT systems use SHA256 hashlocks to implement the two-phase commit: the promise specifies the SHA256 hash of a secret string. The commit message coming back carries that secret as the delivery receipt.
Payments
When using multi-hop transfers to implement payments, the sender should somehow indicate where in the network the intended recipient can be found. Fugger's hypothetical interserver Ripple system would have used KnowledgeRouting and cells. In 2017 at the Interledger project we implemented something quite similar, called Liquidity Routing, using hierarchical addresses, route broadcast messages that described the exchange rate and maximum transfer amount, and quote requests that could explore connectivity and fee information before a payment was made. Something similar was implemented in the Mojaloop network.
Around the same time, Stanislas Polu developed SettleNetwork, which uses Scrypt as the hash function for the hashlock on multi-hop transactions, and no explicit timeouts. It uses a routing model where all servers ("mints") have knowledge of all exchange offers.
A quite different but remarkably clever approach to using Network Ledger Technology for payments is the Lightning Network: there, connections in the network are not trade credit relationships, but random connections between strangers, backed by a layer of Distributed Ledger Technology (DLT), namely the Bitcoin ledger. Onion routing is used to anonymize payment traffic. Pathfinding in the Lightning Network uses route broadcast messages and routing hints in payments replace the role of Fugger's cells and Interledger's address prefixes.
On one side of the spectrum, Lightning Network does not use the trust between people, and only serves to increase the performance of the underlying DLT system. One interesting consequence of the random connections and onion routing is that when you forward someone else's payment in the Lightning Network, even if you are being paid a commission for doing so, you have no way of knowing who your customer is, and so in a sense, you are not offering a money transmission service.
At the other end of the spectrum are commercial banks which are tightly regulated, and it's Ripple.com (the startup born out of the Ripple project) who are now pioneering the multi-hop feature there too (full disclosure: I recently worked at Ripple.com, on their Interledger/R&D team).
For most other NLT systems in between, a network participant will probably need to take some responsibility for which payments they forward, and this sometimes makes it a bit harder to convince people to configure their NLT node as an open relay.
Streaming
In 2018, Evan Schwartz drastically simplified our Luxembourg Interledger system and proposed its successor: ILP/STREAM. It allows users to resolve debts bit-by-bit using "chunked payments" instead of all-or-nothing payments.
Since the payment chunks are so small and generally occur in streams with lots of other small payment chunks to the same destination, it's not necessary to keep track of price information in the routing table. Instead, streams can start splitting over multiple paths, and whichever path proves more reliable and cheaper, receives more and more traffic as the stream continues. ILP/STREAM does use hierarchical Interledger adresses for pathfinding, and uses SHA256 hashlocks to let multi-hop transactions "ripple" through the network.
An additional advantage of allowing only many small payments is that a link in the network can efficiently be implemented using an unconditional payment channel on top of a DLT layer. After each small payment, a new payment channel claim can be exchanged, which resets the trustline between two nodes, thus allowing for one-way traffic with many times the value of the maximum trust limit between the peers (as long as both trust the same DLT system).
Coil.com use ILP/STREAM to offer a flatrate donations platform.
Debt loops
Taking the idea of streaming payments one step further, NLT could also be used to settle debt loops. In a way, in-network multilateral netting is the ultimate way to coordinate trade, since no payment services are needed. The flows of goods and services are not traded against counter-flows of money, but are written down in one ledger per trade relationship, and then netted out directly between themselves.
The idea of "Federated LETS", or " a mutual credit system of mutual credit systems" has been labeled "intertrading" in Credit Commons, a project and protocol pushed forward by Matthew Slater and Tim Jenkin. Tim Jenkin's Community Exchange Systems has been practicing intertrading since 2004, and Matthew Slater has been working on Credit Commons since 2008, with the Credit COmmons Whitepaper (pdf) published in 2016.
In 2011, I published the OpenTabs idea, which promoted leaving debts unpaid, but also had a handwavy idea of loop detection by sharing your friendlist with your close friends.
In 2016 I rebooted the OpenTabs project under the name LedgerLoops, and included a more detailed (but unfinished) distributed loop detection algorithm, and an implementation of debt loop resolution using circular hashlock transactions.
In 2018, I implemented an improved loop detection algorithm based on probes, and drafted an idea for netting at equilibrium.
Whereas in general LedgerLoops does not support exchange rates or transaction fees, with netting at equilibrium, each node considers its neighbors as potential trade pairs.
A node would be willing to trade between any two of its neighbors, but can demand any exchange rate they want. If a node wants a trade to happen, they can slowly improve their exchange rate offer for that pair, until payments start flowing over that path. The idea is that whoever is in more of a hurry to get rid of a certain debt, can cross the spread to make the debt resolution happen. This would still not count as money transmission, since each node is only exchanging their own credit with their own direct neighbors, not offering a service for a stranger.
The main problem with using an NLT system that only supports debt loop resolution and/or streaming, is that it's not usable as a payment system. For instance, when buying a coffee in a cafe, you want the debt to be settled in a matter of seconds, not a week later. Otherwise you would have to stay inside the cafe for all that time, or the cafe has no guarantee of payment before you leave. So you would want the entire debt of the coffee to be settled quickly. Also, if no multi-hop path can be found for the payment, or if the best exchange rate is not good enough, you want to have the option to pay another way, and not end up stuck with a partially settled debt to the cafe.
NLT-KIT: A Strawman Project
Fugger's hypothetical interserver Ripple System was never implemented. Since then, we've seen quite a few projects that propose a central database to which people can submit their IOUs (the Ripple Users mailinglist contains a lot of references to people's personal projects), but not many message-based systems that are not tied to a specific DLT ledger like Lightning.
It seems that SettleNetwork and the ilp-kit stack we developed at the Interledger project were the most advanced working implementations of a purely message-based Network Ledger in the sense of Fugger's seminal paper. But even though a fully functional implementation of SettleNetwork is available on github, the website no longer seems to be operational. And ilp-kit has now been deprecated and superseded by ILP/STREAM.
This means that something that's currently missing from the field of Network Ledger Technology is a good strawman project that implements simple all-or-nothing payments based on interserver messaging.
Therefore, I decided that apart from working on LedgerLoops, I will also work on a fork of ilp-kit, which I called NLT-KIT. The basic idea is to form a network of SNAP links and use landmarks as routing hints. To simplify the technical requirements and to discourage speculation, all multi-hop transactions in the NLT-KIT Network should have the Unicurn as their unit of value. NLT-KIT will be my attempt to continue developing the original Ripple Classic vision that started the exciting field of Network Ledger Technology, now almost 15 years ago. To discuss NLT-related topics with (hopefully) you, I created the Network Money mailing list.
Conclusion
Network Ledger Technology (NLT) is an exciting new field of research, and a lot has happened in various small research projects over the last 15 years. Currently, there are roughly five active projects:
LightningNetwork (NLT on top of Bitcoin), TrustlinesNetwork (RipplePay in an Ethereum contract) and NLT-KIT (pure messaging) are being developed for all-or-nothing payments. ILP/STREAM is being developed for streaming and chunked payments. And finally, LedgerLoops is being developed for debt loop resolution.
This blogpost is my initial overview of the field, please say hi on the Network Money mailing list if you are also working on ideas around Network Money, or you know of any other NLT projects or developments that should be mentioned in it!