You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 20, 2024. It is now read-only.
Originally, the intent with zero-bin was to implement a very simple CLI tool that could prove blocks with plonky2. So the CLI interface is very much designed with this intent — provide a block number as input, and generate a plonky2 proof as output.
As we move towards making this repository production ready it's a good time expand the capabilities of zero-bin in its ability to understand what I am going to call block intervals.
Block Intervals
Block invervals encapsulate the semantics regarding how zero-bin manages a set of proving jobs relative to some higher order intent, like following a chain tip, for example. I will use interval notation to describe them.
Note for all intervals we assume ∈ ℤ
[x,x]
Prove a single block. This is the same (only) block mode that zero-bin currently supports, generalized to interval notation.
In Rust
x..=x
[x,y]
Prove a range of blocks. For example [1,100] entails proving blocks 1 through 100.
In Rust
x..=y
[x,∞)
Follow chain tip, starting from x. This entails making zero-bin aware of the tip of the target chain such that it contiguously proves blocks towards it.
In Rust
x..
Block Connection
A bit of background: zk_evm's prove_block method accepts an optional parent block proof.
With the introduction of block intervals, we will need an additional boolean flag which specifies whether contiguous blocks must be connected when generating proofs. This flag will determine whether zero-bin maintains a record of parent proof outputs to plug into these prove_block calls.
The implications on the prover module
The API of the prover module is at odds with the ability to facilitate block connection in an efficient manner. In particular, the prove method accepts the parent block proof as an argument with the type Option<PlonkyProofIntern>. In other words, this prove method is currently set up to be atomic, in the sense that it executes all proof steps in a single logical step. This of course makes sense in context of the original intent of zero-bin (proving one block at a time), but to support block intervals, this will need to be updated.
zero-bin will need to be able to kick off multiple proving jobs in parallel -- it should not have to wait for block n to complete its block proof before kicking off a proof for block n + 1. This entails heavier orchestration logic in the leader or some clever usage of Future. For example, rather than accepting an Option<PlonkyProofIntern>, it could accept some Option<impl Future<Output = PlonkyProofIntern>> which resolves when its parent proof has completed. This could likely be facilitated with some BlockProofFuture type that uses channels to asynchronously signal block proof completion. My sense is that this will be a more ergonomic solution than a more top-down imperative orchestration system -- but I leave that decision to the implementor.
Summary
Block Intervals are a key capability for wider applicability and thus adoption of zero-bin. The features and details specified herein should be broken into smaller sub issues before implementing, while this issue can serve as the higher level discussion environment and reference definition for the capability as a whole.
The text was updated successfully, but these errors were encountered:
Context
Originally, the intent with zero-bin was to implement a very simple CLI tool that could prove blocks with plonky2. So the CLI interface is very much designed with this intent — provide a block number as input, and generate a plonky2 proof as output.
As we move towards making this repository production ready it's a good time expand the capabilities of zero-bin in its ability to understand what I am going to call block intervals.
Block Intervals
Block invervals encapsulate the semantics regarding how zero-bin manages a set of proving jobs relative to some higher order intent, like following a chain tip, for example. I will use interval notation to describe them.
[x,x]
Prove a single block. This is the same (only) block mode that zero-bin currently supports, generalized to interval notation.
[x,y]
Prove a range of blocks. For example
[1,100]
entails proving blocks1
through100
.[x,∞)
Follow chain tip, starting from
x
. This entails making zero-bin aware of the tip of the target chain such that it contiguously proves blocks towards it.Block Connection
A bit of background: zk_evm's
prove_block
method accepts an optional parent block proof.With the introduction of block intervals, we will need an additional boolean flag which specifies whether contiguous blocks must be connected when generating proofs. This flag will determine whether zero-bin maintains a record of parent proof outputs to plug into these
prove_block
calls.The implications on the prover module
The API of the prover module is at odds with the ability to facilitate block connection in an efficient manner. In particular, the
prove
method accepts the parent block proof as an argument with the typeOption<PlonkyProofIntern>
. In other words, this prove method is currently set up to be atomic, in the sense that it executes all proof steps in a single logical step. This of course makes sense in context of the original intent of zero-bin (proving one block at a time), but to support block intervals, this will need to be updated.zero-bin will need to be able to kick off multiple proving jobs in parallel -- it should not have to wait for block
n
to complete its block proof before kicking off a proof for blockn + 1
. This entails heavier orchestration logic in the leader or some clever usage ofFuture
. For example, rather than accepting anOption<PlonkyProofIntern>
, it could accept someOption<impl Future<Output = PlonkyProofIntern>>
which resolves when its parent proof has completed. This could likely be facilitated with someBlockProofFuture
type that uses channels to asynchronously signal block proof completion. My sense is that this will be a more ergonomic solution than a more top-down imperative orchestration system -- but I leave that decision to the implementor.Summary
Block Intervals are a key capability for wider applicability and thus adoption of zero-bin. The features and details specified herein should be broken into smaller sub issues before implementing, while this issue can serve as the higher level discussion environment and reference definition for the capability as a whole.
The text was updated successfully, but these errors were encountered: