github/chiquito
1
1
Fork 0
mirror of https://github.com/privacy-scaling-explorations/chiquito.git synced 2026-01-08 21:48:03 -05:00
Code Issues Packages Projects Releases Wiki Activity

Fix typos (#210)

Browse Source
This commit is contained in:
Dimitris Apostolou
2024-02-26 10:13:44 +02:00
committed by GitHub
parent 5943fbde3b
commit 8817d866d2
8 changed files with 22 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
book/part1_chapter1.md
View File

@@ -51,7 +51,7 @@ Negative values are obtained by the formula `a + (-a) mod p = 0`.
The prime `p` is usually a very big number when used in ZKP, but we can see an easy example with `p = 7`.
The posible values would be `0, 1, 2, 3, 4, 5` and `6`. If we go over `p` it overflows around to `0`. So for example `6 + 1 = 0` or `5 + 3 = 1`.
The possible values would be `0, 1, 2, 3, 4, 5` and `6`. If we go over `p` it overflows around to `0`. So for example `6 + 1 = 0` or `5 + 3 = 1`.
Then for example `-3 + 3 mod 7 = 0 ` which is satisfied by `4 + 3 mod 7 = 0 => -3 = 4`.

2
book/part1_chapter3.md
View File

@@ -80,7 +80,7 @@ Step types are part of the setup, which means that they cannot change between pr
Signals represent elements of the witness that have an independent value for each trace step, but in chiquito paradigm you can see them as variables on the trace steps.
Rotation refer to the capability of creating rules that involved the value of signals in other trace steps with an offset relative to the trace step, not just the value of a signal. A rotation of 0, represent the value of the signal in the same trace step, a rotation of 1 in the next step, a rotation of -1 in the previous step, in general any rotation number is posible.
Rotation refer to the capability of creating rules that involved the value of signals in other trace steps with an offset relative to the trace step, not just the value of a signal. A rotation of 0, represent the value of the signal in the same trace step, a rotation of 1 in the next step, a rotation of -1 in the previous step, in general any rotation number is possible.
## Types of signals

4
book/part2_chapter4.ipynb
View File

@@ -13,7 +13,7 @@
"id": "d7a26b56-e0c7-4e35-a064-5899aa2ef6b7",
"metadata": {},
"source": [
"To avoid the soundness error from `evil_witness` in Chapter 3, we need to constrain that forward signals \"a\" and \"b\" are both 1 in the first step instance. Because this isn't true for all step instances, we need to create a new step type, called `FiboFirstStep`, which is idential to `FiboStep` except two additional constraints for \"a\" and \"b\":\n",
"To avoid the soundness error from `evil_witness` in Chapter 3, we need to constrain that forward signals \"a\" and \"b\" are both 1 in the first step instance. Because this isn't true for all step instances, we need to create a new step type, called `FiboFirstStep`, which is identical to `FiboStep` except two additional constraints for \"a\" and \"b\":\n",
"\n",
"| Step Type | Step Instance Index || Signals |||| Setups |||\n",
"| :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: |\n",
@@ -293,7 +293,7 @@
"\n",
"Besides, we learned that with multiple step types, Chiquito can create step instances with different signals and constraints, thereby allowing great versatility in circuit design.\n",
"\n",
"Finally, this example shows again that circuit setup and witness generation are separate processes. There can be multiple witnesses for the same circuit setup. As a great analogy, a circuit can be considered a piece of \"hardware\" whereas its witnesses \"softwares\" that are compatible with the hardware."
"Finally, this example shows again that circuit setup and witness generation are separate processes. There can be multiple witnesses for the same circuit setup. As a great analogy, a circuit can be considered a piece of \"hardware\" whereas its witnesses \"software\" that are compatible with the hardware."
]
}
],

2
book/part2_chapter5.ipynb
View File

@@ -6,7 +6,7 @@
"metadata": {},
"source": [
"# Chapter 5: Padding and Exposing Signals\n",
"In prior examples, all Fibonacci circuit witnesses have the same number of step instances. According to our analogy where a circuit is considered a piece of hardware and its witnesses compatible softwares, it's natural to think that we'd allow for more flexibility for our witnesses. Most immediately, and we shouldn't limit all Fibonacci circuit witnesses to have the same number of step instances.\n",
"In prior examples, all Fibonacci circuit witnesses have the same number of step instances. According to our analogy where a circuit is considered a piece of hardware and its witnesses compatible software, it's natural to think that we'd allow for more flexibility for our witnesses. Most immediately, and we shouldn't limit all Fibonacci circuit witnesses to have the same number of step instances.\n",
"\n",
"However, you might wonder, doesn't `self.pragma_num_steps(4)` limit the number of step instances to 4? Besides, doesn't this function guarantee the Fibonacci circuit's security, such that we have a fixed circuit setup with a specific number of step instances, thereby making the circuit a piece of \"hardware\" that cannot be tampered with? How can we allow for BOTH a fixed circuit setup AND flexible witnesses? This problem is frequently encountered in projects like PSE's zkEVM, where witnesses with very different sizes are passed into the same circuit.\n",
"\n",

22
src/frontend/python/mod.rs
View File

@@ -1825,7 +1825,7 @@ mod tests {
#[pyfunction]
fn convert_and_print_ast(json: &PyString) {
let circuit: SBPIR<Fr, ()> =
serde_json::from_str(json.to_str().expect("PyString convertion failed."))
serde_json::from_str(json.to_str().expect("PyString conversion failed."))
.expect("Json deserialization to Circuit failed.");
println!("{:?}", circuit);
}
@@ -1833,21 +1833,21 @@ fn convert_and_print_ast(json: &PyString) {
#[pyfunction]
fn convert_and_print_trace_witness(json: &PyString) {
let trace_witness: TraceWitness<Fr> =
serde_json::from_str(json.to_str().expect("PyString convertion failed."))
serde_json::from_str(json.to_str().expect("PyString conversion failed."))
.expect("Json deserialization to TraceWitness failed.");
println!("{:?}", trace_witness);
}
#[pyfunction]
fn ast_to_halo2(json: &PyString) -> u128 {
let uuid = chiquito_ast_to_halo2(json.to_str().expect("PyString convertion failed."));
let uuid = chiquito_ast_to_halo2(json.to_str().expect("PyString conversion failed."));
uuid
}
#[pyfunction]
fn ast_map_store(json: &PyString) -> u128 {
let uuid = chiquito_ast_map_store(json.to_str().expect("PyString convertion failed."));
let uuid = chiquito_ast_map_store(json.to_str().expect("PyString conversion failed."));
uuid
}
@@ -1855,9 +1855,9 @@ fn ast_map_store(json: &PyString) -> u128 {
#[pyfunction]
fn halo2_mock_prover(witness_json: &PyString, rust_id: &PyLong, k: &PyLong) {
chiquito_halo2_mock_prover(
witness_json.to_str().expect("PyString convertion failed."),
rust_id.extract().expect("PyLong convertion failed."),
k.extract().expect("PyLong convertion failed."),
witness_json.to_str().expect("PyString conversion failed."),
rust_id.extract().expect("PyLong conversion failed."),
k.extract().expect("PyLong conversion failed."),
);
}
@@ -1870,7 +1870,7 @@ fn super_circuit_halo2_mock_prover(rust_ids: &PyList, super_witness: &PyDict, k:
.downcast::<PyLong>()
.expect("PyAny downcast failed.")
.extract()
.expect("PyLong convertion failed.")
.expect("PyLong conversion failed.")
})
.collect::<Vec<UUID>>();
@@ -1881,12 +1881,12 @@ fn super_circuit_halo2_mock_prover(rust_ids: &PyList, super_witness: &PyDict, k:
key.downcast::<PyLong>()
.expect("PyAny downcast failed.")
.extract()
.expect("PyLong convertion failed."),
.expect("PyLong conversion failed."),
value
.downcast::<PyString>()
.expect("PyAny downcast failed.")
.to_str()
.expect("PyString convertion failed."),
.expect("PyString conversion failed."),
)
})
.collect::<HashMap<u128, &str>>();
@@ -1894,7 +1894,7 @@ fn super_circuit_halo2_mock_prover(rust_ids: &PyList, super_witness: &PyDict, k:
chiquito_super_circuit_halo2_mock_prover(
uuids,
super_witness,
k.extract().expect("PyLong convertion failed."),
k.extract().expect("PyLong conversion failed."),
)
}

4
src/plonkish/backend/halo2.rs
View File

@@ -317,7 +317,7 @@ impl<F: Field + From<u64> + Hash> ChiquitoHalo2<F> {
.advice_columns
.get(&column.uuid())
.unwrap_or_else(|| panic!("column not found {}", column.annotation)),
_ => panic!("worng column type"),
_ => panic!("wrong column type"),
}
}
@@ -327,7 +327,7 @@ impl<F: Field + From<u64> + Hash> ChiquitoHalo2<F> {
.fixed_columns
.get(&column.uuid())
.unwrap_or_else(|| panic!("column not found {}", column.annotation)),
_ => panic!("worng column type"),
_ => panic!("wrong column type"),
}
}
}

2
src/poly/mod.rs
View File

@@ -243,7 +243,7 @@ pub trait SignalFactory<V> {
pub struct ConstrDecomp<F, V> {
/// PI constraint for the new signals introduced.
constrs: Vec<Expr<F, V>>,
/// Expressions for how to create the witness for the generated signals the orginal expression
/// Expressions for how to create the witness for the generated signals the original expression
/// has be decomposed into.
auto_signals: HashMap<V, Expr<F, V>>,
}

6
src/poly/reduce.rs
View File

@@ -21,7 +21,7 @@ pub fn reduce_degree<F: Field, V: Clone + Eq + PartialEq + Hash + Debug, SF: Sig
/// Actual recursive implementation of `reduce_degre`. Key here to understand the difference
/// between: + total_max_degree: maximum degree of the PI the input expression is decomposed of.
/// + partial_max_degree: maximum degree of the root PI, that can substitute the orginal
/// + partial_max_degree: maximum degree of the root PI, that can substitute the original
/// expression.
///
/// The value of `partial_max_degree` can be less than `total_max_degree` when this
@@ -99,7 +99,7 @@ fn reduce_degree_mul<F: Field, V: Clone + Eq + PartialEq + Hash + Debug, SF: Sig
partial_max_degree: usize,
signal_factory: &mut SF,
) -> Expr<F, V> {
// base case, if partial_max_degree == 1, the root expresion can only be a variable
// base case, if partial_max_degree == 1, the root expression can only be a variable
if partial_max_degree == 1 {
let reduction = reduce_degree_mul(
decomp,
@@ -141,7 +141,7 @@ fn reduce_degree_mul<F: Field, V: Clone + Eq + PartialEq + Hash + Debug, SF: Sig
// for_root will be multipliers that will be included in the root expression
let mut for_root = Vec::default();
// to_simplify will be multipliers that will be recursively decomposed and subsituted by a
// to_simplify will be multipliers that will be recursively decomposed and substituted by a
// virtual signal in the root expression
let mut to_simplify = Vec::default();