Unveiling OlaVM Proof of Concept: The Next-Generation Full-Featured zkVM
TL.DR
In August 2022, Sin7y released the White Paper of OlaVM, formally planting the seeds of scalability and privacy in the fertile soil of Ethereum. With the completion of OlaVM PoC, the seeds have broken through the ground, indicating that the seeds have successfully germinated. This article will mainly introduce the progress and some strategic adjustments of OlaVM at this stage.
We are excited to make the following announcements:
- We have preliminarily completed the PoC of OlaVM, and you can check the relevant engineering implementation and related document design through Sin7Y/olavm.
- We have initially completed the design and implementation of the custom smart contract language Ola-lang, and you can check the related engineering design and related document design through Sin7Y/ola-lang.
- We have initially completed the integration of Olang into the developer-friendly IDE: Visual Studio Code, allowing developers to write Olang programs on VSCode and then execute proof generation and proof verification processes. You can view the operation tutorial through Sin7Y/vscode-ola.
And some adjustments:
- The project name was officially adjusted from OlaVM to Ola. OlaVM will be a key module in Ola, and other modules include smart contract language Ola-lang, Ola-compiler, Ola-sequencer, etc.
- The project goal is expanded from programmable scalability to programmable scalability and privacy. We believe that programmable scalability and privacy will be the next important features of Ethereum and even the blockchain industry.
OlaVM
OlaVM is one of the most significant modules in the Ola system. Whether in a public or private scene, the main function of OlaVM is to execute programs and generate execution traces and valid proofs. Therefore, in order to have a high throughput rate for the entire Ola system, the efficiency of the OlaVM module is very crucial, which requires fast program execution, fast execution trace generation, and most importantly, fast proof generation.
In order to generate proofs quickly, OlaVM must be designed as zk-friendly as possible and involve 1) Instruction Set Architecture (ISA) design, 2) finite field selection, 3) builtins, referring to predefined calculations that could not be proven efficiently by splitting into CPU instructions, 4) and prophets, referring to nondeterministic calculations that are inefficient to prove but can be verified efficiently.
- ISA design
- Firstly, the size of the instruction set is directly related to the complexity of the constraint system. The main manifestation is that the increase in the number of instructions will lead to an increase in the number of selector polynomials and instruction constraints. It may even increase the polynomial order of the entire constraint system and increase the workload to prove it.
- Secondly, the frequency of instruction is used. If it is based on the CISC design, more instructions may lead to partial failure in most computing scenarios Instructions are idle or used in a small amount, but the constraints related to these instructions still exist in the entire constraint system, increasing the workload of proof without reason, which returns to the problem mentioned in the first point.
2. Finite field selection
Similar to Cairo’s design, OlaVM also adopts the Algebraic RISC architecture. The meaning of RISC is similar to that described above, and Algebraic represents that the operations performed by OlaVM are all field operations, which is one of the reasons why OlaVM can implement RISC. The operations of OlaVM are all field operations, meaning that the word and instruction operands in OlaVM are also field elements. Different from the field used in Cairo (P = 2²⁵¹ + 17 * 2¹⁹² + 1), the field used by OlaVM is the Goldilock field (P = 2⁶⁴ — 2³² + 1). Therefore, the computation in the Goldilock field can be executed faster because of the huge difference in field size.
3. Builtins
For some special simple calculations, when you want to constrain it, you would find that the constraints are very heavy, such as bitwise operations, and keccak calculations that contain a large number of bitwise operations. As the execution trace table has an upper limit in size, the fewer rows occupied by a single execution, the more executions are included in this table.
Therefore, for the zk-unfriendly calculations involved in the transaction execution logic, it needs to be put into a separate table to verify the correctness. This is the idea behind the builtins design. Since we need to identify which data in the trace is consistent with the corresponding builtins, we need to add an additional selector to enable it. OlaVM currently supports bitwise, range check, and comparison builtins. Other builtin types, such as hash, ecdsa, etc., will be supported in the near future.
4. Prophets
A great advantage of customized zkVM is that zk-friendly can be applied in any component of the system. The above-mentioned design points are related to the design of the OlaVM itself, and the prophets will be integrated into Ola-complier. For example, it is necessary to set a special write-once memory segment in OlaVM and judge whether it is a prophet code segment when allocating compiler memory.
Here is an example of how the prophet plays its role. If the prover wants to prove “I know the square root of the number y is x”, for most virtual machines, since there is no instruction or builtin corresponding to square function, it can only be realized with virtual machine instructions, and then to generate a proof, since the logic of this calculation is complex, it will increase the workload of the prover.
Fortunately, the verification of this calculation is simple, for example, you only need to introduce two logics: x * x = y. rangecheck(x). This is where prophets come into play. It is like a “prophet” that helps you calculate the results of the current calculation. Then, you only need to introduce the verification logic described above into the program. Figure 1 shows the theoretical performance of different processing methods for the processing of nondeterministic calculations.
- The verification logic of prophets is in the program while the verification logic of builtins is a circuit.
- The prophets will only add a few complexities for prover while the increase of prover complexities by builtins will be much larger.
- Finally, the types of calculations solved by the two are also different. Prophets solve nondeterministic calculations, while builtins solve zk-unfriendly calculations.
For more design details, please refer to the Olavm design document and the OlaVM project.
Ola-lang
- Introduction
high-level language for implementing smart contracts. From the outset, it is designed to be a zk-friendly programming language. Ola-lang is influenced by Solidity and Rust. It is very easy for developers familiar with these languages to get started. It is statically typed and supports complex user-defined types among other features. With Ola-lang, you can create contracts for a variety of uses.
2. The Design Goals
- Security: The results of the program executions are deterministic, declared at the language level/syntax, and guaranteed at the compiler level.
- Efficiency: The speed of execution and proof of the program is well balanced to be efficient.
- Universal: Easy to use and readable code, it is developer friendly with minimal learning thresholds for developers familiar with mainstream programming languages such as C++/Rust, to quickly get into writing arithmetic programs.
- Turing complete: Ola-lang can be used for complex programs such as loops, recursion, etc.
3. Key features
- Ola-lang natively supports field operations and plans to support u32, u64, and u256 types based on field elements;
- Ola-lang supports compiling smart contracts to LLVM IR as well as custom IR, which allows the compiler to be separated from the front and back ends for easier optimization;
- Ola-lang supports Prophets, which makes it easy to verify some NP-liked calculations;
- Ola-lang supports Builtins, which makes it easy to deal with zk-unfriendly computation;
- Ola-lang is based on solidity’s syntax and the way contracts are written (Solidity front end may be supported at a later stage.)
4. Architecture Overview
The Ola compiler introduces LLVM-IR as the middle end of the compilation, which makes it possible to separate the front and back ends of the compilation and optimize them as much as possible. The architecture of the Ola compiler is shown in the following diagram.
5. The road to full-featured OlaVM
In addition to the milestone design above, there are more details that need to be refined. See the open issues page for a list of proposed features (and known issues). For more information about the Ola language and how to use the Ola compiler, please check out the repo: Sin7Y/ola-lang, olang.readthedocs.
Join Us
Sin7y Labs is seeking talented and driven individuals to join our team as developers and local ambassadors/community managers. We offer a dynamic and tech-centered work environment, competitive salary and benefits, and opportunities for career growth and development. If you’re interested in being a part of a leading technology company and have a passion for zero-knowledge technology, we’d love to hear from you.
To apply, please write to contact@sin7y.org and submit your resume and a cover letter outlining your qualifications and interest in the role. Join the Sin7y — Ola Discord server if you have any further questions.
About us
Founded in 2021 and powered by top-notch blockchain developers, Sin7y is a project incubator and blockchain technology research team that explores the most important and cutting-edge technologies, including EVM, Layer2, cross-chain, privacy computing, autonomous payment solutions, etc. We are currently building Ola, a one-stop platform bolstering the Ethereum ecosystem with programmable privacy, programmable scalability, and developer compatibility. If you are interested in talking with us, feel free to join our Discord server or email us at contact@sin7y.org.
Stay Tuned
Website | Whitepaper |GitHub | Twitter | Discord | HackMD | HackerNoon
