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 Tech aims to improve scalability and performance in blockchains using ZK-FOAKS (Zero-Knowledge Fast Objective Argument of Knowledges) technology, providing cryptographic proofs that are zero-knowledge, no need for a trusted setup, quantum secure, and fully EVM-compatible.
Fox is building a ZK-EVM Rollups with a strong proof network, combining software and hardware to support fast and reliable generation and verification of computational integrity proofs for general computations, on which the universal dApps can easily be deployed and get their compatibilities.
Along with the high gas and the slow problem of Ethereum, ZK-Rollup is recognized as the best scaling solution for Ethereum to fix it. It is as secure as Ethereum and has the shortest finalizing time compared to all other Layer 2 solutions such as State Channels and Plasma.
The basic idea of zk-Rollup is to aggregate a huge number of transactions into one Rollup block and generate a succinct proof for the block off-chain. Then the smart contract on Layer 1 only needs to verify the proof and apply the updated state directly without re-executing those transactions. This can help save the gas fee by an order of magnitude since proof verification is much cheaper than re-executing computations. Another saving comes from data compression, which only keeps minimum on-chain data for verification. In the Fox solution, we are able to save another 50% gas fee from Ring’s eternal on-chain data service.
Fox Tech uses Validity Proofs that present evidence that a state transition is correct. Validity Proofs reflect a more pessimistic view of the world. Blocks include values representing the L2 state only if that state is correct. A representation of some off-chain computation is sent to a smart contract. The smart contract updates the blockchain with this new value only after it is verified as correct. The main advantages of Validity Proofs are that the blockchain will always reflect a correct L2 state and that a new state can be immediately relied upon and used. The main disadvantage is that proofs are needed for each and every state transition, and not merely when such a transition is contested, and this impacts scalability. In the Fox solution, we use ZK-FOAKS to solve the scalability under Validity Proofs.
Although the validity proofs of ZK-Rollup are secure and efficient, the common applications are still limited to swaps and ERC-20 token transfers. It’s hard to build general-purpose DApps due to the following two reasons.
First, if projects want to develop DApps in a ZK-Rollup, they need to write all smart contract logic using a special and complicated language which requires extremely strong expertise in zero-knowledge proof. Second, different applications can’t interact with each other within the same zk-Rollup Layer 2, significantly undermining the composability of DeFi applications.
In a word, ZK-Rollup is developer-unfriendly and has limited functionality and composability for now without ZK-EVM. That’s the tricky problem we want to tackle. We want to provide the best developer experience and support composability within Layer 2 by supporting native EVM verification directly, so that existing Ethereum applications can simply migrate over onto the zk-Rollup. That is the reason why we are building the zkEVM.
ZK-Rollup is already more mature with regard to specialized applications but will travel a more gradual path with fully generalized smart contracts. Eventually, it will be possible to port any ZK-EVM-based smart contract to ZK Rollup. We estimate it will come true at the end of 2022 at the current pace of Fox's technological development.
To understand the role of zkEVM, we had better start with Ethereum, which is essentially a transaction-based state machine. In computer science, a state machine is a machine that transitions from an old state to a new state by reading a series of inputs. This state contains the status of all account addresses and their mappings.
The EVM, or Ethereum virtual machine, handles transactions. EVM runs as a stack machine in which programmers write code in high-level languages such as Solidity, which is then compiled into EVM bytecode that EVM can understand. The EVM performs standard stack operations as various EVM opcodes, eventually producing a new state.
Now here's the problem. We know that the ZK Rollup solution needs to generate zero-knowledge proofs for transactions on L2 and send them back to L1 for verification. To generate zero-knowledge proofs, transactions need to be processed in accordance with the ZK circuit proof specification. And when EVM was first designed a few years ago, the designers did not consider supporting zero-knowledge proofs. So we need zkEVM. Technically, zkEVM means a virtual machine running on a ZK Rollup network, EVM-compatible and zero-knowledge proof-friendly.
More and more, we see zkEVM as the key to scaling Ethereum increasingly. However, zkEVM is difficult to build. Despite years of intuition, no one has managed to build a native EVM circuit. Designing and implementing zkEVM is challenging for the following reasons:
But why is zkEVM possible now? Thanks to the great progress made by researchers in this area, more and more efficiency problems have been solved in the last several years, and the proven cost of zkEVM is finally feasible! The biggest technological advances come from the following aspects:
There are two main implementation strategies for zkEVM.
For the first strategy, because it fully supports the existing set of EVM opcodes and uses the same compiler as EVM, it is naturally fully compatible with existing ecosystems and development tools and better inherits Ethereum's security model.
The second strategy is not constrained by the original EVM opcode set, so it is more flexible to compile code into a more zero-knowledge proof-friendly opcode set. It also eliminates the heavy lifting required to be compatible with all the original EVM opcodes.
Overall, the first strategy is more compatible and secure, but requires more work; The second strategy is more flexible and requires less work, but requires additional adaptation effort. Fox chooses the first strategy as the best developer-friendly and highest security level solution.
Further, there are two ways to build a universal DApp in zkRollup.
The first and early one is to build dedicated circuits (" ASIC ") for different DApps. It requires developers to design specialized "ASIC" circuits for different DApps. This is the most traditional way to use zero-knowledge proofs. By customizing the circuit design, each DApp will have lower overhead. However, it introduces composability problems because circuits are "static" and the developer experience is poor due to the need for strong circuit design expertise.
This is a fatal problem at the early stage. So we choose the second way: to build a general "EVM" circuit for smart contract execution. This approach does not require any special ZKP designer or developer expertise from the dApp side. The advanced idea of this machine-based proof is that any program will eventually run on the hardware, so we only need to build a universal CPU circuit to validate the low-level CPU steps. We can then use this CPU circuit to verify the execution of any program.