You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, migrating the crate to no_std without the usage of allocators is "possible" but completely useless.
We need to use Vec-like structures, and the only full no_std compatible libs that don't require alloc to work are arrayvec and const-arrayvec. Both of them will eat the entire stack of any regular machine if we try to compute big Proofs (2^16 or more constraints).
Therefore, our best bet is to use an alloc gate for the time being, and if we're in enviroments such as WASM where we want to generate proofs, there's some work already done in allocators there. For embedded I think it's quite impossible to do so if the proofs are bigger than a thousand constraints, maybe much less.
So the idea is to port the repo to no_std and move all of the Vec related work behind an alloc feature. On that way, at least the data structures such as Proof or others can be fully no_std compatible even an allocator will be needed for sure.
The text was updated successfully, but these errors were encountered:
Currently, migrating the crate to
no_std
without the usage of allocators is "possible" but completely useless.We need to use Vec-like structures, and the only full
no_std
compatible libs that don't requirealloc
to work arearrayvec
andconst-arrayvec
. Both of them will eat the entire stack of any regular machine if we try to compute bigProof
s (2^16 or more constraints).Therefore, our best bet is to use an
alloc
gate for the time being, and if we're in enviroments such asWASM
where we want to generate proofs, there's some work already done in allocators there. For embedded I think it's quite impossible to do so if the proofs are bigger than a thousand constraints, maybe much less.So the idea is to port the repo to
no_std
and move all of theVec
related work behind analloc
feature. On that way, at least the data structures such asProof
or others can be fullyno_std
compatible even an allocator will be needed for sure.The text was updated successfully, but these errors were encountered: