Adaptive Leadership for Technical Projects
The best way to reach out is via e-mail.
Notes: Interledger Architecture
What is Interledger?
Interledger is an open protocol suite for sending payments across different ledgers. Like the Internet, connectors route packets of money across independent networks. The open architecture and minimal protocol enable interoperability for any value transfer system.
Interledger is not tied to a single company, blockchain, or currency.
The architecture consists of a conceptual model for interledger payments, a mechanism for securing payments, and a suite of protocols that implement this design. The Interledger architecture is heavily inspired by the Internet architecture described in RFC 1122, RFC 1123 and RFC 1009.
- Sender: one who sends the money
- Receiver: one who receives the money
- Connectors: forward the money through the network from sender to receiver. Can charge fees due to assumption of risk for forwarding packets. Expected to compete with one another for reliability, cost, speed, etc. Connectors are responsible for validating fulfillments in the Interledger Protocol layer. Connectors that fail to deliver the fulfill packet in time may lose money.
- Node: any participant. Can be a sender, receiver, or connector
- Accounts: “edges” of the connection graph, connecting nodes
Comparison to Traditional Banking:
The layers of Interledger are similar to the different layers of traditional inter-bank systems:
- Interledger’s Application layer serves a similar purpose as messaging in banking terms.
- Interledger’s Transport and Interledger layers combined are similar to a clearing system in banking, though there are some differences. (For more details, see IL-RFC-32: Peering, Clearing, and Settling.)
- Interledger’s Link protocols don’t have a direct banking equivalent, but they provide authenticated messaging to enable the * * * * Interledger Protocol layer, and they also associate settlement events in the underlying ledgers to balances in the Interledger Protocol layer.
- The underlying Ledger systems are equivalent of settlement in banking terms.
Layers of the Protocol
Starting from the bottom. TODO: Layer picture
Existing money systems that interledger connects. Settlement of obligation agreements must be made in advance. Settlement for one account MUST NOT depend on the status of any other accounts, due to the threat of cascading risks and failures. They can also choose to never settle their obligations. Recommendation: use Settlement Engines
Provide two-way authenticated communication between account holders. Links Link convey packets of Interledger Protocol data and nformation on the settling of outstanding balances. IL-RFC-23: Bilateral Transfer Protocol defines a link-layer protocol that communicates this information over WebSocket.
The Interledger Protocol v4 is main event. Its packets pass through all participants in the chain. This level is concerned with currency amounts, routing, and whether each step in a payment arrives in time or expires. Finds the correct path and contains a cryptographic condition whose fulfillment is only known to the recipient (and possibly the sender).
Optimized for routing large volumes of low-value packets known as “penny switching.”
- End-to-End Principle
Used for end-to-end communication. Defines condition and fulfillment. Groups packets. Determines exchange rate. Encrypts and decrypts data. Example: the STREAM protocol.
The sender and receiver for a payment define the condition and fulfillment for each packet using a Transport Layer protocol.
Deals with everything else besides minimum-viable stuff for payments: account discovery, negotiation, transport selection, other info in ILP packet data i.e. invoice IDs. Example: Simple Payment Setup Protocol (SPSP)
Interledger Protocol Flow
Interledger moves money by relaying packets. They come in three types:
- “prepare” - Moves from sender to receiver across connectors. represents possible movement of money and a condition for releasing it. Interledger uses the digest of the SHA-256 hash function as the condition for prepare packets.
- “fulfill” - moves from receiver back to sender across connectors. Represents confirmation and acceptance of transaction. The fulfill packet contains a valid 32-byte preimage for the hash specified in the prepare packet.
- “reject” - Connector or reciever can reject packet for any reason, or the packet can expire
As the packets move between sender and receiver, the connectors make necessary charges and currency conversions as they deem necessary.
Transactions can be broken up into multiple packets. Small packets have multiple benefits TODO: unpack things like “free option problem”, lower barrier to entry for running a connector, and faster settlements. No size limit on packets in the protocol, but connectors can set them
Interledger addresses are hierarchical, dot-separated strings where the left-most segment is most significant. An example address might look like:
If two parties in the Interledger have a “parent/child” connection rather than a peer-to-peer connection, the child can request an Interledger address that is under the parent’s address in the hierarchy. For more information, see IL-RFC-31: Interledger Dynamic Configuration Protocol (ILDCP).
Everybody only needs to trust their direct peers. Risk can be mitigated based on chosen direct peers. Conditional transfers or authorization holds, equivalent of a two-phase commit are used to secure transactions. The specifications in the Interledger protocol suite are concerned with what the whitepaper calls universal mode. (as oppose dto atomic mode. TODO unpack)