Cosmos IBC VS ILP

[yxxyun]

https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md

Quote

The Interledger Protocol [14] is not strictly a scalability solution. It provides an ad hoc interoperation between different ledger systems through a loosely coupled bilateral relationship network. Like the Lightning Network, the purpose of ILP is to facilitate payments, but it specifically focuses on payments across disparate ledger types, and extends the atomic transaction mechanism to include not only hash-locks, but also a quorum of notaries (called the Atomic Transport Protocol). The latter mechanism for enforcing atomicity in inter-ledger transactions is similar to Tendermint's light-client SPV echanism, so an illustration of the distinction between ILP and Cosmos/IBC is warranted, and provided below.

1. The notaries of a connector in ILP do not support membership changes, and do not allow for flexible weighting between notaries. On the other hand, IBC is designed specifically for blockchains, where validators can have different weights, and where membership can change over the course of the blockchain.

2. As in the Lightning Network, the receiver of payment in ILP must be online to send a confirmation back to the sender. In a token transfer over IBC, the validator-set of the receiver's blockchain is responsible for providing confirmation, not the receiving user.

3. The most striking difference is that ILP's connectors are not responsible or keeping authoritative state about payments, whereas in Cosmos, the validators of a hub are the authority of the state of IBC token transfers as well as the authority of the amount of tokens held by each zone (but not the amount of tokens held by each account within a zone). This is the fundamental innovation that allows for secure asymmetric tranfer of tokens from zone to zone; the analog to ILP's connector in Cosmos is a persistent and maximally secure blockchain ledger, the Cosmos Hub.

4. The inter-ledger payments in ILP need to be backed by an exchange orderbook, as there is no asymmetric transfer of coins from one ledger to another, only the transfer of value or market equivalents.

 

[KarmaCoverage]

5 minutes ago, yxxyun said:

Cosmos is a persistent and maximally secure blockchain ledger, the Cosmos Hub.

So it is a ledger itself?

Sorry I have only read what is posted about this topic, but it sounds like another attempt to be "the ledger of all ledgers"?

[yxxyun]

Quote

Cosmos is a network of independent parallel blockchains that are each powered by classical BFT consensus algorithms like Tendermint 1.

The first blockchain in this network will be the Cosmos Hub. The Cosomos Hub connects to many other blockchains (orzones) via a novel inter-blockchain communication protocol. The Cosmos Hub tracks numerous token types and keeps record of the total number of tokens in each connected zone. Tokens can be transferred from one zone to another securely and quickly without the need for a liquid exchange between zones, because all inter-zone coin transfers go through the Cosmos Hub.

 

[Guest]

It does sound like a one-size-fits-all solution.

[Apollo]

It sounds more like RCL with sharding then ILP. 

[cmbartley]

I think that from the bank perspective, an advantage of ILP is opacity. In ILP the ledgers don't have knowledge about the state of other ledgers. In Cosmos it appears that validators do have some knowledge about the state of parallel ledgers. 

Edited September 22, 2016 by cmbartley

[lerik]

I always thought that ILP is capable of transfer of coins between different ledger systems in the sense that ownership/keys can be transferred. I am not sure if the information in point 4 is correct. I appreciate clarification. What I understand about Cosmos is that they are using the sidechain method of Blockstream, where a token is kept at a validator and a surrogate is issued instead. Not sure if that can be considered true asymmetric transfer from zone to zone.

I can't find the licensing model for Cosmos. It seems proprietary where the various additional blockchains will be operated by them. ILP and crypto-conditions are more minimalistic, which gives them ability for being adopted in different ledger systems. I don't understand how Cosmos is a scalable solution in the sense that providers can implement it independently.

[kanaas]

1 hour ago, lerik said:

I always thought that ILP is capable of transfer of coins between different ledger systems in the sense that ownership/keys can be transferred. I am not sure if the information in point 4 is correct. I appreciate clarification. What I understand about Cosmos is that they are using the sidechain method of Blockstream, where a token is kept at a validator and a surrogate is issued instead. Not sure if that can be considered true asymmetric transfer from zone to zone.

I can't find the licensing model for Cosmos. It seems proprietary where the various additional blockchains will be operated by them. ILP and crypto-conditions are more minimalistic, which gives them ability for being adopted in different ledger systems. I don't understand how Cosmos is a scalable solution in the sense that providers can implement it independently.

Point 4 is correct when it says that ILP has to be backed with an exchange for that matter, but ILP eventually is backed by an exchange orderbook: the Ripple Concensus Ledger (RCL). With MM's growing the trading volumes on RCL and competing for the best rates combined with an ever improving pathfinding algorithm and spreads that will narrow once to become very very small and without any other third party raping a part of the stake on the exchange component....  this will become the most competitive construction ever thinkable.

I do not know how Cosmos will handle asymmetric payments, but unless God helps them with some very special magic wondertrick, they will need an exchange component as well. Wonder if it will be as efficient and sharp rated as an efficient and on decent volume running RCL...

[jn_r]

46 minutes ago, kanaas said:

Point 4 is correct when it says that ILP has to be backed with an exchange for that matter, but ILP eventually is backed by an exchange orderbook: the Ripple Concensus Ledger (RCL). 

I do not see how that is done. The connectors decide the price they want to offer, but it is not said that they offer that price on the RCL, even though one of the ledgers in the ILP transaction is RCL. Maybe RCL could be made fit for that purpose. Plz correct me if I'm wrong.

46 minutes ago, kanaas said:

I do not know how Cosmos will handle asymmetric payments, but unless God helps them with some very special magic wondertrick, they will need an exchange component as well. Wonder if it will be as efficient and sharp rated as an efficient and on decent volume running RCL...

+1

[Mercury]

It says all coins for through Cosmos hub? Like a central exchange/ place of account? This a big no no for international settlement I would imagine. This removes all trust to a single operator located in single jurisdictional area. Might be ok for national systems but would be a hindrance for international settlement

Sent from my LG-K210 using Tapatalk

[lerik]

If I got it right, the Atomic Transport Protocol in ILP enabled basically by crypto-conditions allows for  transfer of tokens across ledgers, at least to the exchange ledger. Cosmos mentions the word payment (logically across tokens), but with payment there is always a exchange rate involved (which is not a technical issue). So I do not really understand what is said. I assume that with ILP same kind of tokens can be transferred. Let's assume a transfer of BTC where two ledgers A and B are not directly linked but maybe 4 hops between. I assume that with ILP it is technically possible to transfer the BTC token, even if it does not involve the commercial aspect of currency conversion.

Edited September 24, 2016 by lerik

[cmbartley]

On 9/24/2016 at 7:59 AM, lerik said:

I assume that with ILP same kind of tokens can be transferred.

My understanding is that with ILP what is actually transferred is value. In some cases the value could be the transfer of a BTC or other token, in others it may be the transfer of an IOU. In some cases you'll pay with the token of your choice and the recipient will receive the token of their choice. For example if I have USD.Venmo and want to pay you on PayPal you will receive USD.PayPal. Alternatively I could pay with USD.Venmo and the recipient could receive BTC.

Edited September 26, 2016 by cmbartley

[JoelKatz]

ILP doesn't do anything more than it needs to. You can do those other things any way you want and you can still use ILP for the atomic value transfer and you'll interoperate with others who do those other things differently.

[lerik]

Thanks for the answers. My understanding of ILP is still deficient. For what I understood, ILP requires the atomic transaction type with the crypto-conditions as a prerequisite. In order to get ILP working these features need to be added to the ledgers and blockchains. My interest in ILP or crypto-conditions is the possible facilitation of smart contract capability across ledgers. RSK for Bitcoin and Ethereum only work on their respective domain. ILP is intended for payments, but I guess that many smart contract and app platforms like Bigchain or Expanse are taking a look on ILP and crypto-conditions for various use cases that are typically associated with Ethereum. If ILP is only applicable for payments and there are other solutions in development like Cosmos that can provide cross ledger smart contracts, then ILP would appear less attractive. I still do not sufficiently understand the relationship between crypto-conditions and ILP. ILP seems to be a payment protocol, but it also seems that in theory with crypto-conditions more advanced transfers can be done across ledger, and that's what many of the alternative platforms have a need for.

Edited September 26, 2016 by lerik

[JoelKatz]

ILP is a protocol for the atomic execution of two different operations on two different systems. It requires that at least one of the systems have the ability to guarantee that it can perform its share of the bargain in the future so that the other side can commit first with the other side's commitment triggering that side's action. Crypto-conditions are the way to precisely specify what constitute one side confirming its action so that we are assured that the other side will act if and only if the other side did. Crypto-conditions is flexible enough to support more complex operations but we are primarily interested in payments.