-
Notifications
You must be signed in to change notification settings - Fork 5
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #50 from NilFoundation/zkllvm-diagram-reordering
added a new page in Overview with usage flows
- Loading branch information
Showing
4 changed files
with
121 additions
and
106 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,111 @@ | ||
| # Usage flow | ||
|
|
||
| ## Diagram | ||
|
|
||
| The following diagram shows the flow for converting a `.cpp` or a `.rs` file into a proof binary and Solidity code for deployment. | ||
|
|
||
| ```mermaid | ||
| %%{ | ||
| init: { | ||
| 'theme': 'base', | ||
| 'themeVariables': { | ||
| 'primaryColor': '#0f0f0f', | ||
| 'primaryTextColor': '#f1f1f1', | ||
| 'primaryBorderColor': '#f1f1f1', | ||
| 'lineColor': '#87B6FC', | ||
| 'secondaryColor': '#f1f1f1', | ||
| 'tertiaryColor': '#2f2f2f', | ||
| }, | ||
| 'flowchart': | ||
| { | ||
| 'defaultRenderer': 'elk', | ||
| 'curve': 'step' | ||
| } | ||
| } | ||
| }%% | ||
| flowchart TB | ||
| classDef transpilerTitle margin-right: 250px; | ||
| Transpiler:::transpilerTitle | ||
| CPP(C++ code) | ||
| RUST(Rust code) | ||
| CLANG(<code>clang</code>) | ||
| RUSTCOMP(<code>cargo</code> #40;<code>rustc</code>#41;) | ||
| IR(Circuit IR) | ||
| INPUTS(Circuit inputs) | ||
| ASSIGNER(Assigner) | ||
| ASSIGNERRESULT(<code>.tbl</code> and <code>.crct</code> files) | ||
| TRANSPILER(<code>transpiler</code>) | ||
| PROOFBIN(Proof binary) | ||
| SOLIDITY(Solidity contracts) | ||
| CPP --> CLANG | ||
| RUST --> RUSTCOMP | ||
| CLANG --> IR | ||
| RUSTCOMP --> IR | ||
| IR --> ASSIGNER | ||
| INPUTS --> ASSIGNER | ||
| ASSIGNER --> ASSIGNERRESULT | ||
| ASSIGNERRESULT --> TRANSPILER | ||
| TRANSPILER --> PROOFBIN | ||
| TRANSPILER --> SOLIDITY | ||
| subgraph Code | ||
| CPP | ||
| RUST | ||
| end | ||
| subgraph Compilation | ||
| direction LR | ||
| CLANG | ||
| RUSTCOMP | ||
| IR | ||
| end | ||
| subgraph Assigner | ||
| direction LR | ||
| INPUTS | ||
| ASSIGNER | ||
| ASSIGNERRESULT | ||
| end | ||
| subgraph Transpiler | ||
| direction LR | ||
| TRANSPILER | ||
| PROOFBIN | ||
| SOLIDITY | ||
| end | ||
| ``` | ||
|
|
||
| ## Key stages | ||
|
|
||
| Here is a breakdown of the key stages a circuit must pass before being proven. | ||
|
|
||
| ### Write code in C++ or Rust | ||
|
|
||
| There is no need to use any special syntax when working with zkLLVM. A circuit is defined by simply adding a `[[circuit]]` (C++) or a `#[circuit]` (Rust) directive before a function. With some modifications, almost any existing C++ or Rust code can be reused for zkLLVM. | ||
|
|
||
| :::tip[Examples] | ||
|
|
||
| The [**zkLLVM repository**](https://github.com/NilFoundation/zkllvm) contains several ready-made examples of circuits. They can be reused wholly or repurposed depending on the use case. | ||
|
|
||
| ::: | ||
|
|
||
| :::info[Limitations] | ||
|
|
||
| Read the materials in the **Best practices and limitations** section to learn more about the changes that would need to be made to existing C++ or Rust code for reuse in zkLLVM. | ||
|
|
||
| ::: | ||
|
|
||
| ### Compile the code into a circuit | ||
|
|
||
| Compiling takes only a few seconds and the entire process is done via a CLI tool which is a replacement for `clang` and `rustc`. This tool can be easily integrated to a CI/CD pipeline or any development environment. | ||
|
|
||
| It is also possible to use dedicated build management systems (Cargo and CMake) if a circuit requires the use of external dependencies. | ||
|
|
||
| ### Pass the circuit to the `assigner` tool | ||
|
|
||
| The `assigner` tool is used to prepare all inputs and witnesses for the circuit. It generates the circuit constraints and the assignment table. | ||
|
|
||
| After this stage is complete, the circuit should be ready for use with dynamic inputs. | ||
|
|
||
| ### Generate proof for the circuit | ||
|
|
||
| At this point, the circuit and its inputs can be passed to [**the `transpiler` tool**](../getting-started/compiling-a-circuit#using-transpiler-to-generate-the-circuit-proof) to generate a proof and Solidity contract files. | ||
|
|
||
| Alternatively, the circuit proof can be generated by [**using the `proof-generator` tool**](../getting-started/verifying-a-circuit#generate-a-proof-using-proof-producer). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters