# Reviving State Channels using Zero Knowledge Cryptography

### Note: this is a draft for content. it will be brief and shitty

Ever since the bitcoin blockchain went live there have been efforts to increase the throughput of decentralized ledgers. So far, monolithic solutions have all succumbed to the *scalability trilemma.* This is because, with the exception of state channels, every scalability solution requires computations to be done by every node in the network. Rollups just pass the buck - instead of EVM validators, you now have a network of zkEVM sequencers responsible for the execution of app logic. The code is executed off of the main-chain, but it isn't actually off-chain.

<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="A beautiful landscape" style="max-width:100%;">
<p>"Pick Two"</p>
</div>

Helium: A "state channel" facilitates off-block transactions which get persisted to the Blockchain as a single transaction

The issue here is a failure to properly utilise a blockchain at apex capacity. The root ethereum chain is not an environment anyone should be executing application/ business logic inside of, for both privacy and scalability reasons. Zero Knowledge proofs enable "Verifiable Computing", a practice which must necessarily be used extensively throughout the web3 stack to shift state computation from the chain to clients.

State Channels were ahead of their time. At one point, they were hailed as the savior of scaling. Now they are obsucre. In preimse, state channels are fairly simple. They are crytographially-secured state objects that are incrementally mutated by pre-determined parties in a multisignature agreement. Put more simply, Gnosis Safe is, by our definition, the most simple possible state channel.

In practice, however, state channels present an optimisic trust model, where parties must watch the settlement layer and be ready to submit fraud proofs if a counterparty acts maliciously. Meanwhile, honest optimistic transactions take longer to confirm than a Swift ACH transfer. It is likely that the larger scaling community rallied around optimistic rollups over optimistic state channels because it is *far* easier to watch one monolithic chain than countless ephemeral channels.

State channels pre-computed all the steps and removed *some* of the on-chain overhead. However, the on-chain verifier of a state channel batches each interstitial step in memory.
## Definiton of an Application-Specific ZK State Channel
- Participants and roles are assigned at instantiation of the state channel and cannot be changed unless this specific business logic is creted
- Only the participants in the state channel participate in consensus for state channel computation
- An application-specific ZK State Channel can have an indeterminant amount of steps so long as it is finitie
- zkChannels are Directed Acyclic Graphs (DAGs) of possible outcomes. If one outcome is satisfied, the others necessarily cannot be satisfied. There are no checkpoints, and the state channel proof will fail if one of the outcomes is not satisfied. Therefore, finality on-chain is instant and immune to stale state attacks
- A completed ZK State Channel is notarized on-chain via a state-channel proof summarizing the multi-party computation that occured within the state channel. As predetermined during State Channel instantiation (or further, as a forced instantiation by the smart contrct)
- Being low latency is nice; we want sub-second proof times for UX. More than 2-3 actions per second in a zk state channel is only really useful for video gaming
-

### Remaining issues:
available tech / proving time: plonky2 is technically for a validium not zk so there are some questions on like succinctness or something? IDK exactly (need to research) but it is inferior to Halo2 in terms of computational security (citation needed)
- non-responsiveness - VDF + penalize non-responsiveness
- data availability: the goal is to be entirely p2p but this just is not possible to compete with web2. Proper state channel applications will allow users to either manage the storage of state locally (still needs to be browser-based) or use a third-party that holds onto the data needed to rebuild/ prove state channel. Enterprise usecases can very comfortably rely on their legacy data storage solutions here. For web3, we want to do further R&D on whether something like Tornado Cash for information is possible
https://vitalik.ca/general/2021/01/05/rollup.html
https://www.jeffcoleman.ca/state-channels/