Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split Ledger Layer into Clearing and Settlement Layers #358

Closed
wants to merge 1 commit into from
Closed

Split Ledger Layer into Clearing and Settlement Layers #358

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 21 additions & 10 deletions 0001-interledger-architecture/0001-interledger-architecture.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
title: Interledger Architecture
draft: 1
draft: 2
---
# Interledger Architecture

Expand Down Expand Up @@ -52,11 +52,11 @@ The Interledger protocol suite may be used to transact across any ledgers and co

### Conditional Transfers

Each local transfer is first *prepared* and then either *executed* or *rejected*. When a transfer is prepared, the ledger puts the funds of the source account on hold with a *cryptographic condition* and *timeout*. If the condition is fulfilled before the timeout, the transfer is executed and the funds are transferred. If the timeout is reached, the transfer expires and the ledger returns the funds to the source account automatically.
Each local transfer is first *prepared* and then either *executed* or *rejected*. When a transfer is prepared, the funds of the source account are put on hold with a *cryptographic condition* and *timeout*. If the condition is fulfilled before the timeout, the transfer is executed and the funds are transferred. If the timeout is reached, the transfer expires and the the funds are returned to the source account automatically.

Inspired by the [Lightning Network](http://lightning.network), Interledger uses the digest of the [SHA-256](https://en.wikipedia.org/wiki/SHA-2) hash function as the condition for transfers. The fulfillment is a valid 32-byte preimage for the hash specified when the transfer was prepared. Ledgers are responsible for validating fulfillments. [Transport Layer](#transport-layer) protocols are used by the sender and receiver to generate the condition for a particular payment.

To be fully Interledger-compatible, ledgers MUST support conditional transfers, though it is possible to send Interledger payments over a ledger that does not natively support the recommended features. See [IL-RFC 17](../0017-ledger-requirements/0017-ledger-requirements.md) for the full description and tiers of ledger requirements.
Conditional transfers are implemented at the [Clearing Layer](#clearing-layer) and may or may not be implemented by the underlying ledgers. See [IL-RFC 22: Hashed Timelock Agreements (HTLAs)](../0022-hashed-timelock-agreements/0022-hashed-timelock-agreements.md) for a full description of the different implementations of conditional transfers.

### Payment Flow

Expand All @@ -78,24 +78,35 @@ If some transfers in an Interledger payment are executed and others expire, the

Failing to deliver the fulfillment in time is the main risk connectors face and there are a number of additional strategies connectors should employ to mitigate and manage this risk. For more details, see [IL-RFC 18](../0018-connector-risk-mitigations/0018-connector-risk-mitigations.md).


## Interledger Protocol Suite

The Interledger stack is separated into four layers:
The Interledger stack is separated into the following layers:

![Interledger Protocol Suite](../shared/graphs/protocol-suite.svg)

### Ledger Layer
**Note:** What was formerly known as the "Ledger Layer" is now split into the Settlement and Clearing Layers.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with your separation of “clearing” and “settlement” as concepts. However, I would be very careful with the use of these specific terms. They tend to add more confusion than clarity because of the many connotations each term has acquired for specific individuals.

Specifically, “real-time settlement” tends to be very interesting to most people we talk to. However, “real-time clearing” is thought to be a boring, already solved, problem. Most people in the payments industry know they can solve problems in existing settlement systems (cost, speed) by creating direct (often intraday) clearing accounts between themselves.

I’m also pretty uncomfortable calling these different layers. In the end, I think they will come to be seen as different payment paths at the same layer.

A clearing path tends to be a specially created account (one hop path) between two entities.
A settlement path is always a multi hop path between the same two entities.

The process of “settling” the clearing account means returning the clearing balance to zero, by shifting that debt to a third party via a circular payment. Since this settlement process can be thought of as a single atomic transaction, I pay you $100 via a settlement path in exchange for you removing $100 of debt from our clearing path.

I think whatever “ILP-the project” becomes, it should be able to do circular debt clearing payments. Hopefully it should be able to do these atomically. As such it doesn’t make sense to me to think of these as different stack layers. It makes it seem like one type of account is lesser than another type. The goal of prefunded payment channels is to make the two types of accounts equivalent when it comes to inter-party risk.

I’ve noticed that Lightning is using the term “level 2 accounts” with on ledger accounts being “level 1 accounts”. Maybe that is a path forward?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with your separation of “clearing” and “settlement” as concepts. However, I would be very careful with the use of these specific terms. They tend to add more confusion than clarity because of the many connotations each term has acquired for specific individuals.

I agree with the above. I can’t tell you how many times I’ve, for example, used the word “Ledger” and the person I’m talking to has had a completely different meaning of that word, and how it fits into the particular sustem we’re talking about.

I like the concept of not using overloaded words per-se, and instead just defining ILP Layers, like ‘ILP Layer 1’ and then saying giving concrete examples, like “Bitcoin” or the “XRP Ledger”. We can then easily say thing like, “X is on layer 1” or, more likely, “Y has some portions that are solidly layer 1, but other portions that operate in layer 2”

### Settlement Layer

In order for two parties to transact, they must be able to send and receive value in the same settlement system. Examples of settlement systems include bank ledgers, closed-loop payment networks, cryptocurrencies, blockchains, or cash.

Settlement systems may or may not have APIs, and the features that they support determine the type of clearing systems that can be used with them.

### Clearing Layer

It is often too slow or expensive to settle every payment via the underlying settlement system. In these cases, a clearing protocol may be used on top of the underlying settlement mechanism. Clearing protocols may be implemented on bilateral or multilateral bases, such as a trustline or a payment channel network like the [Lightning Network](https://lightning.network), respectively.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe mention that the clearing layer can also be more complex, like the one used in ilp-plugin-xrp-paychan, where the receiver trusts the sender to send an unconditional claim update after fulfillment of the otherwise conditional transfer.


The Interledger Clearing Layer may be different from traditional clearing systems because it implements Conditional Transfers, also known as Hashed Timelock Agreements (HTLAs).

In order to facilitate transfers between accounts, ledgers must implement some API or protocol. This is called the ledger layer. There is a wide variety of ledger layer protocols, corresponding to the many different types of ledger.
The most common types of Clearing Layer protocols are [payment channels](../0022-hashed-timelock-agreements/0022-hashed-timelock-agreements.md#simple-payment-channels) and [trustlines](../0022-hashed-timelock-agreements/0022-hashed-timelock-agreements.md#trustlines). See [IL-RFC 22: Hashed Timelock Agreements (HTLAs)](../0022-hashed-timelock-agreements/0022-hashed-timelock-agreements.md) for more details about different types of clearing protocols.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.. or more generically, combining a conditional trustline and an unconditional payment channel into one clearing layer


See [IL-RFC 17](../0017-ledger-requirements/0017-ledger-requirements.md) for a full description of the ledger layer requirements.
**Note:** Real-Time Gross Settlement may be used instead of a separate Clearing Layer if the underlying settlement system is sufficiently fast, inexpensive, and has sufficient throughput.

Most implementations of Interledger use a plugin architecture to abstract the differences between different ledgers. For an example of this, see [IL-RFC 4](../0004-ledger-plugin-interface/0004-ledger-plugin-interface.md), which defines the interface for the Javascript implementation.
Most implementations of Interledger use a plugin architecture to abstract the differences between different Clearing and Settlement Layers. For an example of this, see [IL-RFC 4](../0004-ledger-plugin-interface/0004-ledger-plugin-interface.md), which defines the interface for the Javascript implementation.

### Interledger Layer

The Interledger layer is responsible for facilitating payments across multiple ledgers. It is comprised of two key components that are used together: the Interledger Protocol (ILP) and the Interledger Quoting Protocol (ILQP).
The Interledger layer is responsible for relaying payments across multiple clearing systems. It is comprised of two key components that are used together: the Interledger Protocol (ILP) and the Interledger Quoting Protocol (ILQP).

The [Interledger Protocol (ILP)](../0003-interledger-protocol/0003-interledger-protocol.md) is the core of the Interledger stack and defines standard address and packet formats that instruct connectors where to send a payment.

Expand Down
24 changes: 14 additions & 10 deletions shared/graphs/protocol-suite.dot
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,10 +2,14 @@ graph G {
node [shape = box,height=.1,fontname = "helvetica"];
newrank=true;

app [label="Application\l" shape="plaintext" width=1.5]
transport [label="Transport\l" shape="plaintext" width=1.5]
interledger [label="Interledger\l" shape="plaintext" width=1.5]
ledger [label="Ledger\l" shape="plaintext" width=1.5]
subgraph cluster_labels {
style=invis;
app [label="Application\l" shape="plaintext" width=1.5]
transport [label="Transport\l" shape="plaintext" width=1.5]
interledger [label="Interledger\l" shape="plaintext" width=1.5]
clearing [label="Clearing\l" shape="plaintext" width=1.5]
settlement [label="Settlement\l" shape="plaintext" width=1.5]
}

subgraph cluster_0 {
style=filled;
Expand Down Expand Up @@ -60,20 +64,20 @@ graph G {
fontname = "helvetica";
}

l1 [shape=box label="Ledger 1"];
l2 [shape=box label="Ledger 2"];
l3 [shape=box label="Ledger N" style=dotted];

lli1:s -- l1:nw;
lli2:s -- l1:ne;
lli3:s -- l2:nw;
lli4:s -- l2:ne [style=dotted];
lli5:s -- l3:nw [style=dotted];
lli6:s -- l3:ne [style=dotted];

l1 [shape=box label="Ledger 1"];
l2 [shape=box label="Ledger 2"];
l3 [shape=box label="Ledger N" style=dotted];

{ rank=same; app app1 app2 }
{ rank=same; transport tr1 tr2 }
{ rank=same; interledger im1 im2 im3 im4 }
{ rank=same; ledger lli1 lli2 lli3 lli4 lli5 lli6}
{ rank=same; l1 l2 l3 }
{ rank=same; clearing lli1 lli2 lli3 lli4 lli5 lli6}
{ rank=same; settlement l1 l2 l3 }
}
Loading