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.

Background

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.

ZK-EVM

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:

• EVM has limited support for elliptic curves. Currently, EVM only supports BN254 pairing. It is difficult to prove recursion because cyclic elliptic curves are not directly supported. It is also difficult to use other proprietary protocols in this setting. The validation algorithm must be EVM-friendly.
• The EVM character length is 256 characters. EVM runs on 256-bit integers (much like most regular VMS run on 32-64 bit integers), while ZK turns out to work most "naturally" on prime fields. Doing "mismatched field arithmetic" inside the circuit requires proof of scope, which adds about 100 constraints to each EVM step. This requires 25600 bits, increasing the EVM circuit size by two orders of magnitude.
• EVM has a number of special opcodes. EVM differs from traditional VM in that it has many special opcodes, such as CALL, and error types related to execution context and gas. This brings new challenges to circuit design.
• EVM is a stack-based virtual machine. The SyncVM (zkSync) and Cairo (StarkWare) architectures define their IR/AIR in register-based models. They built a specialized compiler to compile the smart contract code into a new ZK-friendly IR. Their approach is language compatibility rather than native EVM compatibility. Fox zkEVM is a stack-based model and direct support for native toolchains which is also harder to prove.
• The Ethereum storage layout introduces significant overhead. Ethereum storage layouts are highly dependent on Keccak and huge MPT, both of which are not ZK-friendly and have huge proof overhead. For example, the Keccak hash is 1000 times larger than the Poseidon hash in the circuit. However, replacing Keccak with another hash can cause some compatibility issues with the existing Ethereum infrastructure.
• Machine-based proofs are significantly overhead. Even if you can handle all of the above, you still need to find an efficient way to put them together to get a complete EVM circuit. Even simple opcodes like ADD can cause overhead for the entire EVM circuit.

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:

• Use of polynomial commitments. Over the past few years, most compact zero-knowledge proof protocols have stuck with R1CS, encoding PCP queries in application-specific trusted Settings. Circuit sizes often explode, and can't do many custom optimizations because the degree of each constraint needs to be 2 (bilinear pairings only allow one multiplication in the exponent). With a polynomial commitment scheme, we can elevate the constraints to any degree with generic or even transparent Settings. This provides great flexibility in backend selection.
• Lookup table parameters and the appearance of custom widgets. Another powerful optimization comes from the use of lookup tables. Optimization was first proposed in Arya and then optimized in Plookup. This can save a lot on ZK unfriendly primitives (that is, bitwise operations like AND, XOR, etc.). Custom widgets allow us to be highly constrained efficiently. TurboPlonk and UltraPlonk define elegant program syntax to make it easier to use lookup tables and define custom widgets. This is very helpful in reducing the overhead of EVM circuits.
• The recursive proof is becoming more and more feasible. Recursive proofs have been costly in the past because they relied on special pair-friendly cyclic elliptic curves (i.e. constructions based on MNT curves). This introduces significant computational overhead. Yet more technology makes this possible without sacrificing efficiency. For example, Halo can avoid the need for pairwise curves and use special inner product parameters to amortize recursive costs. We can also do proof aggregation directly against existing protocols (lookup tables reduce the overhead of non-local field operations, thus making the validation circuit smaller). It can greatly improve the scalability of supported circuit sizes.
• Hardware acceleration makes proof more efficient. To the best of our knowledge, we build the fastest GPU and ASIC/FPGA accelerators for the prover. The GPU prover is about 5 to 10 times faster than the Filecoin implementation. This can greatly improve the efficiency of the prover's calculation.

There are two main implementation strategies for zkEVM.

• Direct support for existing EVM opcodes, fully compatible with the Solidity opcode set. The solution is used by Fox, Scroll, and the Ethereum foundation.
• Keep Solidity compatible by designing a new virtual machine that is zero proof of knowledge friendly and adaptable to EVM development tools. This scheme is mainly used for zkSync.

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.