TL;DR

first level title

1. We are working hard to build the first ZKVM based on PE-VM. Through the ZK-friendly design and the improvement of the ZK algorithm, it has a higher throughput rate; its technical characteristics are as follows:

a. Prove fast:

i. ZK-friendly: obtain a smaller circuit scale and a simplified underlying constraint unit;

ii. Faster ZK implementation: further optimized improvements to plonky 2;

b. Fast execution:

Adopt parallel execution VM (in the context of Parallel prove technology, the shorter the proof generation time, the more obvious the effect).

2. What we have done:

a. In July 2022, the white paper of OlaVM was released;

c. For the ZK algorithm with the fastest execution efficiency at present, we have completed the circuit design and algorithm research of plonky 2, you can open the link: https://github.com/Sin 7 Y/plonky 2/tree/main/plonky 2/ designs to learn more about the design of plonky 2, we will optimize and improve it in the next step, please continue to pay attention. . .

first level title

what are we doing

OlaVM is the first layer-2 ZKVM that introduces parallel execution VMs. It integrates the technical points of the two schemes to obtain faster execution speed and faster proof speed, so as to achieve higher system throughput in the future.

In the current Ethereum system, there are two main reasons for the slow throughput:

1. Consensus process: each node repeatedly executes the transaction to verify the validity of the transaction;

2. Transaction execution: Transaction execution is single-threaded.In order to solve the first point of the problem and need to be programmable at the same time, many projects have carried out research on ZK(E)VM, that is, the transaction is completed off the chain, and only the state is verified on the chain (of course there are other expansion solutions, which will not be discussed here. Too many details), but to really improve system throughput, you needGenerate proofs as fast as possible

Although at this stage, for ZK(E)VM, the bottleneck that affects the throughput of the entire system lies in the generation of proofs; but when Parallel prove is used to speed up the throughput of the entire system, the faster the blocks are generated, the corresponding proofs are generated The earlier the start time (with the evolution of the ZK algorithm and the improvement of acceleration methods, the shorter the proof generation time, the more obvious the improvement effect of this module).

How to achieve high throughput?

secondary title

Proof generation as fast as possible (currently highest priority)

In order to accelerate the generation of proofs, it can be roughly divided into two parts: the smallest possible circuit size and the fastest possible algorithm execution; the fastest possible algorithm execution can be divided into: the improvement of the parameters of the algorithm itself (such as choosing a small domains) and improvements in the external execution environment (such as hardware acceleration).

1. Constraint size as small as possible

a. Prophet

Yes, the consumption of proof generation is strongly related to the overall scale n of constraints. If the overall scale of constraints can be greatly reduced, the time for proof generation will be significantly reduced. This requires that in the design of the VM, you need to use as much design as possible to reduce the overall constraint size.

b. Zk-friendly

Prophet means "prophet", first "predict" and then "verify", its main purpose is: for some complex calculations, we don't need to use VM instructions to implement these complex calculations (may consume a lot of instructions , so as to increase the execution trajectory of the VM and the final constraint scale); instead, the built-in Prophet is used to complete the calculation, and the result is sent to the VM, and then the VM only performs a legality check on the result. Prophet is some built-in functions with specific calculation functions, such as division calculation, square root calculation, cube root calculation, etc. We will gradually enrich the Prophets library according to actual scenarios, so that for most complex calculation scenarios, the overall constraint reduction effect is maximized .

When the calculation is complex, Prophet can help reduce the size of the trajectory executed by the VM; but before that, we prefer that the calculation itself be Zk-friendly. Therefore, in the design, we will use some Zk-friendly operations, such as common hash algorithms, signature verification algorithms, etc.; these optimizations also often exist in other ZK(E)VM solutions; but the final key is, When you choose a Zk-friendly complex calculation, how to constrain this complex calculation with smaller constraints?

In addition to executing computing logic, the VM itself also has other operations that need to be proven, such as RAM operations. A stack-based VM needs to perform POP and PUSH operations every time it is accessed; at the verification level, it is still necessary to verify the validity of this operation. These operations will form an independent Table, and then use constraints to verify these The effectiveness of the stack operation; while the register-based VM performs the same logic, the resulting execution trace is smaller, so the constraint scale is also smaller.

Due to the amazing performance of Plonky 2, we temporarily use Plonky 2 as the ZK backend of OlaVM. We have deeply analyzed Plonky 2's Gate design, Gadget design and protocol principles, and found some optimization directions. You can follow our Github Repo: Plonky 2 designs to learn more about it.

secondary title

Faster transaction execution (not a bottleneck at this stage)

When the proof generation takes a long time, such as several hours, the improvement brought by parallel execution is not obvious; there are two scenarios that can improve the effect brought by this parallelism, one is that the number of aggregated blocks becomes larger to achieve quantitative change Cause qualitative change; the other is that the proof time is greatly shortened. Of course, if the two promotion effects are superimposed, it will be better.

first level title

compatibility?

Of course, the main goal of OlaVM is still to build a high-throughput ZKVM. When our first step is done well, we will consider achieving compatibility, especially Ethereum compatibility, which will also be in our roadmap middle.

All Together

Integrating all the above modules, the data flow chart of the whole system is roughly shown in the figure below:

Coming Soon

first level title

1. Early December 2022:

a. Complete the OlaVM DSL design;

b. Complete the design and development of the OlaVM precompiled contract;

refer to

refer to

1.OlaVM:https://olavm.org/whitepaper/OlaVM-07-25.pdf

2.Plonkish:https://zcash.github.io/halo 2/concepts/arithmetization.html

3.Cairo VM:https://starknet.io/docs/how_cairo_works/cairo_intro.html#field-elements

4.Plonky 2:https://github.com/Sin 7 Y/plonky 2/blob/main/field/src/goldilocks_field.rs

5.Ingonyama:https://github.com/ingonyama-zk/cloud-ZK

6.Semisand:https://semisand.com/

7.Plonky 2 designs:https://github.com/Sin 7 Y/plonky 2/tree/main/plonky 2/designs

about Us

about Us

Sin7y was established in 2021 and is composed of top blockchain developers. We are both a project incubator and a blockchain technology research team, exploring the most important and cutting-edge technologies such as EVM, Layer 2, cross-chain, privacy computing, and autonomous payment solutions.

GitHub | Twitter | Telegram | Medium| Mirror | HackMD | HackerNoon