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.
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:
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:
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).
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.
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.
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.
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
