Create near-crypto crate that can be compiled for wasm32

[ijerkovic]

We tried including near-crypto as a dependency for our light client contract but we get an error when compiling for wasm32.
This is the error:
the wasm32-unknown-unknown target is not supported by default, you may need to enable the "js" feature. For more information see: [https://docs.rs/getrandom/#webassembly-support](https://www.google.com/url?q=https://docs.rs/getrandom/%23webassembly-support&sa=D&source=docs&ust=1656515658320773&usg=AOvVaw1OyQqyRsfwq8cHsQw1O_c2)

We need the near-crypto for verifying Ed25519 and SECP256k1 signatures.

While we did manage to make signature verifying work in our contract and compile for wasm32 by taking ed25519-dalek and libsecp256k1 crates, it would be great if there existed a wasm32 friendly crate for near-crypto.

Also for reference here is how we made it work for us (notice we had to include few versions of random as dev-dependencies):

[package]
name = "test-package"
 
[lib]
crate-type = ["cdylib", "rlib"]
 
[dependencies]
utils = { path = "../utils" }
near-sdk = "4.0.0"
ed25519-dalek = "1"
getrandom = { version = "0.2", features = ["custom"] }
libsecp256k1 = "0.7"
thiserror = "1"
primitive-types = "0.10"
derive_more = "0.99.9"
 
[dev-dependencies]
rand_08 = { package = "rand", version = "0.8" }
rand_core_06 = { package = "rand_core", version = "0.6" }
rand_07 = { package = "rand", version = "0.7" }
rand_core_05 = { package = "rand_core", version = "0.5" }

[ijerkovic]

@medicz @chefsale

[chefsale]

cc: @matklad @ilblackdragon @bowenwang1996

[matklad]

This needs some design work: near-crypto is the crypto needed to implement the near-node. This is not the same as the crypto needed to interact with near-node.

So, what we need here is probably to create a separate crate, near-client-crypto, which is independent from near-crypto (the same way the rpc types crate should be independent of naercore) and is intended to be used alongside the rpc types crate to intetrface with near node from Rust. This'll also be useful for stuff like workspaces.

This probably wants to be on dev-platform's plate, cc @austinabell

[matklad]

That being said, near-crypto today doesn't have dependencies on other nearcore stuff, so, if the actual engineering work to make that compatible with wasm is small, I'll be OK with just dumping that to crates.io under 0.x version.

Note that this won't be ideal situation for the consumers:

• there won't be guarantees about APIs not breaking
• even if we could make it work on wasm, I'd be against putting engineering effort into making it work good on wasm. Ie, stuff like "use ed25519 dalek on x86_64 but ed25519-compact (https://github.com/jedisct1/rust-ed25519-compact) on WASM" isn't somethig we should be doing here I think.

[austinabell]

Anyone would be able to write this library, it has no dependencies on anything to change here. Is the ask that this be done in such a way that it's plugged into our tools somehow and therefore made sure to be maintained? Is there something else that I'm missing that would be valuable for us to take action on?

But yes definitely agree this isn't on nearcore/core team if we build this lib

cc @AustinBaggio

[ilblackdragon]

There are two points here:

• The specific functions to verify signatures. There is a proposal to make such a host functions to reduce their cost, and I would support that proposal: NEP-364: Efficient signature verification host functions NEPs#364
• There is a number of primitives in nearcore that are needed in the smart contracts. The reason for that was to make sure that these libraries are maintained together with nearcore and using the same primitives across smart contracts and the node. For example, there is a near-primitive-core which is designed for that.

For specifically crypto library, there is randomness used in:

• vrf - that is not even used anywhere AFAIK
• randomness module - also not sure where is that used
• and new key generation,

All of these can be wrapped with "rand" or "node" feature of this module.
Such that near-crypto will just need to be included with features = ["rand"]

[sascha1337]

tasty

[sascha1337]

https://github.com/CosmWasm/drand-verify
https://github.com/confio/rand

There are two points here:

• The specific functions to verify signatures. There is a proposal to make such a host functions to reduce their cost, and I would support that proposal: NEP-364 NEPs#364
• There is a number of primitives in nearcore that are needed in the smart contracts. The reason for that was to make sure that these libraries are maintained together with nearcore and using the same primitives across smart contracts and the node. For example, there is a near-primitive-core which is designed for that.

For specifically crypto library, there is randomness used in:

• vrf - that is not even used anywhere AFAIK
• randomness module - also not sure where is that used
• and new key generation,

All of these can be wrapped with "rand" or "node" feature of this module. Such that near-crypto will just need to be included with features = ["rand"]

[bowenwang1996]

I don't think any of the developer platform teams has time for this right now. @ijerkovic do you want to work on this yourself? We can certainly help review the pull requests.

[ijerkovic]

From the side of Calimero, we should be good enough with the NEP-364 which will add both ed25519_dalek and secp256k1 signature verification into NEAR runtime as pre-compiled functions.
We are also low on dev time currently, but we can get back to this eventually.
Thanks for all the input!

[sascha1337]

wen ?

[russellwmy]

@sascha1337 I am not sure how urgent you need this feature. I created a NEAR SDK that works on browser. However, it is not stable. I built for developing dapp with dioxus (Web UI framework). Here is the SDK https://github.com/russellwmy/web3-anywhere.

@matklad I mentioned in #6387.
@ijerkovic in case you need reference and idea. we can meet and talk about it. I want the native SDK can build on WASM as well.

cc: @ilblackdragon @ijerkovic

[ijerkovic]

@russellwmy I would love to hear more, however for us this is currently low priority since we managed to make our contracts work with minimal copy/pasted signature verify code from https://github.com/near/nearcore/blob/4b055712e478675e9b05095f9191c9ba8bfa4022/core/crypto/src/signature.rs
Also, with nep-364 the signature verification should be available through the env so this is really not a blocker for us at all.

All our efforts are currently at testing and preparing bridge contracts for audit, but we can meet and talk about it.

[MaksymZavershynskyi]

@russellwmy . I would love to talk about it. What is the best way to contact you?

[russellwmy]

@ijerkovic & @nearmax
You can book a meeting here

https://calendly.com/d/d2c-w49-fry/30-minute-meeting?month=2022-10

[nagisa]

We do have a near-crypto crate now, but is it being compiled to wasm32 and are people using it?

EDIT: Ah, never mind, I didn't read the original issue statement closely enough.

[sascha1337]

Did this before quite easy
What else blocking ?