Horizontal scaling within a serial payment channel

[leighmcculloch]

The current payment channel protocol described in the SEP is serial.

Participants agree together on a new net settlement amount. Each payment in the channel is a committed proposal to change that number. When I say committed, I mean the participant proposing the change is committed, they've signed everything they need to sign and the participant receiving the proposal is free to close the channel with that change without any further coordination.

The payment channel protocol doesn't require that the participant receiving the proposal confirm the transaction before the participant proposing can propose another payment, however there are implications for the proposer not waiting, as is described in the SEP.

There's a separate discussion #287 where we have discussed the problem of performing concurrent payments. That problem is similar, but distinct.

The serial nature of the protocol is a result of the participants operating on a single net settlement amount. Similar to how in concurrent applications there must be synchronization on mutating a shared variable, the channel must either synchronize or coordinate around changing the net settlement amount.

This discussion is for discussing how two participants using a single channel that reaches the limits of vertically scaling the channel, could horizontally scale the channel? If you have an idea please comment below. Let's try and keep one top-level comment per idea, with comments about that idea as sub-comments of that comment.

[leighmcculloch]

One idea that @nikhilsaraf mentioned to me, that he referred to as the super channel, is to have one logical channel wrap many actual channels. This would in-effect be a layer above the actual payment channels. Payments would be routed to whichever payment channel is next either via some availability test or via round-robin selection.

Benefits:

• Dynamic scaling. The number of actual payment channels can be dynamic.
• Limiting factor in scale would be the scheduler who decides which channel to use. That's something that can be iterated on in isolation and plenty of strategies to pick from there.
• Supports concurrent payments at the third layer, the layer above the payment channel.

Costs:

• Capital lock up might be larger because capital must be divided across the actual channels.
• Larger payments may not be possible, or may require locking up multiple channels, negating the benefits.

[leighmcculloch]

Another idea that @stanford-scs mentioned to me, that we can refer to as a buffered channel, is to buffer payments and deliver them as a block that either contains all payments or summarizes them into a final payment. The block would occur frequently but could contain a number of payments that is a scale beyond the number of payments a serial channel alone can coordinate. If the block is a summary of the payments within this essentially adds a second layer of net-settlement to the payment channel. The first layer is the net-settlement that the serial payment channel encodes into its close transactions. The second layer is the net-settlement that a payment encodes since a payment can be the sum of many payments layered on-top.

Benefits:

• Dynamic scaling. The scale does not need to be fixed at setup. Over time the number of payments that are buffered can be increased or lowered and be controlled fluidly based off environmental factors.
• The same capital that is required for a single channel is required for a buffered channel.
• Supports concurrent payments at the third layer, the layer above the payment channel.

Costs:

• For implementations that buffer and deliver all payments in a single block, the message is likely to be large and slow.
• For implementations that buffer and summarize payments into a single payment, the system can coordinate about what payments are in what block via some other method, which radically increases the complexity of the integration. Each participant would need to validate blocks against payments they have received to ensure every payment was in fact received. There is likely a cost to this.

[acharb]

Another con/risk is it introduces a risk for a large # of payments to be negated. Eg. if there were 100 "virtual" payments in a block, and when it comes time to confirming the block, one of the participants could decide to back out and not confirm the block for whatever reason. Therefore negating all these virtual payments. We could limit the # of payments/block though, but at the cost of the scaling gains.

[accordeiro]

What if we combined this idea with uni-directional channels? The sending party buffers and summarizes payments in an arbitrary interval (say 1s), then computes the net value and sends to the other end? The breakdown of each individual sub-payment could be appended to the transaction in a lightweight format.

[leighmcculloch]

There is a rudimentary implementation of a buffered channel now in the SDK at: https://github.com/stellar/experimental-payment-channels/tree/main/sdk/agent/bufferedagent

The console example application also supports buffered payments.

[leighmcculloch]

An idea that was first shared at #287 (reply in thread), that we can refer to as a merging channel, is for both participants to stream payments as frequently as they wish to each other, queueing incoming payments, confirming them on their own time, and at each confirm merging them with the most recently sent payment. In an payment channel where the flow of payments is equally bi-directional and the volume of sending is greater than of confirming both participants may always be out-of-dated but are always catching up and could catch up for close.

Benefits:

• Avoids the complexities of any third layer construct, or can still be combined with other third layer constructs.
• Removes the network delays.
• Solves Handle concurrent payments #287 and allows for concurrent payments in either direction at the layer 2, the payment channel layer.

Costs:

• Both participants risk the channel being locked open, as described in the first comment of this discussion thread (Horizontal scaling within a serial payment channel #330 (comment)) unless another mechanism, unknown at this time, is added to the protocol to prevent that.
• There will be some upper limit reached since the channel is still serial, and so this is not really horizontally scaling.

[leighmcculloch]

The risk described above where a channel can get locked open occurs because participants generate many valid iterations that the other participants could choose not to confirm, and then submit declarations one at a time. One way to mitigate this is to have participants update the current iteration number until it is confirmed. For example:

[leighmcculloch]

I am going to try implementing just enough of this idea to see what it benchmarks like: #338.

[leighmcculloch]

Before doing any coding I drew a diagram for the approach described above where we reuse iteration numbers. Here's a very simple example of how it would start, however I haven't figured out or decided what the simplest rule to introduce yet would be to resolve the two final states that form:

I'm going to put a pause on digging in further on this to look into #330 (reply in thread).