Split Ledger Layer into Clearing and Settlement Layers #358
Conversation
When we originally started working on Interledger, we thought of it as a Real-Time Gross Settlement protocol. However, we have shfited to thinking of it as primarily a protocol for clearing payments. Nevertheless, we still refer to the layer below the Interledger layer as the "Ledger Layer". This is confusing because it refers to both settlement and clearing systems. This commit splits what was formerly known as the Ledger Layer into the Settlement Layer and Clearing Layer. This change should make it easier to explain why we may assume _clearing_ is fast and inexpensive, even if the underlying ledger or settlement system is slow or has high fees.
emschwartz
requested review from
adrianhopebailie,
justmoon,
sappenin,
michielbdejong,
sharafian,
earizon and
BobWay
emschwartz
changed the title
There was a problem hiding this comment.
Also the following statements still talk in terms "safely rollback to the ledger, in case the connector fails", which is no longer our focus after the pivot, due to strong enlightenment, where the ledger and the next connector are no longer two different parties:
|
|
||
| ### 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. |
There was a problem hiding this comment.
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.
|
|
||
| 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. |
There was a problem hiding this comment.
.. or more generically, combining a conditional trustline and an unconditional payment channel into one clearing layer
There was a problem hiding this comment.
The diagram suggests that the transfers that make up the Interledger payment go over the ledger, which after this pivot will no longer be the case. We could even split up the clearing layer into the layer where the chained conditional transfers are prepared and fulfilled ("transfer layer"?), and the layer where the payment channel balances are adjusted (because like the ledger transfers, the payment channel claim updates are decoupled from the chained transfers in terms of timing, as well as in terms of hashlock condition, and one payment channel claim update may even aggregate/net together the transfers from multiple unrelated Interledger payments). So we should add horizontal lines back and forth (prepare and fulfill) at the clearing layer ("transfer layer"?) in the diagram?
|
|
||
|  | ||
|
|
||
| ### Ledger Layer | ||
| **Note:** What was formerly known as the "Ledger Layer" is now split into the Settlement and Clearing Layers. | ||
|
|
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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”
|
Closing this PR because #359 moves most of what would have been called the Clearing layer into the Interledger layer |
When we originally started working on Interledger, we thought of it
as a Real-Time Gross Settlement protocol. However, we have shfited to
thinking of it as primarily a protocol for clearing payments.
Nevertheless, we still refer to the layer below the Interledger layer as
the "Ledger Layer". This is confusing because it refers to both
settlement and clearing systems.
This commit splits what was formerly known as the Ledger Layer into the
Settlement Layer and Clearing Layer. This change should make it easier
to explain why we may assume clearing is fast and inexpensive, even if
the underlying ledger or settlement system is slow or has high fees.