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.
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:
In the above example, we see that we can mitigate transaction fees by exchanging newly written checks to account for previously written and destroying the olds ones in the process.
In terms of how this works in blockchain land, I’ll explain from an Ethereum developer standpoint, given my background.
When creating a payment channel, the two parties must agree to stake ETH to a smart contract (in this case, both Alice and Bob have staked 25 ETH). This smart contract has the ability to accept a transaction signed by one or more parties and pay out the respective amount to both. If both parties take the latest signed off-chain transaction (in this case, Alice: 15, Bob: 25) and send it to the smart contract, the smart contract will instantly update and pay out to both parties.
The nonce associated with each signed transaction is for transaction ordering purposes. Say that Alice submits the transaction with nonce 0, but Bob doesn’t agree to that because there is a more recent transaction. So, in the case that both parties do not agree to the transaction being submitted, the smart contract will wait a period of time ‘a challenge period’ for a newer transaction (or transaction with a higher nonce) to be submitted. If a newer transaction is submitted, a new challenge period will begin where we will wait for a potentially newer transaction. If a newer transaction is not submitted and the challenge period expires, the contract will instantly update and pay out to both parties based on the latest transaction that it has received. Here is an example of how that scenario would play out:
So, the main benefits here include:
- Privacy — Each payment was known only to Alice and Bob, which allows them to have privacy in their individual transactions such that the public only knows the result which has been shared on-chain.
- ‘Instant Finality’ — Alice and Bob can sign and exchange messages instantaneously without having to wait for confirmation from the chain — leading to a much better user-experience.
- Lower Cost — Alice and Bob are able to exchange ETH freely with the only on-chain transactions being for creating the channel and settling / closing the channel.
One caveat to note here is that each payment channel must have a well-defined set of users when being created. This is needed to ensure that transactions being submitted on-chain have been agreed to by all parties in the channel.
Part 2: App-Specific State Channels
In my next post, I’m going to be delving into App-Specific State Channels.
If you have any projects leveraging state channels, I’d love to see your implementation and how you’re approaching things. And if there’s something about this that I can improve, please don’t hesitate to let me know in the comments section, here. Lastly, if you’ve gained something from this article, I am but a social media noob and would greatly appreciate you sharing this to your network. Here’s the link to do so: https://medium.com/@eolszewski/counterfactual-for-dummies-part-1-8ff164f78540
Further Reading
If you’d like to learn more about Counterfactual, here are a few resources for you to check out:
- Their Twitter (Not very active right now, but I expect this to pick up, soon)
- Their Website
- Their Whitepaper
