State Channels For Dummies: Part 1

Payment Channels

In my last post, I briefly discussed state channels and why I think that they are crucial in the enabling the usability of Ethereum by the general public. Here, I intend to take this one step further with a few posts providing a broad overview of what the guys at L4 are doing with Counterfactual and what that word even means. In this first post, I’m going to be covering the O.G. of the space — payment channels.

I was adamant about having this image — no way to make it non-intrusive. Oh, well.

Payment Channels

So, payment channels have been discussed for some time now and a great reference can be found in the Bitcoin Lightning Network Whitepaper on how exactly these work.

If you were to look for a real world example of a payment channel, imagine the following scenario: you frequently purchase food at a restaurant, but only pay in checks (as this is most convenient for you) — whenever a check is cashed, though, there is a $5 fee from the bank cashing the check for the restaurant. Now, with each check averaging ~$15, this is a 33.33% transaction fee, effectively. So, what do we do?

The situation plays out in the same manner with you paying by check to the restaurant except in that each time you write a new check, you increment it by the value of the previously written check that you gave the restaurant and rip apart the previously written check. This allows the restaurant to have a signed check for the running total that you owe to them, enabling them to handle multiple transactions with only one bank interaction (mitigating the bank’s transaction fee). This would look a little like the following: