Ephemeral ZK L3s

This project focuses on enhancing scalability, reducing transaction costs, increasing throughput and improving transaction speed for end users. We try to demo how using state channels we can give web2 gaming experience to users in web3. We try to minimize on-chain footprint by recursively aggregating state changes made by the players in the state channel using their in-game moves and verifying the final game state using the zk-proof at the end of the game.

There are a total of three components of the infrastructure we had built to build our own ephemeral L3

Local State manager App sequencer State transition function

Local State Manager works for managing the app state locally and it provides the level 1 confirmation of state changes which has been requested by the user. The application which is using the L3 would have to built their own local state manager (further we are trying to make it as general as possible and would try to improve the experience of building local state manager for the user) In context of the demo we have built our own custom local state manager in typescript for the guess game app. Further local state manager also enable user to make request for performing actual state transition

App Sequencer: it is a really crucial components of the L3 infrastructure as it is responsible to cache all the state transition requested by the user. Then generate the plonky2 proof of those state transition in a recursive manner (recursive because we need to make sure that the current state transition is in consistent with the previous state transitions) once the proof generation and verification completes (recursive proof generate and verification in here works as an analogy to state channels where user agrees to a particular state transitions and starts making offchain state transition in a consistent manner so instead of agreement we are enable user to prove the valid state transition to enable state transitions by users in a trustless manner). It basically start dumping the state transition to the L2 or L1 in a periodic manner to any DA layer configured by the developer.

State Transition function Due to time constraints we haven’t made the state transition function much modular but as a future scope we want to make the state transition function as modular as possible in a way that dapp developer should be able to define their own stf function build a executable binary out of it and upload it to the app sequencer to enable app sequencer to start understanding the state transition function this modular nature would help the app sequencer to not get siloed for single app instead it would enable devs to use a single app sequencer for multiple apps.