Channels funding channels, funding channels

Hello, and welcome back to our state channel series! The aim of this week’s post is to go beyond the explanation of typical state channel interactions that we re-introduced last week, and begin to build an intuition for more advanced concepts, such as how state channels can be opened and closed entirely off-chain, and how one state channel can fund another. These concepts will be key in understanding how state channels can be routed through state channel hubs, which is where a lot of the power of state channels comes from.

In state channels, as in life, it’s necessary to have an understanding for what might happen in the worst case scenario, in order to understand how things behave in normal circumstances. We’re going to spend a lot of today’s post looking at how a state channel will play out on-chain, should it come to that.

The Fundamental Guarantee of State Channels

What makes it safe to pay into a state channel? When you deposit your funds into the state channel contract, you’re allowing them to be governed not just by your signature, but also by that of your counterparty (or counterparties). Roughly speaking, it’s safe to deposit into a state channel, only because state channels provide the following guarantee:

You can withdraw your funds within a finite amount of time, no matter what actions any other party takes

Obviously, when we say “no matter what actions”, we’re assuming a certain ground-level of sportsmanship here; the other parties have to play within a reasonable set of rules. If people are allowed to permanently restrict our abilities to interact with the blockchain, whether through censorship, intimidation, imprisonment, or incapacitation, then all bets are off. We basically need the liveliness property of the blockchain - or at least to be able to get a transaction into the chain within a tunable time frame.

The concept of “my funds” is also somewhat ill-defined - after all, you did deposit your funds into a state channel contract, so who knows what that did to your notion of ownership? What we really mean here is that you can reclaim a portion of the funds in the contract that is reasonably fair to you, given the actions that have occurred in the channel.

In practice, reclaiming your funds is a multi-stage affair:

We’re going to look at the two steps separately, and we’re going to tackle those parts back-to-front: this week we’ll be looking at what effects a finalized outcome can cause, and we’ll leave it to next week to explain how the states you’ve exchanged enable each party to obtain a finalized outcome. That means for the rest of this post, I’m just going to assume that somehow we were able to finalize a given outcome on-chain, and not worry at all about how that happened.

What are outcomes, anyway?

Like Ethereum itself, our on-chain model for state channels is a system of accounts. Some of these accounts belong to state channels and some of them belong to participants. It’s useful to draw these as follows:

For the purposes of this post, you can think of a state channel outcome as a set of instructions on how to allocate the channel’s funds within this system of balances. (This is technically an allocation outcome - we’ll see how we need to generalise this concept in order to support virtual channels later in the series.)

Let’s look at example where the channel, C, holding 10 coins, finalizes with outcome {Alice: 7, Bob: 3}:

The outcome allows us to transfer 7 of the coins from C to Alice, and 3 of the coins from C to Bob.

It’s important to acknowledge at this point that the outcome is just some data, conforming to a certain format, that was produced by state channel participants’ signatures off-chain, and could be completely unrelated to the amount held in the channel on-chain. It turns out that this independence is really important when it comes to funding and topping-up channels, provided it’s clear what happens in each case. If the outcome was {Alice: 8, Bob: 5}, for example, the following would occur:

The allocation is an instruction to distribute the funds in the order they appear in the outcome. In the case above, Alice receives her share and then Bob receives the remainder.

It’s also technically possible that the outcome doesn’t allocate all the funds in the channel, although this is unlikely to occur, as it would be in no party’s interest to sign a state that would allow the channel to finalize with this outcome. For example if the outcome were {Alice: 2, Bob: 3}:

The 5 coins left in the channel here are irrecoverably lost, just as if you’d burned them by sending them to the 0 address.

How to deposit, safely

One situation where it’s super important to understand the outcome payout order is when depositing into a channel. Before depositing into a channel, the participants exchange the necessary signed states to allow each and every one of them to finalize a given outcome on-chain. This outcome represents the agreed contributions to the channel, and also specifies the order in which the participants should deposit. For example, if this initial outcome is {Alice: 4, Bob: 6}, then Alice should deposit first, then Bob:

Why is this? The question you need to ask here is what happens to Alice if Bob doesn’t deposit:

As you can see, if Bob doesn’t deposit, Alice can finalize the outcome on-chain, and reclaim her funds. It’s safe for Alice to deposit, because by doing so is “cost neutral” in that the funds she can claim immediately after depositing are the same as the funds she could claim before.

It’s somewhat strange to be talking in terms of an “initial outcome”, as if the channel has finished before it has begun. What does it mean for both participants to be able to finalize a given outcome at the start, and does that mean the channel is stuck here forever? As we’ll see next week, channels progress by stumbling from one outcome to the next. Typically by signing a new state a participant relinquishes some certainty over the outcome attainable and gives their opponent(s) an option to decide which outcome is enforceable. When the opponent in turn signs their response, they pass back this control. At the start of the channel the outcome is finalizable, but not finalized, and this outcome typically stops being finalizable once the participants exchange their next states.

Channels funding channels

So far, all the outcomes we’ve seen have been allocations from channels to participants. What if allocations could also pay out to other channels? This technique could allocate funds to sub-channels with different application rules, for instance. Let’s look at an example:

Notice that the situation we’ve ended up in is identical to the situation where the channel C2 had been directly funded on-chain, and we did this by finalizing its parent. We can use this to introduce the concept of what it means for a channel to be ledger funded: we say C2 is ledger-funded (for us), since we have to ability to convert it to an on-chain funded channel. We call C1 a ledger channel in this case, as it serves as a “private ledger” between Alice & Bob.

What would happen if the the child channel were to finalize instead of the parent:

We already know how this would behave were the parent to finalize — six tokens would go to Alice, and 4 tokens would go to Bob. Because of this, we can actually absorb this outcome into the parent channel, without finalizing the parent on-chain:

We’ve managed to defund a channel off-chain, that was finalized on-chain. Notice that the logic that we’re relying on here is “because we know what would happen if we went to chain, we don’t need to go to chain, and can rewrite our local state to reflect that reality, and save ourselves some gas”. This captures the essense of “counterfactual logic” that you might have come across previously when learning about state channels.

It’s also pretty easy to see how we can ledger fund channels:

Note that these ledger funding & defunding operations are entirely off-chain.

If you keep applying these same tricks, you can quickly build up arbitrary directed acyclic graphs of state channels that fund one another, which are robust to any of their nodes being finalized on-chain. These ideas can be powerful when constructing hierarchical off-chain interactions between groups of participants, ultimately reducing cost and latency for users, as well as transaction load on the main chain. This technique is magnified further through a novel construction that enables virtually funded channels between participants without requiring direct on-chain relationships. Stay tuned for more!

What’s next?

In this post we completely ignored the question of how the states exchanged in a channel lead to a finalized outcome. We’ll begin to look at the mechanics here in next week’s post, but it’ll take a few weeks before we’ll be able to build up the complete picture of virtual channels. The complexity here lies in determining what outcomes are finalizeable for each party, which becomes trickier to ascertain once different channels have different sets of participants.

Hope to see you next time!

Written by Tom Close, Magmo team lead @ Consensys R&D. Thanks to Liam Horne, George Knee, and Andrew Stewart for comments and suggestions.