Fox is an Ethereum zkRollup using ZK-EVM and its original ZK-FOAKS technology. ZK-STARKS comes from Zero Knowledge - Fast Objective Argument of Knowledges that is faster than Stark with linear proof time, sublinear verification time, transparent, and proof recursion inside.

FOX is a scaling EVM-compatable engine for Ethereum. FOX is built on ZK Rollup architecture. ZK Rollup is an L2 scaling solution in which all funds are held by a smart contract on the mainchain, and Fox layer 3 is a high-performance or privacy solution.

DesignFor every Rollup block, a state transition zero-knowledge proof (ZK-FOAKS) is generated and verified by the mainchain contract. This ZK-FOAKS includes the proof of the validity of every single transaction in the Rollup block. Additionally, the public data update for every block is published over other networks at a lower cost.

Our architecture provides the following guarantees:

• The Folder(s) can never corrupt the state or steal funds (unlike side chains).

• Users can always retrieve the funds from FOX even if the folder(s) stop cooperation because the data is available (unlike Plasma).

There are 3 main parts in the Fox architecture: Sequencer, Folders, and L1 Contracts:

• Sequencer gathers transactions, runs the Geth node, leaves the traces of the execution for Folders, and sends the data to ZK-Ringer, which is deployed on other networks, IPFS, or decentralized storage.

• Folders use the traces to generate zero-knowledge proofs for every circuit. The folders then send the aggregated proofs as well as the updated states to the L1 Contracts. The Folder is the core of the Fox system.

• L1 Contracts keep all user’s funds, keep the states, verify the zero-knowledge proofs while updating the states, and manage the deposit and withdraw requests of users.

Folders calculate proof and commit to the L1 FOX contract through the Double-Deck Express. In this session, we illustrate the core logic of Layer 2 and explain what Folders need to prove in a conceptual way. The detailed proof algorithm can be found in the next two chapters.

Even if the workflow outside remains the same, the underlying processing procedure for Layer 1 and Layer 2 are entirely different:

Layer 1 relies on the re-execution of smart contracts.

Layer 2 relies on the validity proof of zkEVM circuit.

Let’s give a more detailed explanation of how things are going differently for transactions on Layer 1 and Layer 2.

In Layer 1, the bytecodes of the deployed smart contracts are stored in the Ethereum storage. Transactions will be broadcasted in a P2P network. For each transaction, each full node needs to load the corresponding bytecode and execute it on EVM to reach the same state (transaction will be used as input data).

In Layer 2, the bytecode is also stored in the storage and users will behave in the same way. Transactions will be sent off-chain to a centralized zkEVM node. Then, instead of just executing the bytecode, zkEVM will generate succinct proof to prove the states are updated correctly after applying the transactions. Finally, the Layer 1 contract will verify the proof and update the states without re-executing the transactions.

Let’s take a deeper look at the execution process and see what zkEVM needs to prove at the end of the day. In native execution, EVM will load the bytecode and execute the opcodes in the bytecode one by one from the beginning. Each opcode can be thought of as doing the following three sub-steps : (i) Read elements from stack, memory, or storage (ii) Perform some computation on those elements (iii) Write back results to stack, memory, or storage. For example, add opcode needs to read two elements from the stack, add them up and write the result back to the stack.

So, it’s clear that the proof of zkEVM needs to contain the following aspects corresponding to the execution process

• The bytecode is correctly loaded from persistent storage (You are running the correct opcode loaded from a given address)

• The opcodes in the bytecode are executed one by one consistently (They bytecode is executed in order without missing or skipping any opcode)

• Each opcode is executed correctly (Three sub-steps in each opcode are carried out correctly, R/W + computation)

Fox is an Ethereum zkRollup using ZK-EVM and its original ZK-FOAKS technology. ZK-STARKS comes from Zero Knowledge - Fast Objective Argument of Knowledges that is faster than Stark with linear proof time, sublinear verification time, transparent, and proof recursion inside.

FOX is a scaling EVM-compatable engine for Ethereum. FOX is built on ZK Rollup architecture. ZK Rollup is an L2 scaling solution in which all funds are held by a smart contract on the mainchain, and Fox layer 3 is a high-performance or privacy solution.

DesignFor every Rollup block, a state transition zero-knowledge proof (ZK-FOAKS) is generated and verified by the mainchain contract. This ZK-FOAKS includes the proof of the validity of every single transaction in the Rollup block. Additionally, the public data update for every block is published over other networks at a lower cost.

Our architecture provides the following guarantees:

• The Folder(s) can never corrupt the state or steal funds (unlike side chains).

• Users can always retrieve the funds from FOX even if the folder(s) stop cooperation because the data is available (unlike Plasma).

There are 3 main parts in the Fox architecture: Sequencer, Folders, and L1 Contracts:

• Sequencer gathers transactions, runs the Geth node, leaves the traces of the execution for Folders, and sends the data to ZK-Ringer, which is deployed on other networks, IPFS, or decentralized storage.

• Folders use the traces to generate zero-knowledge proofs for every circuit. The folders then send the aggregated proofs as well as the updated states to the L1 Contracts. The Folder is the core of the Fox system.

• L1 Contracts keep all user’s funds, keep the states, verify the zero-knowledge proofs while updating the states, and manage the deposit and withdraw requests of users.

Folders calculate proof and commit to the L1 FOX contract through the Double-Deck Express. In this session, we illustrate the core logic of Layer 2 and explain what Folders need to prove in a conceptual way. The detailed proof algorithm can be found in the next two chapters.

Even if the workflow outside remains the same, the underlying processing procedure for Layer 1 and Layer 2 are entirely different:

Layer 1 relies on the re-execution of smart contracts.

Layer 2 relies on the validity proof of zkEVM circuit.

Let’s give a more detailed explanation of how things are going differently for transactions on Layer 1 and Layer 2.

In Layer 1, the bytecodes of the deployed smart contracts are stored in the Ethereum storage. Transactions will be broadcasted in a P2P network. For each transaction, each full node needs to load the corresponding bytecode and execute it on EVM to reach the same state (transaction will be used as input data).

In Layer 2, the bytecode is also stored in the storage and users will behave in the same way. Transactions will be sent off-chain to a centralized zkEVM node. Then, instead of just executing the bytecode, zkEVM will generate succinct proof to prove the states are updated correctly after applying the transactions. Finally, the Layer 1 contract will verify the proof and update the states without re-executing the transactions.

Let’s take a deeper look at the execution process and see what zkEVM needs to prove at the end of the day. In native execution, EVM will load the bytecode and execute the opcodes in the bytecode one by one from the beginning. Each opcode can be thought of as doing the following three sub-steps : (i) Read elements from stack, memory, or storage (ii) Perform some computation on those elements (iii) Write back results to stack, memory, or storage. For example, add opcode needs to read two elements from the stack, add them up and write the result back to the stack.

So, it’s clear that the proof of zkEVM needs to contain the following aspects corresponding to the execution process

• The bytecode is correctly loaded from persistent storage (You are running the correct opcode loaded from a given address)

• The opcodes in the bytecode are executed one by one consistently (They bytecode is executed in order without missing or skipping any opcode)

• Each opcode is executed correctly (Three sub-steps in each opcode are carried out correctly, R/W + computation)