Skip to content

refactor(PR 12): add SecretFr, WasmSecretFr, FFI_SecretFr to zerokit, standardize type naming in Wasm and FFI#423

Merged
vinhtc27 merged 9 commits into
develop/v3.0.0from
refactor/pr12-todo
Jul 7, 2026
Merged

refactor(PR 12): add SecretFr, WasmSecretFr, FFI_SecretFr to zerokit, standardize type naming in Wasm and FFI#423
vinhtc27 merged 9 commits into
develop/v3.0.0from
refactor/pr12-todo

Conversation

@vinhtc27

@vinhtc27 vinhtc27 commented Jul 5, 2026

Copy link
Copy Markdown
Contributor

Changes:

  • rln: renamed IdSecret to SecretFr and apply the new type to nullifier, trapdoor, and key generation.
  • rln-ffi: added opaque FFI_SecretFr, migrate to SecretFr, standardize FFI type naming, update C/Nim examples.
  • rln-wasm: added WasmSecretFr, migrate to SecretFr, and standardize WASM type naming, update JS example.

@github-actions

github-actions Bot commented Jul 5, 2026

Copy link
Copy Markdown

Benchmark for 725d718

Click to view benchmark
Test Base PR %
FullMerkleProof::compute_root_from 7.6±0.11µs 7.7±0.77µs +1.32%
FullMerkleTree::delete 16.4±0.28µs 16.4±0.30µs 0.00%
FullMerkleTree::get 0.7±0.00ns 0.7±0.01ns 0.00%
FullMerkleTree::get_empty_leaves_indices 1216.8±14.30µs 1220.8±25.99µs +0.33%
FullMerkleTree::get_subtree_root 8.5±0.18ns 8.4±0.07ns -1.18%
FullMerkleTree::override_range 1637.3±44.45µs 1637.6±48.54µs +0.02%
FullMerkleTree::proof 69.0±0.61ns 69.3±1.71ns +0.43%
FullMerkleTree::set 8.1±0.17µs 8.1±0.16µs 0.00%
FullMerkleTree::set_range 1611.1±22.72µs 1600.8±42.64µs -0.64%
FullMerkleTree::update_next 8.1±0.17µs 8.1±0.24µs 0.00%
FullMerkleTree::verify 7.6±0.10µs 7.6±0.08µs 0.00%
OptimalMerkleProof::compute_root_from 7.6±0.20µs 7.6±0.11µs 0.00%
OptimalMerkleTree::delete 18.8±0.24µs 18.7±0.31µs -0.53%
OptimalMerkleTree::get 28.7±0.81ns 27.9±0.52ns -2.79%
OptimalMerkleTree::get_empty_leaves_indices 860.7±6.42µs 860.6±6.79µs -0.01%
OptimalMerkleTree::get_subtree_root 19.8±0.15ns 19.2±0.21ns -3.03%
OptimalMerkleTree::override_range 3.6±0.13ms 3.6±0.10ms 0.00%
OptimalMerkleTree::proof 437.5±6.94ns 440.8±6.25ns +0.75%
OptimalMerkleTree::set 9.5±0.13µs 9.6±0.21µs +1.05%
OptimalMerkleTree::set_range 3.6±0.13ms 3.6±0.13ms 0.00%
OptimalMerkleTree::update_next 9.7±0.47µs 9.7±0.46µs 0.00%
OptimalMerkleTree::verify 7.6±0.10µs 7.6±0.17µs 0.00%
Poseidon::hash/10 117.1±0.26µs 83.4 KElem/sec N/A N/A
Poseidon::hash/100 1214.9±13.69µs 80.4 KElem/sec N/A N/A
Poseidon::hash/1000 13.0±0.19ms 75.2 KElem/sec N/A N/A
Poseidon::hash/single 11.7±0.01µs 81.4 MElem/sec N/A N/A

@github-actions

github-actions Bot commented Jul 5, 2026

Copy link
Copy Markdown

Benchmark for 7871c1c

Click to view benchmark
Test Base PR %
FullMerkleProof::compute_root_from 9.5±0.11µs 9.5±0.23µs 0.00%
FullMerkleTree::delete 20.6±0.51µs 20.5±0.27µs -0.49%
FullMerkleTree::get 0.9±0.00ns 0.9±0.01ns 0.00%
FullMerkleTree::get_empty_leaves_indices 1567.0±7.47µs 1569.8±22.59µs +0.18%
FullMerkleTree::get_subtree_root 10.9±0.10ns 10.9±0.09ns 0.00%
FullMerkleTree::override_range 2.1±0.02ms 2.1±0.04ms 0.00%
FullMerkleTree::proof 89.2±0.60ns 90.7±4.09ns +1.68%
FullMerkleTree::set 10.2±0.17µs 10.1±0.08µs -0.98%
FullMerkleTree::set_range 2.0±0.01ms 2.1±0.03ms +5.00%
FullMerkleTree::update_next 10.2±0.17µs 10.1±0.10µs -0.98%
FullMerkleTree::verify 9.5±0.11µs 9.5±0.13µs 0.00%
OptimalMerkleProof::compute_root_from 9.5±0.07µs 9.5±0.09µs 0.00%
OptimalMerkleTree::delete 23.9±0.47µs 23.6±0.30µs -1.26%
OptimalMerkleTree::get 41.8±10.48ns 36.4±0.72ns -12.92%
OptimalMerkleTree::get_empty_leaves_indices 1112.7±20.86µs 1112.9±26.79µs +0.02%
OptimalMerkleTree::get_subtree_root 30.7±5.82ns 24.8±0.48ns -19.22%
OptimalMerkleTree::override_range 4.1±0.13ms 4.8±0.13ms +17.07%
OptimalMerkleTree::proof 624.2±87.60ns 575.5±17.07ns -7.80%
OptimalMerkleTree::set 12.0±0.27µs 12.0±0.39µs 0.00%
OptimalMerkleTree::set_range 4.1±0.11ms 4.9±0.50ms +19.51%
OptimalMerkleTree::update_next 12.2±0.53µs 12.1±0.46µs -0.82%
OptimalMerkleTree::verify 9.6±0.23µs 9.6±0.08µs 0.00%
Poseidon::hash/10 151.6±0.13µs 64.4 KElem/sec N/A N/A
Poseidon::hash/100 1576.7±5.60µs 61.9 KElem/sec N/A N/A
Poseidon::hash/1000 16.9±0.46ms 57.9 KElem/sec N/A N/A
Poseidon::hash/single 15.1±0.01µs 63.2 MElem/sec N/A N/A

@github-actions

github-actions Bot commented Jul 5, 2026

Copy link
Copy Markdown

Benchmark for 725d718

Click to view benchmark
Test Base PR %
PmTree::delete 1506.5±12.17µs 1526.0±15.43µs +1.29%
PmTree::get 693.2±44.87ns 655.3±55.98ns -5.47%
PmTree::get_empty_leaves_indices 61.5±0.62µs 61.6±1.01µs +0.16%
PmTree::get_subtree_root 391.5±5.63ns 383.0±7.27ns -2.17%
PmTree::override_range 135.3±3.58ms 137.9±3.56ms +1.92%
PmTree::proof 9.8±0.15µs 10.0±0.16µs +2.04%
PmTree::set 748.3±11.25µs 756.4±7.67µs +1.08%
PmTree::set_range 129.3±3.29ms 130.2±3.30ms +0.70%
PmTree::update_next 7.0±3.87ms 7.1±3.93ms +1.43%
PmTree::verify 502.7±5.09µs 516.0±16.56µs +2.65%
PmTreeProof::compute_root_from 499.6±4.92µs 512.3±2.85µs +2.54%
RLN::finish_proof 68.4±0.90ms 68.8±0.86ms +0.58%
RLN::generate_partial_proof 129.2±2.42ms 129.5±2.89ms +0.23%
RLN::generate_proof 187.3±3.05ms 189.7±8.88ms +1.28%

@github-actions

github-actions Bot commented Jul 5, 2026

Copy link
Copy Markdown

Benchmark for 7871c1c

Click to view benchmark
Test Base PR %
PmTree::delete 1509.4±13.58µs 1521.3±11.34µs +0.79%
PmTree::get 551.5±62.90ns 502.6±9.98ns -8.87%
PmTree::get_empty_leaves_indices 61.4±1.03µs 61.4±1.02µs 0.00%
PmTree::get_subtree_root 390.6±12.85ns 395.8±7.48ns +1.33%
PmTree::override_range 134.8±4.42ms 127.3±3.56ms -5.56%
PmTree::proof 9.7±0.34µs 9.5±0.30µs -2.06%
PmTree::set 744.5±12.94µs 768.2±10.71µs +3.18%
PmTree::set_range 125.3±3.55ms 126.2±5.16ms +0.72%
PmTree::update_next 6.9±3.82ms 6.7±3.64ms -2.90%
PmTree::verify 506.3±4.14µs 515.1±5.01µs +1.74%
PmTreeProof::compute_root_from 506.6±4.09µs 515.7±6.10µs +1.80%
RLN::finish_proof 68.4±2.20ms 69.0±0.85ms +0.88%
RLN::generate_partial_proof 128.7±1.16ms 129.2±1.24ms +0.39%
RLN::generate_proof 188.1±7.98ms 188.7±7.22ms +0.32%

@vinhtc27 vinhtc27 changed the title refactor(PR 12): add SecretFr to zerokit, standardize type naming in Wasm and FFI refactor(PR 12 part 1): add SecretFr to zerokit, standardize type naming in Wasm and FFI Jul 6, 2026
@vinhtc27
vinhtc27 requested a review from sydhds July 6, 2026 09:17
@vinhtc27 vinhtc27 changed the title refactor(PR 12 part 1): add SecretFr to zerokit, standardize type naming in Wasm and FFI refactor(PR 12): add SecretFr to zerokit, standardize type naming in Wasm and FFI Jul 6, 2026
@vinhtc27 vinhtc27 changed the title refactor(PR 12): add SecretFr to zerokit, standardize type naming in Wasm and FFI refactor(PR 12): add SecretFr, WasmSecretFr, FFI_SecretFr to zerokit, standardize type naming in Wasm and FFI Jul 6, 2026
Comment thread rln/tests/proof.rs
@@ -481,7 +481,7 @@ mod test {
let leaf_index = 3;

let identity_secret_seed = hash_to_field_le(b"test-merkle-proof");

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not using let mut then avoiding the clone here?

@vinhtc27 vinhtc27 Jul 6, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Handled in next PR 13.

Comment thread rln/src/hashers.rs
///
/// The internal copy of the secret is zeroized after hashing.
pub(crate) fn poseidon_hash_id_secret(secret: &SecretFr) -> Fr {
let mut to_hash = [**secret];

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

deref here would be more readable wdyt?

@vinhtc27 vinhtc27 Jul 6, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It still need * and then .deref so i guess it kinda the same, and also have to import some trait so i prefer this.

Comment thread rln/tests/keygen.rs

let expected_identity_secret = poseidon_hash_pair(trapdoor, nullifier);
let mut to_hash = [identity_secret];
let expected_identity_secret = poseidon_hash_pair(*trapdoor, *nullifier);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not use the hash pair for Secret Fr here ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These change in the next PR13

Comment thread rln-wasm/src/wasm_rln.rs
#[wasm_bindgen(js_name = newSingle)]
pub fn new_single(
identity_secret: &WasmFr,
identity_secret: &WasmSecretFr,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm seeing this only now but is there a reason we use reference here everywhere? Because, for example, it requires to clone the secret here so almost no reason no?

@vinhtc27 vinhtc27 Jul 6, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it has a good reason to do so.

WASM take & for all non-primitive types because with wasm-bindgen, a by-value param moves ownership, the JS object gets its internal pointer nulled after the call. JS has no move semantics, so callers don't expect this:

const keys = WasmIdentityKeys.generate();
const secret = keys.getSecret();
const w1 = WasmRLNWitnessInput.newSingle(secret, ...); // if by-value: secret is consumed here
const w2 = WasmRLNWitnessInput.newSingle(secret, ...); // throws "null pointer passed to rust"

With & the object stays alive and we clone once inside instead. Otherwise we need to provide clone() fn.

The same idea apply for FFI too.

@vinhtc27
vinhtc27 requested a review from sydhds July 6, 2026 14:37
@vinhtc27
vinhtc27 merged commit fb9a173 into develop/v3.0.0 Jul 7, 2026
15 checks passed
@vinhtc27
vinhtc27 deleted the refactor/pr12-todo branch July 7, 2026 15:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants