- TLDR: Play with an Interledger test network
- Payments on the Web
- Introduction to Interledger
- ILP v IBC?
- How everything fits together
- What's There vs. What's Missing
- How a payment unfolds
- Implementations and Libraries
- Tutorial Material
TLDR: Play with an Interledger test network
To dive in and play with Interledger, make sure you have Docker and Docker Compose installed, then follow the directions at https://github.com/adaburrows/interledger-testnet-docker.
Payments on the Web
In 1989, the hypertext system that powers the web was envisioned by Tim Berners-Lee and co. In 1991, Berners-Lee announced the first publicly accessible web. In 1994, Berners-Lee created the W3C (World Wide Web Consortium) to steward the standards for the web. Here we are 26 years later and we are only now in a position to start standardizing payments on the web.
What has taken so long? People had to get to used to the idea. It took merchant services allowing people to pay online with credit cards. It took PayPal, Cash App, Venmo, Facebook Payments, and who knows what else. It took online cryptocurrencies to get the conversation started on how to make payments work online across the multitudes of networks we've created.
But here we are at the end of the year 2020 and on the W3C site there are now a few drafts all based around standardizing payments on the internet. As these are drafts, they are subject to lots of change, including potential abandonment (if consensus around forward movement can't be reached), until they actually become standards. Fortunately, some of them currently have a decent amount of support behind them in the form of Google, Microsoft, Ripple, Coil, and the Interledger Foundation.
Payment Request API — This is a draft browser API which allows sites to describe what is being paid for, request a payment, and allow the user to choose a particular payment method from those accepted by the website. Also allows website to ask for a shipping address. Interledger could be used with this, but a payment handler needs to be defined to handle sending the money over ILP and the ILP connector receiving the money would likely need to handle receipts (but that's a detail for later).
- Payment Handler API — This is a draft browser API which allows service workers to be extended for handling specific kinds of payments. It also exposes a PaymentManager API which allows the Payment Request API to know how to display the payment instrument the payment handler supports.
- Payment Method: Basic Card — Specifies how basic card payments, such as Visa or Mastercard, should upfold with the Payment Request API.
- Interledger Payment Method — Specifies how Interledger payments can unfold with the Payment Request API.
- Payment Method Manifest
- Web Monetization — This is a parallel standard to the Payment Request API. It allows websites to specify a Payment Pointer and compliant browsers or browsers with the correct plugin will be able to start streaming Interledger payments to the site immediately without any user interaction. The work on this standard may inform work on the above specifications.
Introduction to Interledger
Interledger is a protocol suite and set of software implementations for routing and clearing payments through a distributed financial architecture, while simultaneously allowing many entities to maintain liquidity and distribute the risk of clearing and settling payments. It also has ability to automatically settle those payments through many possible underlying systems, which may or may not include various blockchains. It is akin to the Automated Clearing House (ACH) in the USA, the EBA Clearing network in the Single European Payment Area (SEPA), AusPayNet in Australia, VisaNet, and SWIFT for international transfers. It is more flexible in its design the the above, and can actually be seen as an upgrade to ISO8583 (financial card spec with a hierarchical addressing scheme; e.g. credit, debit, or gift cards).
The chief differences between other payment systems and those implemented atop Interledger's protocol suite is that:
- Interledger aims to create a distributed network of exchanges instead of central ones. In effect, it wants to democratize sending and exchanging money so whoever wants to participate may do so. However, there are hurdles which will be covered later.
- Interledger sends payments that are broken into as many little small payments as possible — or in their words "packetized payments". These "packetized payments" could then be routed across many nodes in the network thereby reducing the inherent risk or chance of failure in processing one larger payment across the Interledger network. This means that it is not a clearing protocol in the traditional sense, as it may take time and much network traffic to clear a large "packetized payment". The end result, should be the same.
- Additionally, Interledger claims to implement "trustless sending" where a sender can send payments over the network without having to trust any of the connectors along the way. This is accomplished through some basic cryptography agreed upon by the sender and receiver through the SPSP protocol. While all the "packetized payment" transactions may clear and show up as being agreed to by all the connectors along the route to the destination, the connectors themselves need to trust their peers. If a settlement doesn't happen, then the situation is sorted out between the two peers in their existing relationship.
In ILP these "packetized payments" contain several fields:
packetType(UInt8) — The value 12 in the case of a prepare packet, see its definition.
amount(UInt64) — An unsigned integer in a currency predefined by the account set up with the current connector node. The account has an associated asset and scale which define the meaning of the amount.
expiresAt(InterledgerTimestamp) — The expiration for the completion of the the transaction. This value is reduced at each hop along the route.
executionCondition(UInt256) — The cryptographic condition used for "trustless payments".
destination(ILPAddress) — The destination address used for routing.
data(variable length octet string) — End to end data which should be encrypted.
As the value field is only one integer value, its asset type and scale is determined by the peer relationship. This value will need to be exchanged into a new value before being passed onto the next hop in the route. The exchange rates can either be predetermined (like hours worked converted into currency, or a pie converted into a price in a currency) or they can be looked up via API calls for current forex or crypto exchange rates. Since each connector knows what the local currency is for the accounts held with other connectors, the conversion is straight forward.
ILP v IBC?
ILP is great for doing anything analogous to exchange of currency, while IBC is useful for making assertions about holding non-fungible assets (AKA non-fungible tokens) on a different blockchains than it is actually held on.
Interledger has changed greatly since its inception. These changes are key to understand the quirks of specific implementations of Interledger. To fully understand this takes some sleuthing and investing a large number of hours to go through the available material. Here's a collection of links that shows all the relevant inflections so far: The Flow of Thought (Historical Discussions)
When it was initially conceived, the main analogy of ILP (Interledger Protocol) was the Internet Protocol (IP). The analogy went sort of like this: IP allowed internetworking of networks to create a network of networks where messages could traverse the different networks and reach their destination, no matter what network the message originated from or to which network it was addressed. Interledger, then, would allow the traversal of money from one ledger into another and so on until the money finally arrived at the destination ledger. Much of the talk took the analogy, perhaps, a little too far. There were charts comparing different levels of the stack to the OSI model.
In practice, the whole OSI model comparison doesn't work out. This is because:
- ILP is firmly in the application layer of the OSI model, and not really truly a transport level protocol. It is an overlay network which defines the flow of information between connected nodes based on certain criteria, but still relies on IP to transport and route the information between nodes.
- It's very difficult to exchange cryptocurrencies that each have potentially incompatible rules for writing transactions to the blockchain. Additionally, the different blockchains are completely separate resources and are not completely fungible. People have attempted to get around this with sidechains, but they are even more technologically complicated than a single blockchain since they require multiple layers of blockchains. Sidechains also lock away potential liquidity in a way not typically done with other fungible tokens by banking systems. Polkadot and Cosmos provide a layer of interoperability between all of the applications specific blockchains which exist in parallel within their respective networks. This is simple compared to sidechains, but still only works within those respective networks.
- For more overview of this problem space see: Belchior, R., Vasconcelos, A., Guerreiro, S., & Correia, M. (2020). A Survey on Blockchain Interoperability: Past, Present, and Future Trends. arXiv preprint arXiv:2005.14282.
- Most currencies act like matter and energy, not abstract data. They are conserved (Ripple might be an exception) and were originally designed to be durable. Typically, currencies are minted, entered into circulation, and then traded for value, but they aren't normally destroyed (except in certain monetary policies). Value can never really be transferred from one currency to another (there's some nitpicking we could do around this, because it does depend on the currency). The exchange of one currency for another does not require the destruction of one currency and creation of another currency, it rather requires someone holding a pair of currencies to agree with another person to exchange one currency for another at a specific exchange rate. The exchange then takes the original currency, adds it to it's reserve of that currency while subtracted the exchanged currency from it reserve of that currency. There is always a risk of loosing liquidity in these exchanges if the flow of value doesn't happen both ways. However, if enough people peered and multi-path routing was implemented for Interledger, there may always be enough sources of liquidity distributed throughout the network.
- For more background on theory of money see Andolfatto, D. (2009). What is Money? How is it Created and Destroyed?. Mimeo.
- For more on currency exchange see Chen, J. (2020) Foreign Exchange (Forex) Definition. Investopedia. and Weithers, T. (2011). Foreign Exchange: A Practical Guide to the FX Markets. Germany: Wiley.
How everything fits together
People, companies, payment providers, crypto wallet providers, banks, or whatever other entity who wants to be a part of the network must peer their connector with another connector. This process is roughly:
- Establish an Interledger address for the organization (and therefore for all their child accounts).
- Connect to peers through a VPN or at the very least using TLS client certificates with verification enabled to ensure both encryption and that peers are who they say they are.
- Set up an account in the accounting module for tracking accrued balances between connectors over specific assets and scales. This is needed for settlement.
- Set up the wallets for specific digital currencies used to settle between peers.
- Set up the settlement engines which will be used to transfer the value between peers on the underlying shared ledgers using the newly set up wallets.
Each node/connector also uses other specific protocols for maintaining configuration, routing, and connections with other linked nodes. The protocols used for achieving this are:
- Interledger Protocol V4.md — The basic underlying protocol used in the network as a frame for all other ILP based messages.
- Dynamic Configuration Protocol — Used for configuring child connector nodes.
- Bilateral Transfer Protocol — This is the main protocol for connectors to communicate with each other. It also used to be used for settlement plugins, but now those used a plain HTTPS interface.
- Route Broadcasting Protocol (RBP) — The draft specification of how route discovery works.
- ILP Over HTTP — This allows ILP to be used over HTTP(S) instead of websockets. It allows scaling the infrastructure a little better, see Evan Schwartz. Thoughts on Scaling Interledger Connectors. Interledger Blog. 2019/01/22.
Applications then use the above protocols and additional protocols (some built on top of other IL protocols) to initiate payments across the network:
- STREAM: A Multiplexed Money and Data Transport for ILP — This is a quite rich protocol used for communicating between financial applications with ILP.
- Payment Pointers and Payment Setup Protocols — A specification for how to use easy to remember strings (Payment Pointers), which dynamically resolve to an ILP address.
- Simple Payment Setup Protocol (SPSP) — A protocol for sending payments.
- Web Monetization — A simple specification for allowing web sites to be payed over ILP.
- Open Payments — A new application level specification for initiating payments the extends SPSP.
PayID — A slighly more flexible version of payment pointers. It does not require Interledger. People in Australia cannot use it do to a legal issue.
- It's PayString now?
- Identity, Authentication, and Authorization protocols — curiously absent from most of the discussion above is the layers of the applications which provide security and identity.
OAuth — Most applications will use some form of OAuth 2.0 to secure apps.
- Open ID Connect
- OAuth 2.1 — this is a rework and simplification of the spec to make it easier to follow OAuth as current best practices with all of the amendments added in.
- OAuth 2.0 Rich Authorization Requests (RAR)
- OAuth 2.0 Pushed Authorization Requests (PAR)
- The Case for OAuth 3.0 — background reading for what's been changing in OAuth world.
- Grant Negotiation and Authorization Protocol — work on a protocol that will likely replace the above which has grown out of Tx Auth, RAR, PAR, XYZ, and 3.0.
- OAuth — Most applications will use some form of OAuth 2.0 to secure apps.
Example applications would be:
- An ILP enabled wallet, like Uphold
- A Web Monetization provider, like Coil, which sends money from a $5/mo subscription to a website owners wallet over ILP
- An online shopping cart which requests money from you ILP enabled wallet.
- A bluetooth enabled app which sends money from your ILP enabled wallet to a street performer who is running the app and also has an ILP enabled wallet.
- A contract platform that creates ILP addresses for web content and splits the money between parties according to the contract and automatically pays into their ILP enabled wallet.
For the official overview, you can take a look at:
What's There vs. What's Missing
First, let's look at what is there and implemented:
- The suite of protocols is relatively stable at the moment, but since it's a dialog it will be subject to change as different applications start using it and finding things that need to be changed.
- As far as being a way of communicating financial messages, the current implementations work and do communicate messages over secured networks.
- There is a nascent network of nodes creating the Interledger network. It includes players like Coil, Uphold, Gatehub, and Ripple. Because of Uphold and Ripple there's a decent amount of liquidity in the network already.
- Centralized wallets like Uphold and Gatehub provide Interledger integration and then some.
- The only payment provider at the moment is Coil, but with Coil and Uphold there is a functioning ecosystem. See Wright, Turner. (2020) Coil Creators Can Now Receive Payouts Using Uphold Wallets. Cointelegraph. May 20. and Johnson, Cory. (2020) Full Court WordPress: Coil Deal Boosts Functional Blockchain — And XRP. Forbes. May 19.
So what's missing?
- More materials on how to get up and running with Interledger and how to set up test networks.
- I've linked to the available materials below.
- More tutorials around building Interledger apps and wallets.
- For Web Monetization Providers, see the Web Monetization Implementations list for details.
- For wallets, this is what is in the community that I've found so far, obviously only accessible to people who can look at code and see what it's doing.
- For other apps, there's likely work around Open Payments which will be applicable.
- More settlement engines to support more ledgers.
- Only XRP, Etherium, Paypal (business accounts only), and Bitcoin over the Lightning Network (via the old plugin architecture) have settlement engines. But anyone can write one. See the implementations for more details.
- More Interledger enabled wallets. Part of me wants to see Interleger easy enough to integrate in any wallet, but perhaps keeping a small active value in centralized wallets while storing larger sums in personal wallets on the specific ledgers one uses will be the way forward.
- More payment providers in order to make a more thriving economy.
- Thought around alternative currencies/values (though in some ways, we are going to tackle a portion of this).
- A secure routing protocol, as the same flaws that can happen with BGP can also happen with ILP routing.
- A better accounting engine (though there seems to be work on this).
How a payment unfolds
Implementations and Libraries
As the core of the work around Interledger has been the protocol suite, there is no one implementation of the software. There are currently around 4 reference implementations (called Connectors). Each implementation is in varying levels of completeness and compliance with the new protocols. So far there are implementations in three languages. Libraries have also been built in those languages.
This still doesn't have all of the material for creating applications that interact with an Interledger implementation and the underlying wallets and settlement layers, but those are next steps.