Network Effects in Generalized State Channels
One of the talks at ETHDenver which I unfortunately missed was about generalized state channels. Luckily, the talk was recorded and you are able to see it below. This article is for dApp developers who are interested in building on top of this technology. Also, in my effort to learn, I will try to teach.
I am a hacker/app-builder and concerned Etherian and am intrigued by the promise of this technology to help improve dApp scalability and user experience. I will try to summarize some of the implications of the talk, which might pique your interest enough to schedule to watch the full video later, if you haven’t already.
The innovation presented is a design pattern called “counterfactually instantiated contracts”. These are smart contracts which don’t have to be deployed on-chain at all in order to be used in a state channel dApplication. After being run through a compiler, their bytecode can be combined with the signatures of the state channel participants to deterministically produce a signed message with a “counterfactual address” (ex. 0xc407e) that acts as a reference. This message is called a counterfactual instantiation of the original contract. So far, all of this can be done off-chain.
Then, the state channel participants can exchange signed messages off-chain that modify the state of the channel while referencing the counterfactual address 0xc407e as the enforcement mechanism. For those new to the idea of channelized applications, they rely on an enforcement mechanism (i.e. a smart contract) that participants can use to claim invalid/fraudulent messages, like the other participants claiming they have more money (i.e. different state) than they actually do.
The counterfactually instantiated contract is “deployed” via its listing in a central registry contract on-chain. The counterfactual contract at address 0xc407e can then be referenced by all participants by both contracts on-chain (via the mapping of the counterfactual address to the on-chain address; this mapping is a function of the registry contract) as well as counterfactually instantiated contracts off-chain. Off-chain, the counterfactual contract is not actually deployed, just instantiated. This instantiation creates a threat of deployment in the case of invalid state changes and works as an enforcement mechanism just the same as a “judge” contract in a payment channel.
This allows participants to use the state channel and exchange as many messages as they want, without affecting on-chain scalability. Furthermore, this activity is public to the participants, but private from observers outside of the channel.
The fact that all instantiations use a single registry contract allows for a dependency tree of counterfactually instantiated contracts which do not need to be deployed on-chain absent a dispute. If I understand correctly, this requires all nodes in the tree to reference the same on-chain registry contract. The assumption of the same on-chain registry contract is what anchors the node graph and allows for the modularity and inter-dependencies seen below.
If an invalid message is claimed by one participant, the other participants can use the previously determined bytecode and participant signatures to deploy the counterfactual contract on to the chain. Then, they can provide any proof of messages that they have which goes against the invalid message and the enforcement mechanism will correctly settle the dispute. Notably, the dispute can be “localized”, meaning a dispute in the chess state channel should not affect the atomic swap state channel.
Otherwise, if everybody gets along and participants want to simply close the channel, then they can also deploy the counterfactual contract on-chain. Along with claims of the last state by the participants, this settles the final state of the channel.
Network Effects
What I’m still trying to wrap my head around is what kind of network effects emerge as a result of this design pattern. Assuming the on-chain registry is what anchors the network of counterfactually instantiated contracts, then accumulating developers and users within an ecosystem surrounding a single registry is extremely valuable. This is because of the properties of the design pattern:
- State channel applications do not have to be “installed” by each user. Here, install means the typical steps required for opening a state channel, including on-chain contract (enforcement mechanism) deployment. Instead, a new contract can be counterfactually instantiated off-chain, and immediately used. This is a game-changer for user experience and blockchain scalability.
- State channel applications that are counterfactually instantiated can reference other counterfactually instantiated contracts as part of a dependency tree. The implications of this are yet to be revealed, but my guess is that this modularity is generally a good thing and this will have benefits for dApps within the network. A tech stack could appear, where one state channel dApp is compatible with another. Developers who are familiar with generalized state channels can coordinate around these standards, increasing collaboration and build opportunities.
It might be possible to have multiple instances of the “global” counterfactual contract registry. Since there are dependencies between state channel dApplications (within the same registry namespace), you want all of these dApps to be on the same page. Indeed, the presentation and announcement alluded to the fact that generalized state channels can be implemented on any Turing-complete blockchain platform. But, as I’ve shown above, there are potentially network effects that emerge from using a single, dominant state channel registry per blockchain. How strong these network effects are is an open question.
If the central registry is the thing that anchors a state channel ecosystem namespace, then its possible that multiple registries can exist on the same blockchain. These would then compete for users and dApp developers. From an end-user perspective, they could be interoperable if the user provided the address of the registry as a setting while using the dApp. In practice there might be other limitations of having multiple, competing registries. It is possible that the registry itself is considered infrastructure subject to temptations of greater control and influence, meaning the governance of the registry contract requires decentralized governance, with upgrades decided by a network of token holders.
Sound familiar?
Next Up: Integration
From my work on Workspace0x, I know that supply chains offer opportunities for industry integration, either vertically or horizontally. In my next article, I will write about opportunities for integration within the context of generalized state channels. Thanks to L4 for an awesome innovation, and stay tuned!
Use your magnificent powers of curation by clapping or sharing if you enjoyed the article. I am a freelance cryptoeconomic researcher, and am available for consulting and front-end development work in the blockchain industry. The best compliment and way to support my objective research would be a tip to this ETH address: 0xe7f2c56369E32f67dBCdD5F5ca4712D599aD4715
