Flow Chart

1. Submitting transactions

   As a user, you submit transactions by signing transactions and sending them through the JSON-RPC interface.

2. Executing transactions

   The transactions are then stored in the pending transaction pool, where the sequencer node running the zkEVM software picks these transactions up and decides which ones it wants to process or discard. The sequencer will do a few of the following checks to see if the transaction should be discarded or processed:

   • If the sender has sufficient funds to complete the transaction

   • If the smart contract called actually exists and contains valid bytecode

   • If the transaction is not a duplicate

   • If the transaction does not involve a "double-spend", which means the sender's funds have not already been used in another transaction

   

   Once the transaction is considered valid, the sequencer will update the Ryoshi state. Users will experience transactions going through almost instantly. From here onwards, the user remains engaged in the Ryoshi L2 state. Everything that follows involves sharing transaction data back to Ethereum L1, but this step is only important for users who wish to transfer their funds from Ryoshi L2 back to Ethereum L1.

3. Batching transactions

   The sequencer combines multiple transactions into a single batch and sends them to the zkEVM.sol smart contract. This contract is stored on Ethereum mainnet and also has a separate version on the Ethereum Sepolia testnet. Batches are not necessarily validated or confirmed at this stage.

4. Verifying transactions

   Using ZKPs, the zkEVM.sol smart contract acts as a verifier in verifying transactions. It verifies whether the batch just received is valid or not, through sending the batch to an aggregator node.

5. Generating & verifying zk-proofs/validity proofs

   The zkEVM.sol smart contract sends the batch it just received to an aggregator node, which is a machine running zkEVM software that communicates with a zkProver. The flow is as follows:

   • The aggregator receives the batch from the smart contract

   • The aggregator sends the batch to the zkProver

   • The zkProver creates multiple zk-STARKs -> a single zk-STARK -> a zk-SNARK

   • The zk-SNARK (the validity proof) gets sent back to the aggregator

   • The aggregator sends back the validity proof to the zkEVM.sol smart contract

   • zkEVM.sol verifies the validity proof

   • If the validity proof is valid, accept it

   • If it is not valid, reject it

6. Reading events on Ryoshi

   Finally, DApps read information from Ryoshi through the synchronizer. It reads events from the Ethereum smart contract(s), storing knowledge of both the zk-validity proofs from the aggregator, and the batches submitted from the sequencer. This way, DApps can easily get a view of the state of Ryoshi via JSON-RPC.