Understanding Counterfactual and the Evolution of Payment Channels and State Channels
This article is one in a series of my 🍌Banana Papers — blockchain whitepapers re-written in an easy to digest (like bananas!) manner. My goal is to help readers quickly understand and evaluate complex blockchain ideas with minimal pain.
I’m getting a little esoteric with this banana paper on Counterfactual, I know. The whitepaper just came out a couple weeks ago, there’s no ICO, no investment hype, and it’s what I would call deep in the bowels of blockchain tech. But there’s enough info out there on EOS, etc. right? Though no doubt covering the top 10 crypto would bring me more readers … let’s instead spend a little time on some blockchain ideas that are new, backed by some of the big names, technically challenging, but quiet.
Counterfactual is an idea funded by Vitalik Buterin, ethereum and L4 Ventures, and developed by Jeff Coleman, Liam Horne, and Li Xuanji. It’s a well-written (thanks for introducing me to the word desideratum, guys) and thorough whitepaper. And it’s a pretty exciting idea. Let’s dive in.
Counterfactual — The Easy Explanation
We’ve seen this problem before: the Ethereum blockchain is too expensive and too slow for most applications. It’s expensive because of gas costs — a single transaction currently costs around $.20. And it’s slow because users are forced to wait several block confirmations (at least several minutes) before a transaction is final. This experience just doesn’t fulfill the high expectations of modern users who live on web and mobile.
Counterfactual — through generalized state channels — solves these problems by moving processes off the blockchain, while still giving processes the benefits of blockchain.
Counterfactual transactions are cheap and fast, yet still trustless and final.
Counterfactual — the Detailed Overview
To understand how Counterfactual achieves the above, let’s do a little knowledge build.
First there was the blockchain…
On a blockchain, transactions are trustless and final. But on a typical blockchain you pay a transaction fee (which pays for the miners to mine your transaction) and you wait for your block to be propagated across the network to ensure it’s the truth (this takes at least a few minutes).
Next there were payment channels…
Payment Channels
Payment channels try to provide a better experience than blockchain — they create a layer for cheap, fast payments.
Payment channels are smart contracts — deployed on a blockchain — that internally, and without writing them to the underlying blockchain, record transactions that happen among a group of users.
For example, you and I work together and want an easy way to pay each other for lunches, coffee, etc. So we open a payment channel and each fund it by depositing 10 ETH. That 10 ETH — called a state deposit — is locked into the channel. Now when we pay each other using the payment channel (and we both have to sign every transaction so that the channel knows the transaction is true), the smart contract records the transaction and transfers the money around internally, but does NOT send the transaction to the underlying blockchain. The payment channel knows and keeps track of our balances. So there is no transaction fee or delay in our payments to each other.
When all the participants are done with their transactions — in our example say we’re done working together and don’t expect to again anytime soon — we signal that we’re done to the smart contract, which then submits all the transactions in one big lump to the underlying blockchain, making everything permanent. Through this entire process there were only two transaction fees charged, and only two times where we had to wait for the blocks to propagate through the network: when we created the payment channel/state deposit, and when we closed the payment channel.
Examples of payment channel projects are the Raiden Network and the Bitcoin Lightning network.
Next there were app-specific state channels…
State Channels
State channels are just like the payment channels above — except they are built not just for currencies, but can be built for anything that requires state on a blockchain — basically any transaction that is stored on the blockchain.
For example: the moves in a chess game. Instead of each turn being sent to a record keeper as it is taken, the turns are instead collected in the channel, then submitted as one large report at the end of the game. Just like payment channels, state channels allow groups of users to transact multiple times, over minutes or even years, agreeing at each step on what has happened, and then — when everyone is done — commit the entire record of transactions to the blockchain in one giant commit. State channels are fast and cheap, yet still trustless and final.
One item to note: state channels are built specifically for each individual application, and work only for that specific application and its specific state. This has been a strong discourager for development teams — building a new state channel for an app is expensive and time consuming.
And now, finally, we get to Counterfactual, and their concept of generalized state channels …
Counterfactual and Generalized State Channels
Generalized State Channels are like the above app-specific state channels, except they are a generic framework. Generalized State Channels allow any state of any application to be combined into one, single state channel, all at the same time. (Similar to state channels, Generalized State Channels only work for the agreed upon participants.)
So you could play chess, sell coffee, play checkers, send MKR tokens, and more, all on the same state channel, all with no fees, no delay, and no blockchain transactions.
Not only that, but (and this may be the most impressive feature) Generalized State Channels allow you, at any time, to add new apps and states to your channel, and move funds between all your apps, all with no extra work, no fees, no delay, and no transactions sent to the blockchain.
Hey — I know I’ve been using this channel to pay you back for lunches, but want to start up a chess game on that channel, too?
Counterfactual — and Generalized State Channels — are a way to get apps all working together on the blockchain, and make them cheap and fast. And they are a framework that development teams can use to put state channels in their app with minimal work.
That’s the overall idea, and it’s a big one. The whitepaper is packed full of details around threat models, implementation, comparison to other ways of taking transactions off-chain, and more. We’ll cover a few of those below.
More Details
The whitepaper goes into great detail about the concept and definitions behind Counterfactual. I’ll cover a couple that I found to be important.
Adding a new contract to the channel
As I mentioned above, one of the most powerful features of Counterfactual is that you can dynamically add new apps (meaning the app’s smart contracts) to your channel, and then use that smart contract’s functionality without going “on-chain” or incurring any fees. Counterfactual does this by a process called counterfactual instantiation. This process compiles the original smart contract that is on the blockchain into a Counterfactual smart contract that is then deployed to, and lives in, your state channel, and that the participants agree is now part of their overall agreement. This new counterfactual contract is linked to the original smart contract, so that when the time to finalize the state channel arrives, the counterfactual version of the smart contract can update the original smart contract on the blockchain.
Object Oriented Design
Counterfactual state channels are built in an object-oriented manner, meaning that counterfactually instantiated smart contracts can be viewed as objects that interact and build upon other objects in the state channel. All these objects can talk, interact, etc., building a pyramid up to the top contact, which is a multi-signature wallet that directly interacts with the blockchain. In fact, this top-level multi-sig wallet is the only object that interacts with the blockchain, handling everything that needs to go to the blockchain, such as disputes and finalizations.
Threats
There are several threats to state channels that Counterfactual must worry about.
First, in order for state channels to work properly, there are several assumptions made that aren’t necessarily true for blockchain. If any of these assumptions turn out to be false, then that false assumption poses a fatal threat to the state channel. Counterfactual does not handle situations where these assumptions are not true:
- The underlying blockchain must be well built
- Participants must be available and online often
- There must be no external incentives greater than the internal incentives
- The smart contracts must be well built
The second big worry is griefing. Griefing is when a user does something unexpected in a system, for no personal reward, just to harm someone else. Dirty stuff, right? And dangerous. Here are two ways griefing can happen in a state channel:
Unavailability Griefing
Everything is going smoothly in your state channel, until one of the participants, Bob, decides to stop responding. Bob won’t sign his messages, he won’t agree to your messages, nothing. And because of this, other participants are nowforced into paying to finalize the state channel onto the blockchain.
This is a tough situation, because the system can’t just punish the person who is griefing. After all, maybe Bob is not really greifing, maybe he’s just not online, maybe it’s the other person being the jerk and making a false claim against Bob. The system has no way to definitively know who is telling the truth.
Counterfactual puts forth a few possible solutions for unavailability griefing, such as trusted third-parties, and economic ways to penalize the griefer, but this area is still being researched.
Posting a Stale State
Posting a stale state happens when one of the participants in the state channel submits an old state as the newest one. For example, our buddy Bob pays you 1 ETH for dinner, then submits an old state to the channel where he still owns that 1 ETH, then spends that 1 ETH again.
This is a real problem because while you — as the person who had already received the ETH — would normally be able to challenge this action and prove Bob had already spent the ETH, what happens if you are offline, or there is network congestion and you are unable to send your challenge?
Counterfactual puts forth one suggestion for handling this behavior, which is penalizing participants who submit states that are later, through a variety of proposed ways, proven to be false.
There is much more in the whitepaper, but we’re going to stop here. Hopefully I’ve given you a solid foundation, and if you’re interested in learning more you have the knowledge needed to give the whitepaper a full read.
Resources
How about giving some claps?
If you enjoyed this article, feel free to clap many times or share with a friend. This lets me know my work is helping, and encourages me to write more.
Also — if you’d like to see more of these 🍌Banana Papers, comment below and let me know which blockchain projects you are interested in, and would like to understand a little better.
Michael Bogan is a tech enthusiast with 25 years of technical architecture, founding startups, product launches, and researching blockchain projects.
