Subscribe to ZKPool
<100 subscribers
Firstly, welcome to the zkML demo, which operates on ZKPool and is built on RISC Zero's zkVM solution.
Increasingly, projects such as RISC Zero are building zkVM, while others like Taiko and Optimism are utilizing zkVM to develop applications for Ethereum Layer 2.
The zkVM solution is gaining more recognition. Previously, there were concerns about its performance. However, teams have continually optimized it from both the ZKP protocol and hardware perspectives. It's getting faster and faster.
In particular, zkVM's continuation technology provides significant advantages, enabling parallel proving and compatibility with consumer-level devices.
Additionally, continuation technology aids in the use of proof recursion, which can help preserve privacy.
In the context of our zkVM, continuations are a mechanism for splitting a large program into several smaller segments that can be computed and proven independently.
Consider RISC Zero's zkVM as an example. A Rust program can be compiled into a RISC-V image. This image can be executed in the zkVM environment, generating a large execution session.
This session can be split into smaller segments, each of which can be proved in parallel.
If we delve deeper, we can see that the whole session may contain numerous cycles. We can define the limit of cycles for each segment. This approach allows us to handle large tasks by breaking them into smaller ones. These smaller tasks can run on lower-end devices, such as consumer-level GPUs.
Note that to obtain the final proof of the entire session, we need to join the proof of each segment through proof recursion.
For instance, if a program is divided into four segments, we must prove each of these four segments and then perform proof recursion three times.
In the Zero-Knowledge Proof (ZKP) proving system, without continuation technology, the circuit could be quite large, necessitating the manual division of big circuits into smaller ones.
For zkVM, since we can divide large proving tasks into smaller ones, we can execute these tasks in parallel. This could potentially reduce the latency of proving, even when taking the cost of proof recursion into account.
In fact, a parallel computing system has several requirements:
The parallel tasks are relatively independent with minimal interaction between them.
There is a low amount of data transfer between the scheduler and parallel tasks.
The total latency can be reduced.
The overall computational load doesn't increase linearly with the number of parallel tasks.
Fortunately, the zkVM's continuation technology meets the above requirements.
In addition, the zkVM's continuation has these other advantages:
This can reduce the memory requirements for parallel tasks, enabling more individuals with consumer-level devices to participate, thereby promoting decentralization among provers.
It supports pausing and resuming a zkVM.
It can preserve privacy through proof recursion.
zkVM can simplify the proving of all Rust programs without the need to write circuits. Its continuation technology can also reduce latency through parallel proving.
This is why teams developing zkEVM, including Taiko and Scroll, are also exploring zkVM solutions.
While zkML requires a large amount of computation with zkVM, continuation technology ensures that any large models such as LLM can use zkVM for proving. This is particularly useful as proving performance continues to improve.
Finally, its application in a privacy preservation scenario will be highly anticipated.
One challenge for zkVM is identifying the optimal solution for parallel proving, particularly determining the number of segments.
If we split the tasks into segments (assuming n=2^i). Then we will need n segment proving tasks and (n-1) recursion proving tasks.
Thus, the total proving computation loading is:
In which:
L: Total computation loading
Lseg: The computation of one segment
Lrec: The computation loading of proof recursion
Thus, compared to not splitting, the overall computational load will increase.
On the other hand, if more than n devices can participate in parallel proving, which will complete both the segment's proof and recursive proof, then the latency will be:
In which:
T: Total computation latency
Tseg: The computation latency of one segment
Trec: The computation latency of proof recursion
As evident, when i is large, the proving latency might be significantly reduced. However, it's important to balance this with the increased total computational load due to more segments.
We believe that zkVM will become increasingly advantageous as performance improves, given its significant benefits for general-purpose usage.
Reference:
Firstly, welcome to the zkML demo, which operates on ZKPool and is built on RISC Zero's zkVM solution.
Increasingly, projects such as RISC Zero are building zkVM, while others like Taiko and Optimism are utilizing zkVM to develop applications for Ethereum Layer 2.
The zkVM solution is gaining more recognition. Previously, there were concerns about its performance. However, teams have continually optimized it from both the ZKP protocol and hardware perspectives. It's getting faster and faster.
In particular, zkVM's continuation technology provides significant advantages, enabling parallel proving and compatibility with consumer-level devices.
Additionally, continuation technology aids in the use of proof recursion, which can help preserve privacy.
In the context of our zkVM, continuations are a mechanism for splitting a large program into several smaller segments that can be computed and proven independently.
Consider RISC Zero's zkVM as an example. A Rust program can be compiled into a RISC-V image. This image can be executed in the zkVM environment, generating a large execution session.
This session can be split into smaller segments, each of which can be proved in parallel.
If we delve deeper, we can see that the whole session may contain numerous cycles. We can define the limit of cycles for each segment. This approach allows us to handle large tasks by breaking them into smaller ones. These smaller tasks can run on lower-end devices, such as consumer-level GPUs.
Note that to obtain the final proof of the entire session, we need to join the proof of each segment through proof recursion.
For instance, if a program is divided into four segments, we must prove each of these four segments and then perform proof recursion three times.
In the Zero-Knowledge Proof (ZKP) proving system, without continuation technology, the circuit could be quite large, necessitating the manual division of big circuits into smaller ones.
For zkVM, since we can divide large proving tasks into smaller ones, we can execute these tasks in parallel. This could potentially reduce the latency of proving, even when taking the cost of proof recursion into account.
In fact, a parallel computing system has several requirements:
The parallel tasks are relatively independent with minimal interaction between them.
There is a low amount of data transfer between the scheduler and parallel tasks.
The total latency can be reduced.
The overall computational load doesn't increase linearly with the number of parallel tasks.
Fortunately, the zkVM's continuation technology meets the above requirements.
In addition, the zkVM's continuation has these other advantages:
This can reduce the memory requirements for parallel tasks, enabling more individuals with consumer-level devices to participate, thereby promoting decentralization among provers.
It supports pausing and resuming a zkVM.
It can preserve privacy through proof recursion.
zkVM can simplify the proving of all Rust programs without the need to write circuits. Its continuation technology can also reduce latency through parallel proving.
This is why teams developing zkEVM, including Taiko and Scroll, are also exploring zkVM solutions.
While zkML requires a large amount of computation with zkVM, continuation technology ensures that any large models such as LLM can use zkVM for proving. This is particularly useful as proving performance continues to improve.
Finally, its application in a privacy preservation scenario will be highly anticipated.
One challenge for zkVM is identifying the optimal solution for parallel proving, particularly determining the number of segments.
If we split the tasks into segments (assuming n=2^i). Then we will need n segment proving tasks and (n-1) recursion proving tasks.
Thus, the total proving computation loading is:
In which:
L: Total computation loading
Lseg: The computation of one segment
Lrec: The computation loading of proof recursion
Thus, compared to not splitting, the overall computational load will increase.
On the other hand, if more than n devices can participate in parallel proving, which will complete both the segment's proof and recursive proof, then the latency will be:
In which:
T: Total computation latency
Tseg: The computation latency of one segment
Trec: The computation latency of proof recursion
As evident, when i is large, the proving latency might be significantly reduced. However, it's important to balance this with the increased total computational load due to more segments.
We believe that zkVM will become increasingly advantageous as performance improves, given its significant benefits for general-purpose usage.
Reference:
Share Dialog
Share Dialog
No comments yet