From 68f8a4a067eb2d48a2a0d916401dd798b77631f6 Mon Sep 17 00:00:00 2001 From: nsingal <31551081+nsingal@users.noreply.github.com> Date: Tue, 27 Feb 2024 22:52:42 -0800 Subject: [PATCH 1/4] Update types.md --- sunscreen_docs/src/linked/linked_programs/types.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sunscreen_docs/src/linked/linked_programs/types.md b/sunscreen_docs/src/linked/linked_programs/types.md index 456372a47..80358edcf 100644 --- a/sunscreen_docs/src/linked/linked_programs/types.md +++ b/sunscreen_docs/src/linked/linked_programs/types.md @@ -28,6 +28,7 @@ link an FHE type to a ZKP program, it is actually this plaintext polynomial that inserted into the ZKP circuit. Of course, if you are linking this value to your ZKP program, you _probably_ don't care about the actual encoding (i.e., the plaintext polynomial coefficients), but rather the _underlying value_ being encoded, whether that's a signed, unsigned, or rational value. This is where the `AsFieldElement` trait comes in: given a `linked_input`, the trait method `linked_input.into_field_elem()` decodes the input into a native field element. +> NS: Can we get rid of the "into_field_elem" ? ### Specifying linked inputs @@ -73,6 +74,7 @@ fn exceeds(#[linked] a: BfvUnsigned64, #[linked] b: BfvUnsigned zkp_var!(u64::MAX).constrain_le_bounded(b.into_field_elem(), 128); } ``` +> NS: Fix the u32::MAX to a u64 so it looks more logical. ## Rational From 92151d955c99c87d65b96fbf9135f0d8cd2fad44 Mon Sep 17 00:00:00 2001 From: nsingal <31551081+nsingal@users.noreply.github.com> Date: Tue, 27 Feb 2024 22:54:47 -0800 Subject: [PATCH 2/4] Update compiling.md --- sunscreen_docs/src/linked/compiling/compiling.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sunscreen_docs/src/linked/compiling/compiling.md b/sunscreen_docs/src/linked/compiling/compiling.md index 149130be0..058197844 100644 --- a/sunscreen_docs/src/linked/compiling/compiling.md +++ b/sunscreen_docs/src/linked/compiling/compiling.md @@ -35,3 +35,5 @@ let app = Compiler::new() # Ok(()) # } ``` + +> NS: Can I specify the fhe params and just a junk fhe program to compile the zkp? From d3489ff51aea3e3eaeffb4a33c3ec450f3a99f94 Mon Sep 17 00:00:00 2001 From: nsingal <31551081+nsingal@users.noreply.github.com> Date: Tue, 27 Feb 2024 22:56:29 -0800 Subject: [PATCH 3/4] Update private_tx.md --- sunscreen_docs/src/linked/applications/private_tx.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sunscreen_docs/src/linked/applications/private_tx.md b/sunscreen_docs/src/linked/applications/private_tx.md index ac048396f..7f15ffa63 100644 --- a/sunscreen_docs/src/linked/applications/private_tx.md +++ b/sunscreen_docs/src/linked/applications/private_tx.md @@ -61,6 +61,8 @@ properties. {{#include private_tx.rs:validate_transfer}} ``` +> NS: It is not clear where the last 2 properties are being handled by SDLP. Can you make it more explicit? + #### Registration As we noted above, we're assuming a deposit to a private account occurs from a From ddf0962a62d8a7b94dce1f08be9ae029ff3ab885 Mon Sep 17 00:00:00 2001 From: nsingal <31551081+nsingal@users.noreply.github.com> Date: Tue, 27 Feb 2024 22:57:44 -0800 Subject: [PATCH 4/4] Update prove.md --- sunscreen_docs/src/linked/runtime/prove.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sunscreen_docs/src/linked/runtime/prove.md b/sunscreen_docs/src/linked/runtime/prove.md index 77bb510c4..4e9265efa 100644 --- a/sunscreen_docs/src/linked/runtime/prove.md +++ b/sunscreen_docs/src/linked/runtime/prove.md @@ -99,6 +99,8 @@ let proof = builder Again, you can also use `encrypt_symmetric_returning_link` to do the same thing for a symmetric encryption. +> NS: Can we change it so the linked_input is provided as an input to 'verify' rather than part ofthe builder? + #### Decrypt returning link Use the `decrypt_returning_link` method if you have an existing ciphertext,