search

ZenGo-X / emerald-city

WASM/HW-friendly lightweight client application for threshold ECDSA
GNU General Public License v3.0
15 stars 6 forks source link

secp256k1 no_std/wasm friendly #4

Open vhnatyk opened 5 years ago

vhnatyk commented 5 years ago

Seems C library from Rust compiled to WASM is not quite impossible but maybe a better idea to replace with some pure Rust implementation alternative like libsecp256k1-rs

vhnatyk commented 5 years ago

seems the crate we currently use is no_stdfriendly according to this merged PR

vhnatyk commented 5 years ago

also found origin of the pure rust alternative, though it's not on github

vhnatyk commented 5 years ago

All tests passing including last one test_from_bytes, thanks @omershlo for the suggested fix 👍. Though #6 is ready to be merged, maybe we should consider keeping no_std and wasm branches separate for some time, since no_std may require further heavy modifications and a current secp256k1 crate is no_std compatible anyway.

omershlo commented 5 years ago

I lost you: 1) #6 is no_std??? 2) #6 compiles on wasm ? (and how do I try it) 3) I don't understand what two branched you suggest (there's the one with old secp256 lib and the one with new secp256 lib, did you mean these two? ) 4) what are the "features" needed for wasm friendly version?

The above is probably a list of stupid questions: If I understand you correctly: #6 is wasm compatible. We want to merge it and start a branch for no_std version? Am I understand you correctly ?

vhnatyk commented 5 years ago

Hi)

  1. Current secp256k1 crate got no_std support very recently (10 days ago) - it's wrapper around well established C lib with good performance. Though it's practically not compatible with wasm due to libc

  2. 6 builds on wasm 👍 - but to run actually, there is another PR sitting in my branch cause it's based on top of this unmerged one - and there is info on how to run

  3. Actually keeping support for both no_std and wasm in a single branch via conditional compilation may be a bit tedious. There are few more duplicating crates to be removed etc - the issue is flash memory size, RAM usage etc - while with that delayed PR we are fine for wasm already. Maybe we should try to keep two separate branches for no_std and wasm(or make wasm master) - as probably still a huge amount of work ahead for bare metal devices

  4. Please check the draft PR - as it has only delta between this #6 and clearly shows code that makes it run on wasm

At the moment I tend to find more benefits from pure rust crate in this PR - main concern was the performance, now we know is ok in release, and result compiled file size is a lot smaller. Current rust-secp256k1 C lib is ~500kb almost uncompressable. Pure Rust libsecp256k1 is smaller.

Sintayew4 commented 3 months ago

4