State Channel for Dummies: Part 4

Ledger Channels and Virtual Channels

Before getting started, I recommend that you read up on Hub-And-Spoke Channels for payments as we will be building on that knowledge here.

I never know where to put this image…

After reading this post, you will understand how to create ‘virtual channels’ between two spokes in a hub-and-spoke topology whereby the two spokes are able to transact independently of the hub. An example of a virtual channel is illustrated by the dashed red line:

A virtual channel illustrated in red

Ledger Channels

Virtual Channels are contingent on the implementation of what are known as ‘ledger channels’. Ledger channels are simply another name for a bi-directional payment channel. In the below example, we have ledger channel x opened between Alice and Bob where Alice has a balance of 5 ETH and Bob has a balance of 3 ETH.

Opening a Virtual Channel

In order to open a virtual channel, we require that two nodes share a common connection that they both have ledger channels open with. Ingrid will serve as our common connection / hub, having open ledger channels y with Alice and z with Bob. Below we show what virtual channel x between Alice and Bob would look like - where Alice would have a balance of 5 ETH and Bob would have a balance of 3 ETH:

In order to open this channel, Alice and Bob will both send a signed request to Ingrid. After receiving signed requests from both parties, Ingrid will approve of this change and update both ledger channels. This update process will block the coins needed for each side of the virtual channel on their respective sides of the ledger channels — this leaves us with the following:

We have blocked 5 ETH on the left and 3 ETH on the right of each ledger channel

The existing ledger channels have had 5 ETH blocked on their left side and 3 ETH blocked on their right side in order to support the creation of the virtual channel. At this point, we no longer need Ingrid and updating the virtual channel is identical to the update of a ledger channel (where both parties sign and exchange sequenced distributions).

Alice agreeing to send Bob 1 ETH
Bob agreeing to send Alice 2 ETH (based upon starting distribution)

Now that we’ve opened a virtual channel and have exchanged a few payments, the next part is settling and closing the channel.

Closing a Virtual Channel

Ideal

In order to close the above virtual channel, Bob and Alice would submit the latest mutually signed distribution to Ingrid. Ingrid would then update the balances of each ledger channel to reflect this update. Keep in mind that we are keeping the ledger channels open, meaning that none of this is being done on-chain.

2 ETH has moved from right to left in both ledger channels to account for the update

Unavailability / Griefing

Consider that Bob decides to try and cheat Alice by sending an earlier distribution to Ingrid. Upon receiving this message from Bob, Ingrid will verify that it is indeed the latest distribution with Alice. In the case that Alice is unavailable, Ingrid will start a dispute period where she will provide proof that a virtual channel was opened (signed request by Alice) as well as the latest distribution of the channel that Bob has sent to her (signed by Alice and Bob). If Alice is unable to make it back online before the end of the dispute period, the ledger channel between her and Ingrid will be updated and closed.

Bob having successfully griefed Alice due to her unavailability

Monitoring Services

In the case that Alice had anticipated her unavailability, she may have sent the mutually signed distributions to a friend (Carl) to send to Ingrid on her behalf in case she was unavailable — effectively making Carl a monitoring service. This may not prevent Alice’s channel from being closed due to her unavailability, but it would force Bob to either submit a newer distribution (of which there are none) or agree to the one that Carl had submitted.

Bob failing to grief Alice due to Carl submitting the latest distribution on Alice’s behalf

This strategy of providing a paid monitoring service (like Carl) is quite popular in the community. Personally, I am not a fan of this as the same effects can be achieved in a channel without a third party service—this will be covered in a later post. This being said, if you’d like to learn more about these third-party solutions, I have included some relevant documentation in the next section.

Who is Working on This?

This post was inspired by Perun Channels — the work they are doing is excellent and has spawned multiple variants of their work. The one which I am most familiar with would be ‘Set Payment Channels’, which are currently being implemented by SpankChain, Nathan Ginnever (Finality Labs), and Arjun Bhuptani (Connext).

Part 5: Generalized State Channels / Counterfactual

Next week’s post is going to be covering Counterfactual Instantiation as well as Generalized State Channels.

Further Reading

Virtual Channels

Monitoring Services

Interested in Being Featured?

If you have any interesting projects that the community would benefit from leveraging / understanding, I would love to see your implementation and how you’re approaching things.

Feedback

If there’s something about this that I can improve, please don’t hesitate to let me know in the comments section, below. And if you’ve gained something from this article, please spam the clap button and share it (these simple actions really make a huge difference). Here’s the link to do so:

https://medium.com/@eolszewski/state-channel-for-dummies-part-4-f3ba9d76c7c4

Find me on Twitter or Github!