Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create near-crypto crate that can be compiled for wasm32 #7137

Open
ijerkovic opened this issue Jun 29, 2022 · 17 comments
Open

Create near-crypto crate that can be compiled for wasm32 #7137

ijerkovic opened this issue Jun 29, 2022 · 17 comments
Labels
A-cryptography Area: Cryptography A-RPC Area: rpc

Comments

@ijerkovic
Copy link

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
Copy link
Author

@medicz @chefsale

@chefsale
Copy link
Contributor

@matklad
Copy link
Contributor

matklad commented Jun 30, 2022

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
Copy link
Contributor

matklad commented Jun 30, 2022

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
Copy link
Contributor

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
Copy link
Member

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
Copy link

tasty

@sascha1337
Copy link

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
Copy link
Collaborator

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.

@bowenwang1996 bowenwang1996 added A-RPC Area: rpc A-cryptography Area: Cryptography labels Jul 7, 2022
@ijerkovic
Copy link
Author

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
Copy link

wen ?

@russellwmy
Copy link

@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
Copy link
Author

@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
Copy link
Contributor

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

@russellwmy
Copy link

@ijerkovic & @nearmax
You can book a meeting here

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

@nagisa
Copy link
Collaborator

nagisa commented Jul 14, 2023

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
Copy link

Did this before quite easy
What else blocking ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-cryptography Area: Cryptography A-RPC Area: rpc
Projects
None yet
Development

No branches or pull requests

11 participants