Enabling Nova to be used in `no_std` environments #376

milosdjurica · 2025-03-13T11:42:40Z

Closes #345

This PR enables Nova to be used in no_std environments. After this PR is merged users of this library will have the option to choose if they want std or no_std version of Nova.

`std` functionalities remain unchanged!

Main points for no_std part ->

Rayon parallelization is disabled since parallelization can not be used in no_std environments.
halo2curves dependency can not be used as it is not no_std compatible. Instead of halo2curves, pasta_curves crate is used for Pallas and Vesta curves. Secp, Secq, Bn256 and Grumpkin curves are not available for now in no_std environments.
bincode dependency version is changed to 2.0.0-rc.3 as the old one was not compatible for no_std.
Using rand_core + rand_chacha for RNG, as OsRng relies on the operating system and is unavailable in no_std environments.
In no_std using OnceCell from core::cell::OnceCell instead of once_cell crate .
Default features are disabled for most of other dependencies.

@srinathsetty no_std branch was used as a reference for some of the changes -> main...no_std

As I said, Nova's functionality remains unchanged by default, but this gives users an option to use it in a no_std environments too by disabling default features. Also, all tests are passing!
To build the Nova library on no_std target, use cargo build --target thumbv7em-none-eabi --no-default-features.

I’m more than open to all questions, suggestions, discussions, and corrections! Please let me know what you think! :)

…ents + fix rayon

* checkpoint * OsRng fixed * checkpoint * builds on no_std

* feat: add batch commit to trait (microsoft#366) * feat: add batch_commit and default implementation to CommitmentEngineTrait * feat: add batch_vartime_multiscalar_mul and default implementation to DlogGroup trait * feat: implement batch_commit in hyperkzg * fix: batch_commit should support using a slice of blinding factors * KZG Key Generation, Save, Load (microsoft#368) * save load * fixed exp batch * tools * fix * fix * fix * improve interface * clean * fix typos * fix * clean * ptau * ptau save load * fix * fix * pedersen save --------- Co-authored-by: Srinath Setty <srinath@microsoft.com> * An initial implementation of NeutronNova (microsoft#370) * simplify types * placeholder * deduplicate code an initial draft of running instance in neutronnova * test default instance-witness pair * simplify poseidon sponge * checkpoint NIFS prover * add verify * add padding in test case * additional progress * finish testing neutronnova folding scheme * small cleanup * factor out contributions from eq * reorganize code * checkpoint * change power polynomial * checkpoint * checkpoint working test * switch the order * checkpoint * compute the right E vectors * leverage the nested structure * simplify the handling of E1 and E2 * simplify the handling of E1 and E2 * simplify tests * test when the left and right split unevenly * rearrange * general code cleanup * fix clippy warnings * simplify Poseidon state reset; cleanup unused code * cleanup unused code * checkpoint circuits from Nova folding scheme * checkpoint and reorganize gadgets a bit * use the version from gadgets * create various low-level gadgets * fix most of the build issues * fix build issues * more progress on circuit * fix duplicate paths * use expect test * replace params with vk to avoid confusion * builds * tests build * additional checks * print failures * simplify the RO usage * fix tests * fix univariate * checkpoint * checkpoint nifs circuit * checkpoint * test passes * cargo check passes * revive tests * add missing file * cleanup; fix test * fix clippy * add missing constraints * simplify * move neutron under an experimental feature flag * remove unused file * remove unused file * save on field multiplications * Simplify Nova APIs (microsoft#373) * checkpoint simplified APIs * cleanup code * fix benches to use the simplified APIs * de-duplicate hash check code * fix clippy errors * bring back MSM from https://github.com/microsoft/Nova/blob/7050052bc2… (microsoft#375) * bring back MSM from https://github.com/microsoft/Nova/blob/7050052bc2606129fbb52a1fa666eef22d92748d/src/provider/msm.rs * fix tests * fixed to work in no_std too --------- Co-authored-by: Jacob Trombetta <jacob.trombetta@spaceandtime.io> Co-authored-by: SunJc <331631622@qq.com> Co-authored-by: Srinath Setty <srinath@microsoft.com>

milosdjurica · 2025-03-13T11:56:25Z

@milosdjurica please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
@microsoft-github-policy-service agree [company="{your company}"]
Options:

(default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.
@microsoft-github-policy-service agree
(when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.
@microsoft-github-policy-service agree company="Microsoft"
Contributor License Agreement

@microsoft-github-policy-service agree company="MVP Workshop"

src/gadgets/nonnative/util.rs

src/nova/mod.rs

Cargo.toml

src/spartan/snark.rs

srinathsetty · 2025-03-13T18:32:35Z

Thanks for submitting this PR! I'll add comments one by one.

As a note: We should also add a CI job to check if the code builds in no_std mode.

src/provider/mod.rs

srinathsetty · 2025-03-17T18:30:07Z

src/provider/mod.rs

 use serde::{Deserialize, Serialize};

 /// An implementation of Nova traits with HyperKZG over the BN256 curve
+#[cfg(feature = "std")]


This seems quite hard to maintain going forward. Wouldn't it be simpler to make the underlying code "no std" compatible rather than introducing new types at the highest level?

I agree, it is not ideal scenario. The current problem is that halo2curves are not no_std compatible. I started working on converting halo2curves crate to be no_std compatible, then we will be able to use halo2curves everywhere (in std & no_std environment).

You can see the changes here -> privacy-ethereum/halo2curves@main...milosdjurica:halo2curves:no_std

Any help with those changes is more than welcome!

I think there may be a way to pass pasta_curves to Nova without needing Nova to maintain that code. For example, we could have the layer above Nova implement Nova's traits for pasta_curves types right?

Latest commit b45a5db resolves this by removing pasta_curves completely, and uses halo2curves for STD and NO_STD. This will make code much more simpler to maintain going forward. I am waiting for PR in halo2curves to be accepted and then I will change halo2curves import in Cargo.toml -> b45a5db#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542R46

src/provider/msm_no_std_impl.rs

srinathsetty · 2025-03-17T18:32:29Z

src/provider/pasta_curves.rs

@@ -0,0 +1,176 @@
+#![cfg(not(feature = "std"))]
+//! This module implements the Nova traits for `pallas::Point`, `pallas::Scalar`, `vesta::Point`, `vesta::Scalar`.
+


We recently dropped support for pasta_curves because it is hard to maintain layers on multiple curve libraries and halo2curves implements pasta_curves. Is there a reason to bring this back?

Responded here -> #376 (comment)

I have made changes in the latest commit to resolve this, now I am just waiting for the PR in halo2curves to be accepted. Changes -> b45a5db

srinathsetty · 2025-03-17T18:33:42Z

src/r1cs/mod.rs

+    #[cfg(feature = "std")]
    let r_E = E::Scalar::random(&mut OsRng);
+    #[cfg(not(feature = "std"))]
+    let r_W = E::Scalar::random(&mut ChaCha20Rng::seed_from_u64(0xDEADBEEF));


This is not safe. We need to sample random numbers to provide zero-knowledge. Please change these everywhere to call into a secure random number generator.

srinathsetty · 2025-03-17T18:34:41Z

src/spartan/mod.rs

  );

+  // Sequential execution instead of rayon::join
+  #[cfg(not(feature = "std"))]


Is there a reason to do this here than in the underlying code inner?

Not really sure what do you mean by this?

srinathsetty · 2025-03-17T18:37:31Z

Hi @milosdjurica thanks again for your work on this! I've left some comments. The most important one is related to random number generator used. It seems like the code hardcodes randomness instead of sampling from a secure rng. Is there no random number generator in no-std environment? If yes, then I'm not sure the prover and the setup can be safely implemented in such environments.

milosdjurica · 2025-03-18T16:43:16Z

Hi @srinathsetty , thank you for the effort! I have resolved some changes, and as I noted, I started working on no_std version of halo2curves . I will look into the RNG problem and let you know when I find something. If you have something on your mind please let me know.

I'm open for all suggestions, and once again, thank you very much! :)

milosdjurica · 2025-03-21T12:18:00Z

Hi @srinathsetty , here is the update.

Halo2curves

Regarding halo2curves, I have opened PR to make it no_std, now waiting for it to get merged. After it gets merged, we will be able to use halo2curves in both -> no_std and std environment, and there won't be need for pasta_curves crate. Link to PR -> privacy-ethereum/halo2curves#192

There is one more thing regarding this. Nova is using halo2curves with derive_serde feature, and this includes one more crate which is serde_arrays and it is not no_std compatible, so I have opened a PR there too -> Kromey/serde_arrays#36

RNG

Regarding RNG in no_std, seems like there is no universal and simple way to get secure random number (at least I am not aware of it right now). ChaCha is creating a PRNG from seed, but for the same seed, output will always be the same and predictable, which is not secure. The solution is to get a random number in no_std environment is to provide a ChaCha with secure entropy source, but this depends on a specific targets.

Under the hood, rand and rand_core libraries use getrandom crate to get random data from system resources. In order to get this to work with thumbv7em-none-eabi target, we would need to create our own backend that will retrieve random data from system.

Possible solution for RNG

What we can do is to hide functionality that requires RNG behind STD feature flag. This would mean that STD users can do same things as they always could. In no_std mode users would only be able to verify the proofs, but not create them. This is still improvement, as in earlier versions, no_std users could not interact with library in any way.

std -> can prove and verify (stays the same like it has always been and uses safe OsRng)
no-std -> can only verify

Please let me know what you think. Thanks!

srinathsetty · 2025-03-21T18:23:38Z

std -> can prove and verify (stays the same like it has always been and uses safe OsRng)

no-std -> can only verify

Update: It is dangerous to provide APIs where someone can produce a proof in no_std mode that are easily distinguishable. In particular, if the prover uses a seed that's known or can be guessed, it's easy to break zero-knowledge. We cannot hope that no one runs the prover in no_std mode.

If your goal is to only run the verifier in no_std mode, then why not simply write a stand-alone program that deserializes Nova's bincode-encoded proofs and verify them? The verification algorithm can be easily pieced together using code provided in this library.

milosdjurica · 2025-03-24T12:43:41Z

Update: It is dangerous to provide APIs where someone can produce a proof in no_std mode that are easily distinguishable. In particular, if the prover uses a seed that's known or can be guessed, it's easy to break zero-knowledge. We cannot hope that no one runs the prover in no_std mode.

I completely agree with this, but this is not what I was suggesting. I will give a minimal example to explain what I was trying to say.

struct CompressedSNARK {
  // Fields...
}

impl CompressedSNARK {
  #[cfg(feature = "std")]
  pub fn prove() {
    // This method uses RNG and it will only be available in STD mode. We will keep using OsRng as before.
    // But, users WILL NOT BE ABLE to `prove()` in no_std environment due to the feature flag above the method -> `#[cfg(feature = "std")]`.
    // This means that if users want to call this method, they must be in STD mode, and they will use safe OsRng for random number.
  }
  pub fn verify() {
    // This method DOES NOT use RNG, so it is completely safe to let users call this function in both, std and no_std mode.
  }
}

Users in STD environment can call both prove and verify methods, but users in NO_STD environment can ONLY call verify method.

Long story short ->

NO_STD users will only be able to use safe parts of API (parts that do not use RNG).
STD part will stay completely same and completely safe as before. It will use safe OsRng for creating random numbers as it was using it before.

If your goal is to only run the verifier in no_std mode, then why not simply write a stand-alone program that deserializes Nova's bincode-encoded proofs and verify them? The verification algorithm can be easily pieced together using code provided in this library.

Regarding this : In order to deserialize proof and verify it, you need to specify in which struct you want to deserialize into. That means you need to import a struct from Nova, and that means Nova has to be dependency in your project. If Nova is not no_std compatible, then the program calling it also can not be no_std compatible.

Let me know what you think about this. I hope I explained it well now, and that it makes more sense. If you agree with this, I will make another commit that will remove using unsafe RNG in no_std mode and only enable using safe RNG in std mode

P.S. -> Latest commit b45a5db removes pasta_curves completely as dependency and enables using halo2curves in both STD and NO_STD mode.
I am waiting for the PR to be accepted in halo2curves and then I will change Cargo.toml to point to their repo instead of my fork.

milosdjurica · 2025-03-26T09:40:18Z

Hi @srinathsetty ,

Here is commit regarding RNG -> 402073b

I decided to take a bit different approach from what I have explained earlier, as previous approach would bloat the whole codebase with #[cfg(feature = "std")] flags.
What I chose to do was to introduce a new error - NovaError::UnsafeRandomNumber , and throw that error when user tries to call RNG method and std feature is off.

This keeps the codebase clean, safe and easy to maintain.
Let me know what you think of this. Thank you!

srinathsetty · 2025-03-26T18:43:17Z

Regarding this : In order to deserialize proof and verify it, you need to specify in which struct you want to deserialize into. That means you need to import a struct from Nova, and that means Nova has to be dependency in your project. If Nova is not no_std compatible, then the program calling it also can not be no_std compatible.

Diving a bit into this. I'm not sure it is necessary to have Nova as a dependency at all. There should be a way to build a stand-alone nova-verifier that is pinned to a particular nova prover version that can deserialize proofs produced by the prover into types owned by this project and verify them. We did this in a completely different language (Solidity), see e.g., https://eprint.iacr.org/2024/2099, so it should be possible to do the same in Rust.

milosdjurica · 2025-03-31T12:48:44Z

Diving a bit into this. I'm not sure it is necessary to have Nova as a dependency at all. There should be a way to build a stand-alone nova-verifier that is pinned to a particular nova prover version that can deserialize proofs produced by the prover into types owned by this project and verify them. We did this in a completely different language (Solidity), see e.g., https://eprint.iacr.org/2024/2099, so it should be possible to do the same in Rust.

Hi @srinathsetty , Thanks for this, I will take a look.

Do you maybe have any other suggestions for other changes made in this PR?

P.S.
I did some tests about faster MSM #372 and i found out that halo2curves MSM implementation is almost 2x faster than the current one. However, this would require more testing as I only tested for verifications of Pallas-Vesta SNARKs with spark compression, without any additional features turned on. Values I got are 412ms for current MSM implementation in this library, and 230ms for halo2curves MSM implementation.

I tested in both STD and NO_STD environments and in both cases it was faster. Might be worth exploring this deeper. You can see changes here -> MVPWorkshop@6c30073 . Note: this is not included in this current PR.

msm_fast.rs is halo2curves implementation from https://github.com/privacy-scaling-explorations/halo2curves/blob/main/src/msm.rs with some small changes in order to make it compile on no_std.

srinathsetty · 2025-04-01T18:04:35Z

Diving a bit into this. I'm not sure it is necessary to have Nova as a dependency at all. There should be a way to build a stand-alone nova-verifier that is pinned to a particular nova prover version that can deserialize proofs produced by the prover into types owned by this project and verify them. We did this in a completely different language (Solidity), see e.g., https://eprint.iacr.org/2024/2099, so it should be possible to do the same in Rust.

Hi @srinathsetty , Thanks for this, I will take a look.

Do you maybe have any other suggestions for other changes made in this PR?

P.S. I did some tests about faster MSM #372 and i found out that halo2curves MSM implementation is almost 2x faster than the current one. However, this would require more testing as I only tested for verifications of Pallas-Vesta SNARKs with spark compression, without any additional features turned on. Values I got are 412ms for current MSM implementation in this library, and 230ms for halo2curves MSM implementation.

I tested in both STD and NO_STD environments and in both cases it was faster. Might be worth exploring this deeper. You can see changes here -> MVPWorkshop@6c30073 . Note: this is not included in this current PR.

msm_fast.rs is halo2curves implementation from https://github.com/privacy-scaling-explorations/halo2curves/blob/main/src/msm.rs with some small changes in order to make it compile on no_std.

This is unexpected. Would you be able to run the commitment benchmark on your machine and report results here. The command is: cargo bench --bench=commit

milosdjurica · 2025-04-03T12:26:55Z

You are right regarding the benchmarks. I have ran benchmarks and it says that halo2curves is slower. However, verification test says different.

Could you update your test src/nova/mod.rs::tests::test_ivc_nontrivial_with_spark_compression_with<...>(...) like this ->

  fn test_ivc_nontrivial_with_spark_compression_with<E1, E2, EE1, EE2>()
  where
    E1: Engine<Base = <E2 as Engine>::Scalar>,
    E2: Engine<Base = <E1 as Engine>::Scalar>,
    EE1: EvaluationEngineTrait<E1>,
    EE2: EvaluationEngineTrait<E2>,
  {
    // ...
    // ...

+   let start = std::time::Instant::now();
    // verify the compressed SNARK
    let res = compressed_snark.verify(&vk, num_steps, &[<E1 as Engine>::Scalar::ZERO]);
+   let duration = start.elapsed();
+   println!("Duration is -> {:?}", duration);

and run test with the following command -> cargo test --release -- --nocapture test_ivc_nontrivial_with_ .
Flag -- --nocapture allows us to see the prints.
Do this with the current msm implementation on main and then compare it with halo2curves msm implmentation. main...MVPWorkshop:Nova:proof_of_faster_msm Here you can see the changes needed in order to use halo2curves msm implementation.

Those are my results ->

ON MAIN ->

running 1 test
Duration is -> 473.631666ms
Duration is -> 274.569834ms
test nova::tests::test_ivc_nontrivial_with_spark_compression has been running for over 60 seconds
Duration is -> 545.656791ms
test nova::tests::test_ivc_nontrivial_with_spark_compression ... ok

USING HALO2CURVES MSM ->

running 1 test
Duration is -> 223.310875ms
Duration is -> 118.1095ms
Duration is -> 225.901208ms
test nova::tests::test_ivc_nontrivial_with_spark_compression ... ok

It is faster in all 3 cases, and it should also be faster not only for spark compression but also for normal compression in -> test_ivc_nontrivial_with_compression()

srinathsetty · 2025-04-05T01:15:59Z

You are right regarding the benchmarks. I have ran benchmarks and it says that halo2curves is slower. However, verification test says different.

Could you update your test src/nova/mod.rs::tests::test_ivc_nontrivial_with_spark_compression_with<...>(...) like this ->
  fn test_ivc_nontrivial_with_spark_compression_with<E1, E2, EE1, EE2>()
  where
    E1: Engine<Base = <E2 as Engine>::Scalar>,
    E2: Engine<Base = <E1 as Engine>::Scalar>,
    EE1: EvaluationEngineTrait<E1>,
    EE2: EvaluationEngineTrait<E2>,
  {
    // ...
    // ...

+   let start = std::time::Instant::now();
    // verify the compressed SNARK
    let res = compressed_snark.verify(&vk, num_steps, &[<E1 as Engine>::Scalar::ZERO]);
+   let duration = start.elapsed();
+   println!("Duration is -> {:?}", duration);
and run test with the following command -> cargo test --release -- --nocapture test_ivc_nontrivial_with_ . Flag -- --nocapture allows us to see the prints. Do this with the current msm implementation on main and then compare it with halo2curves msm implmentation. main...MVPWorkshop:Nova:proof_of_faster_msm Here you can see the changes needed in order to use halo2curves msm implementation.

Those are my results ->

ON MAIN ->
running 1 test
Duration is -> 473.631666ms
Duration is -> 274.569834ms
test nova::tests::test_ivc_nontrivial_with_spark_compression has been running for over 60 seconds
Duration is -> 545.656791ms
test nova::tests::test_ivc_nontrivial_with_spark_compression ... ok
USING HALO2CURVES MSM ->
running 1 test
Duration is -> 223.310875ms
Duration is -> 118.1095ms
Duration is -> 225.901208ms
test nova::tests::test_ivc_nontrivial_with_spark_compression ... ok
It is faster in all 3 cases, and it should also be faster not only for spark compression but also for normal compression in -> test_ivc_nontrivial_with_compression()

It is not clear why the microbenchmark will show halo2curves as slow but faster when used elsewhere. Thanks, will investigate!

milosdjurica · 2025-04-07T10:14:22Z

Thanks for looking into it!

In the meantime, do you have any questions or suggestions about other things regarding this PR? Here is comment regarding latest RNG changes #376 (comment)

zakajd · 2025-05-31T05:58:00Z

@srinathsetty What is the current state of this PR? Can it be merged or still waiting for the upstream PR in halo2curves repo to be merged first?

milosdjurica and others added 16 commits February 10, 2025 21:09

cargo.toml update

aca9049

Merge branch 'microsoft:main' into no_std_latest

42e7341

Merge branch 'microsoft:main' into no_std_latest

9486641

halo2curves only on STD, prelude crate

3aaff41

no_std pasta curves impl

04ee879

no_std pasta_curves impl + comments in cargo.toml

0628d50

bincode and byteorder fix, added comments for later, TODO delete comm…

b7782a0

…ents + fix rayon

bincode fix

3cb4f0f

rayon paralel only for STD, sequential for NO_STD

670a842

Prelude changes (#11)

96fb896

* checkpoint * OsRng fixed * checkpoint * builds on no_std

Merge branch 'microsoft:main' into no_std_latest

4aa9ebd

getrandom optional for wasm32

c81aecb

once_cell from core for no_std and allow unused imports for FloatCore

c49fa4f

removed comments

577e8d5

moving core::cell:OnceCell into prelude

30ddc84

milosdjurica and others added 3 commits March 13, 2025 14:19

Merge branch 'main' into no_std_latest

31b310c

comment formatting

13448ee

removed cs and vk

b51c4cb

srinathsetty reviewed Mar 13, 2025

View reviewed changes

src/gadgets/nonnative/util.rs Outdated Show resolved Hide resolved

srinathsetty reviewed Mar 13, 2025

View reviewed changes

src/nova/mod.rs Outdated Show resolved Hide resolved

srinathsetty reviewed Mar 13, 2025

View reviewed changes

Cargo.toml Show resolved Hide resolved

srinathsetty reviewed Mar 13, 2025

View reviewed changes

src/spartan/snark.rs Outdated Show resolved Hide resolved

milosdjurica and others added 4 commits March 14, 2025 09:28

removed comments

46866bf

maybe_rayon (#13)

58b6783

merge main

db76abf

no_std job

ec35376

srinathsetty mentioned this pull request Mar 14, 2025

Experimental support for no_std #344

Closed

srinathsetty reviewed Mar 17, 2025

View reviewed changes

src/provider/mod.rs Outdated Show resolved Hide resolved

srinathsetty reviewed Mar 17, 2025

View reviewed changes

src/provider/mod.rs Outdated Show resolved Hide resolved

srinathsetty reviewed Mar 17, 2025

View reviewed changes

src/provider/msm_no_std_impl.rs Outdated Show resolved Hide resolved

srinathsetty reviewed Mar 17, 2025

View reviewed changes

milosdjurica added 4 commits March 18, 2025 16:43

write_bytes -> to_bytes

6a91fba

result -> digest

e87ed1d

removed comments, updated imports from std to core

5b26ac4

both STD and NO_STD using same msm

6d4c959

milosdjurica added 2 commits March 20, 2025 12:23

merge main

ae8a034

merge main

27a4de4

Changed from pasta_curves in no_std to halo2curves for both (#14)

b45a5db

removed chacha random number

402073b

merge main

3514046

merge main

72b4521

		@@ -0,0 +1,176 @@
		#![cfg(not(feature = "std"))]
		//! This module implements the Nova traits for `pallas::Point`, `pallas::Scalar`, `vesta::Point`, `vesta::Scalar`.

Enabling Nova to be used in no_std environments #376

Are you sure you want to change the base?

Enabling Nova to be used in no_std environments #376

Uh oh!

Conversation

milosdjurica commented Mar 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

std functionalities remain unchanged!

Uh oh!

milosdjurica commented Mar 13, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

srinathsetty commented Mar 13, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

srinathsetty commented Mar 17, 2025

Uh oh!

milosdjurica commented Mar 18, 2025

Uh oh!

milosdjurica commented Mar 21, 2025

Halo2curves

RNG

Possible solution for RNG

Uh oh!

srinathsetty commented Mar 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

milosdjurica commented Mar 24, 2025

Long story short ->

Uh oh!

milosdjurica commented Mar 26, 2025

Uh oh!

srinathsetty commented Mar 26, 2025

Uh oh!

milosdjurica commented Mar 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

srinathsetty commented Apr 1, 2025

Uh oh!

milosdjurica commented Apr 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

srinathsetty commented Apr 5, 2025

Uh oh!

milosdjurica commented Apr 7, 2025

Uh oh!

zakajd commented May 31, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

Enabling Nova to be used in `no_std` environments #376

Enabling Nova to be used in `no_std` environments #376

milosdjurica commented Mar 13, 2025 •

edited

Loading

`std` functionalities remain unchanged!

srinathsetty commented Mar 21, 2025 •

edited

Loading

milosdjurica commented Mar 31, 2025 •

edited

Loading

milosdjurica commented Apr 3, 2025 •

edited

Loading