# ZK State Channels in Aztec 3

Mach 34 recently experimented with

## What is a State Channel?
Blockchain computations are expensive. Even on L2, paying $0.04/tx can be prohibitively expensive in the context of web2 operations that cost fractions of a cent. State channels are a way to iteratively construct state offchain with the result of the computation posted onchain.

## What is a ZK State Channel?

## A Short Intro to Aztec3's Private Kernel Circuit
Aztec3 is a privacy-preserving L2 rollup with a smart contracting language written in Noir. While traditional smart contracts define code that executes onchain, private functions in Aztec smart contracts are circuits that exist in a sort of vaccuum isolated from the chain. The base building block of a private transaction is a "Kernel Circuit" which verifies the execution of an "app" circuit (the function being called) and a previous kernel circuit recursively, as is shown below:
- 

In short, the Kernel circuit stitches together the callstack of potentially complex smart contract execution. Inside these private circuits, we can make "oracle" calls that provide private values during witness generation (rather than as function parameters). As mentioned, circuits exist by themselves and have no concept of the private state stored in the [private state tree](https://docs.aztec.network/concepts/advanced/data_structures/trees#note-hash-tree). To privately and verifiably work with Aztec3 state, oracles provide access to notes inside of circuits. Kernel proofs will provide the merkle inclusion proofs for note CRUD operations, allowing sequencers to ultimately constrain the access of blockchain state privately used in

You can [learn more about how Kernel circuits function here](https://www.youtube.com/watch?v=6rTQFBYvOpA).

## Hijacking Aztec3's Kernel Circuit for ZK State Channels
[Originally proposed by Aztec's Jan Beneš](https://forum.aztec.network/t/abusing-private-kernel-to-create-state-channel-scheme/2550), the recursive nature of Kernel Circuits lends itself to the p2p

## Benefits of Kernel Circuit State Channels

## Prohibitive Issues with Kernel Circuit State Channels
The prohibitive issue with Kernel Circuits is the need for the entire callstack to be simulated before proving can be completed. In normal transactions, this makese sense. Take a case where private function A calls private function B, utilising the result of function B inside of function A. In Zero Knowledge, the *entire* witness must be known when proving. It would be impossible to prove function A without knowing what the result from function B would be. The kernel circuit for function A thus relies on commitments to the exeuction of function B. Furthermore, at any given point (with few exceptions deep in the channel) it is impossible to predict the depth of the callstack. A payment channel could facilitate 5 tranfers or 50 transfers; a game of tic tac toe could be won in 5 moves or could result in a draw after 9 moves.

It is reasonably possible for the kernel circuit to verify the intent of the callstack at a given point without knowing the entire depth of the callstack or knowing the exact result always. However, this would require changes to arguably the most critical component of the Aztec3 blockchain (not to mention potential negative effects on efficiency). While we believe that accomodation of this usecase could uniquely position Aztec to natively provide a unique tool of privacy and scalability, it would be understandable to delegate state channel architecture to the application level.

## Additional Issues with kernel Circuit State Channels

## Circuit-based ZK State Channels
Alternatively, as Mach 34 has explored previously with [Plonky2](https://github.com/battlezips/battlezips-plonky2), ZK State Channels can be constructed with circuits and traditional smart contracts.