# Reviving State Channels with Zero Knowledge Proofs
<div style="text-align:center;">
<img src="https://i.imgur.com/gjMwRIP.jpg" alt="DALL-E Abstract Art on a Social Graph of Economic Interactions" style="max-width:75%;">
<p><em>DALL-E Abstract Art on a Social Graph of Economic Interactions</em></p>
</div>
"Privacy and scalability" are two of the most coveted properties in web3 R&D in 2023. Be it the

The scalability of decentralized ledgers has been a persistent challenge since their popularization. In short, the *scalability trilemma* presents an unavoidable tradeoff between decentralization, security, and performance when executing code in decentralized environments. Today, [ZK Rollups](https://vitalik.ca/general/2021/12/06/endgame.html) are provide layer two interactions that cut layer one EVM verification costs by orders of magnitude with minimal sacrifices to decentralization and security.

Basic *Zero Knowledge* Rollups do not encrypt, obscure, or otherwise anonymize any information. Instead, zero knowledge proofs serve as the engine for *verifiable computations* (FURTHER READING LINK NEEDED). A verifiable computation offloads the execution of a function to untrusted clients while outputting verifiable results. A Layer 2 ZK Rollup posts roots of layer 2 chain state with accompanying proofs that the transition in roots represents a bundle of valid transactions. While ZK Rollups themselves have throughput boundaries, they offer the first solution for Ethereum to subvert the the *scalability trilemma*.

<div style="text-align:center;">
<img src="https://i0.wp.com/conversableeconomist.com/wp-content/uploads/2022/06/image-8.png?w=535&ssl=1" alt="Vitalik Buterin's Scalability Trilemma" style="max-width:100%;">
<p><em>The Scalability Trilemma (source needed)</em></p>
</div>

However in 2018, in the early days of the growing pains of decentralized networks, resources and fervor for scaling centered around the *state channel*.

State Channels had no such state verification, instead relying on authoritative commitments from all involved parties. This allows layer-two peer-to-peer transacting at unrivaled speeds, however it introduces optimistic trust assumptions. In order to prevent double spends with state state by dishonest counterparties, clients must themselves watch the chain, or outsource this responsibility to a third party. The overhead of optimistic watchtowers is far greater for an indeterminant amount of state channels than it is for a monolithic rollup, and the optimistic rollup quickly became the focus of scaling efforts.

As the practice of verifiable computation continues to mature, it is time to revisit the state channel construction and see how we zero knowledge can remove optimisim in every case but a time-out. By the end, we will present a new tool for both privacy and scalability that modularly performs in any EVM layer.

## What are (Zero Knowledge) State Channels

This blog post is an informal summary of the intended features of Zero Knowledge State Channels, with everything being subject to scrutiny and change with further R&D.

Zero Knowledge State Channels are application-specific zero knowledge circuits that recursively bundle many state iterations into one single summary proof. As would be expected of an optimistic state channel, this summary provides scalability by allowing many state changes to happen off-chain with a single on-chain verification. However, this summary also can also abridge or hide information according to the needs of the application. Complex and detailed multi-step operations can be summarized into a few parameters along with a proof of validity.

<br>

<div style="text-align:center;">
<img src="https://i.imgur.com/KazTRzk.png" alt="Battleship State Channel Diagram" style="max-width:100%;">
<p><em>An (over)generalization of a ZK State Channel setup for the game Battleships</em></p>
</div>

<br>

Where optimistic state channels derive their value proposition from > 1000 TPS transacting, ZK state channels find significant opportunity at even a throughput of 1 TPS.

ZK State Channels

Zero Knowledge proofs facilitate "verifiable computations" in which the computation of an arbitrary function can be offloaded to an untrusted party, without revealing inputs, while guaranteeing the credibility of the output.

=-=-=-=
* A state channel proof is a recursively built state proof that notatizes the integrity of a multi-step computation
* Application-specific logic governs what steps can be taken at a given point
* Escape/ exit conditions for a state channel must be explicitly defined in the state
* Can only be finalized on-chain when a specific outcome condition is met

=-=-=-=

State channels originally were designed with the intention of facilitating hundreds or thousands of transactions per second between two parties. With zkChannels, this would open a host of usecases around information exchange and gaming, it is far from necessary for the majority of interesting real-world applications. These channels are envisioned with common peer-to-peer economic interactions in mind.

Another important difference is that optimistic state channels can have an indefinite amount of steps and remain open theoretically forever, a zk state channel has an arbitrary but finite amount of steps. Further, while optimistic state channels could be closed at any time, a zk channel can only be closed if certain conditions are met, allowing the channel to produce an outcome. This means that a zk channel must explicitly encode escape logic

## Example: Invoice Factoring

<br>

<div style="text-align:center;">
<img src="https://i.imgur.com/v24pwn0.jpg" alt="DALL-E's Drawing of A Supply Chain" style="max-width:50%;">
<p><em>A man accepting a shipment from a truck to a cargo bay, as drawn by DALL-E</em></p>
</div>

<br>
![]()

When a seller recieves a "purchase order" documenting the goods or services a buyer is requesting, they need to manufacture and deliver the product *before* any money changes hands. Suppliers that cannot themselves afford to fulfill lucrative orders can turn to third party financiers who will purchase these unpaid obligations at a discount. While this practice generally increases competition in the market by decreasing barriers to entry, the infestation of intermediaries makes it ripe for disruption by web3.

Unfortunately, the issues of privacy and scalability prevent public or even private blockchains from being a proper competitor to centralized systems. Costs on the root chain are prohibitively expensive (anecode: I was on a call building an invoice factoring project where they agreed to subsidize $1Mm of gas as cost of customer acquisition). Even if we were to settle transactions on a rollup, costs still are orders of magnitude more expensive than web2 interactions. Even more detrimental is the fact that this practice exposes ALL state on chain. It is impossible to participate

## Problems to be Solved
Consider a scenario where you're playing Battleships over a ZK state channel, and your opponent just sunk the last ship on your board. The circuit will force you to generate a state transition that has a negative personal impact, so why respond in the first place?

We expect that ZK state channels that need timeouts will need to employ a third-party "transponder" oracle committee capable of attesting to the time and order of transactions without knowing anything else. While a cryptographic solution such as a VDF would be ideal, current methodologies introduce optimistic trust assumptions. Clients would have to watch the chain for a dishonest assertion of a timeout. While *transponders* widen the circle of trust, they provide proactive guarantees that a client has not timed out. In short, enlisting a third party to attest to responsiveness is critical for instant finality.

Data Availability is a separate consideration. Potentially, ZK State Channels could claim agnosticism to the data layer and care only about the verifiable computation. In a radically decentralized ZK State Channel, each user would bring their own data store. The channel would only coordinate the construction of the confidential multi-party computation between all involved clients. Enterprises with existing databases seeking to synchronize with counterparties therefore present an obvious first market, and state channels are natively a tool for [Baselining](https://github.com/eea-oasis/baseline-standard/blob/main/core/baseline-core-v1.0-psd01.md). However, the vast majority of developers will not have existing data stores nor be interested in running centralized stores. Thus, ZK State Channels will eventually need a data store.

BattleZips iteratively proves the concept of ZK State Channels, and currently makes no attempt to address data availability. [GunDB](https://gun.eco/) will be used to store persistent state in the early versions. However, ZK State Channels intends to explore the use of [Celestia](https://celestia.space/) for ordering and persisting state. This sacrifices some of the privacy afforded by going off of any chain, but could be an available option for those who can't or won't use off-chain data stores.