The Collateral Management Challenge in Payment Channels—and one sight of light

There are many challenges to operating an instant transaction network as a service on top of a blockchain. From a business perspective, one of the critical issues is the collateral lock-up required to transport payments. Essentially, to maintain a trustless network, a provider that wishes to maintain a payment service usable by some set of recipients, for example merchants, to receive off-chain transactions, would have to lock up an amount of collateral that is equal to the expected incoming volume of the recipient, and then claim that amount back from the channels used to receive the payments.

The coordination required to maintain the payment channels that are used by the provider to receive payments from senders, and those used to deliver payments to recipients, is not negligible. The senders’ and receivers’ balances will have to be managed and organized such that the collateral locked up by the provider is adequately distributed, and service is not disrupted.

To clarify, imagine you are a payment service provider with many paying consumers and a few receiving merchants. The consumers would deposit money into the channels they have open with you, and then request to use their balances to make purchases from the merchants. As the provider, you would accept that the clients’ channel balances shift in your favor, and in turn shift the merchants’ balances in the merchants’ favors (i.e. make a linked payment). In essence, you would give away large amounts of the collateral you have locked up in the merchant channels, in exchange for the many smaller amounts that you have received in your consumers’ channels. You are, as the intermediary here, essentially fragmenting the consolidated collateral you have locked up to provide service to your merchants, and accepting the burden of collecting back the smaller amounts from your user.

Unless you have credit lines open with the merchants, in which case, we’re not talking about a trustless network anymore, or you have infinitely deep pockets, you’re going to care about efficiently managing the collateral invested in sustaining your operations. Imagine that as the provider, you have your collateral spread across a few directly connected nodes in different continents and that the following trends are observed:

1. Users from North America (NA) make a lot of purchases from merchants in Europe (EU)
2. Users from the EU make a lot of purchases from Africa.
3. Users from Africa make a lot of purchases from NA.

In this simple 3-party example, as the network provider, you’re going to end up in a peculiar position whereby, after a while, you resort to routing payments through indirect paths, and can no longer utilize your direct routes, because the balances of the direct payment channels between nodes have become skewed in one direction. To repair this, you could opt to transfer balances on-chain, to continue efficient operations.

Resorting to on-chain transactions, however, to mitigate the effect of this collateral build-up, would not scale with running a global payment network involving hundreds of thousands, if not millions, of participants.

As part of our efforts towards building a sustainable payment network,
we put together late last April the protocol known as REVIVE, an off-chain solution to re-balance a payment channel network, and published
it in this year’s proceedings of the ACM Conference on Computer and
Communications Security.

The REVIVE protocol enables a set of payment channel owners to execute a set of transactions that would simultaneously shift, off-chain, the balances of the channels they use in the protocol. If you plug-in just the right parameters to the protocol, you can use it to solve some of your collateral lock-up related problems, maintain a healthier network at cheaper costs, and efficiently consolidate some of your fragmented collateral.

Essentially, the protocol is broken up into two major components: a transaction set generation procedure, and a transaction enforcement mechanism. The generation procedure is built to take into account the goals of the shifting operation, whether they are to re-balance, or even skew, the involved payment channels, and output a set of sane transactions that can be performed oi-chain to achieve those goals. The enforcement mechanism is used to ensure the atomic execution, or failure, of all the generated transactions, to guarantee correctness, and that dishonest participants in a re-balancing instance are unable to steal any funds.

It has been obvious, prior to REVIVE, that if one user wished to shift balance from one of their channels to another, they could simply execute a self payment that would transfer the same amount through a linked circular payment. However, in a broader context of different users, different payment channels, different objectives and different payment amounts, it was not clear how a set of re-balancing transactions could be created. This complex problem is modeled as a linear program in REVIVE’s generation protocol, that accounts for what each participant would like to do with their channels, and outputs a set of transactions that maximizes the satisfaction of those goals (i.e. maximized re-balanced funds with the right parameters).

Enforcing a general transaction set, however, is not a trivial special case of enforcing a linked payment. For one thing, the transaction amounts are not assumed to be equal. Therefore, an intermediary who aborts the protocol in the middle of its execution may end up with more incoming funds than outgoing. In REVIVE, a general enforcement protocol that is backed up by an on-chain dispute mechanism is specified and leveraged to ensure the security of the protocol.

As we make progress towards developing a practical cryptocurrency payment network, we intend to release more of the intricacies of our developments out to the world. Decentralized ledgers are a sensitive environment, and peer-reviewed research is key towards ensuring the security of the protocols that can be employed.

If you’re interested in giving REVIVE a full read, then head over to https://acmccs.github.io/papers/p439-khalilA.pdf for a copy of the published paper we presented a few weeks ago at the ACM CCS conference in Dallas!

We hope you enjoyed this short read on one of the key business problems in payment networks. We will be releasing more blog posts soon on the progress of Liquidity.Network!

DISCLAIMER: Timelines and roadmap details mentioned are subject to change. Please look for our official communication on liquidity.network and subscribe to our update emailers. There is a lag on uploads. This message is not an endorsement or recommendation for Liquidity Network, any cryptocurrency, or investment product.  Neither the information, nor any opinion contained in this message constitutes a solicitation or offer by the creators or participants to buy or sell any securities or other financial instruments or provide any investment advice or service.