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

Refactor crypto and other WASM-based modules #341

Conversation

cairomassimo
Copy link
Contributor

@cairomassimo cairomassimo commented Feb 5, 2024

Description

Re-implement the functionality of @lit-protocol/crypto package as follows (WIP!):

  • create a new nx workspace (currently in the ng/ dir), with a simpler/standard build system,
  • create a unified Rust crate exposing an API to js,
  • merge all Rust crates, which expose functionality via wasm, into the unified one,
  • set up a mechanism to generate TypeScript types from Rust (beyond those created by wasm-bindgen, if needed),
  • add a thin (type-safe) JS layer on top of Rust, dealing with data conversion (the less, the better),
  • migrate all tests for @lit-protocol/crypto to the new implementation,
  • migrate all uses of/references to @lit-protocol/crypto to the new implementation.

Design choices

  • esbuild as bundler
    • supports embedding binary files out-of-the box, useful for wasm
    • fast
    • supported by jest via esbuild-jest-transform
  • single javascript package (currently named @lit-protocol/ng, to be renamed)
    • tree-shaking should remove unused functionalities,
    • better split into modules, before splitting into packages,
    • split into packages later, when useful/needed (e.g. to reduce build time, to support different build pipelines, what not).

Notes

The build does not generate .d.ts TypeScript declaration files yet.
Not adding this for now, since it could come for free if recent PR nrwl/nx#21084 is merged (or nrwl/nx#20688 fixed anyway).

@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@joshLong145
Copy link

@cairomassimo Would it be easier if we made a feature branch for this work? this would make it easier to review the work over time as comments will be cleared once you push newer commits. If we used a feature branch then we could review in a more manageable fashion. WDYT?

@cairomassimo
Copy link
Contributor Author

cairomassimo commented Feb 9, 2024

To do:

  • make the exported wasm function handle multiple curves dynamically (the api is identical, less code, no/less need for macros)
  • see what happens if we bypass nx entirely
  • set up a long-lived feature branch and/or split this PR into smaller ones for easier reviews (@joshLong145)

serde_json = "1.0"
serde_bare = "0.5"
serde-wasm-bindgen = "0.5"
bls12_381_plus = { version = "=0.8.9" }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not needed since you're including blsful. Use blsful::inner_types and it gets you the same.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree.

I added this to fix the crate to an older version, which would fix a compile error. IIRC, I got the error when using the blsful crate from Git, but it doesn't occur at all using versions published to crates.io. Removing.


struct Bls<C>(C);

// We have to create this trait because G1/G2 implementations do not use a common trait for all the methods we need.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if we can go Uint8Array -> Vec<u8> -> {struct} via serde and these traits. A TryFrom<Vec<u8>> would fit better, or we could change the overall approach to rely on serde for JS communication everywhere.
Happy to discuss this today!


#[derive(Tsify, Deserialize)]
#[tsify(from_wasm_abi)]
pub enum EcdsaVariant {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing P384

Ok(k)
}

fn derive_key_inner(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happily! See #341 (comment)

Ok(k)
}

fn sum_of_products_pippenger(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we copying code here? All this is done for you in https://github.com/LIT-Protocol/hd-keys-curves/blob/main/src/lib.rs#L23

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code was moved*, not copied, from https://github.com/LIT-Protocol/lit-ecdsa-wasm-combine/blob/main/src/combiners/hd_ecdsa/mod.rs#L53, I didn't know it was also available in another crate.

[*] the idea is having only one crate that exposes the crypto functionality to JS via WASM, and have it be part of the SDK. Ideally, this crate would not actually implement any cryptography itself, but only delegate to other crates making sure the API is JS-friendly and type-safe.

So indeed this piece of code lives much better in a different crate, I'll happily work on delegating this to hd-keys-curves!


#[derive(Tsify, Deserialize)]
#[tsify(from_wasm_abi)]
pub enum FrostVariant {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again why are we copying code from lit-frost? The point of a crate is that its reusable.

@Ansonhkg Ansonhkg mentioned this pull request Feb 14, 2024
5 tasks
@cairomassimo cairomassimo force-pushed the feature/lit-2382-js-sdk-refactor-crypto-and-other-wasm-based-modules branch from 54f422d to c5a9385 Compare February 15, 2024 11:27
@Ansonhkg Ansonhkg changed the base branch from master to staging/3.1.5 February 15, 2024 18:53
The `blstrs_plus` implementation of BLS curves would crash with a
`panic_misaligned_pointer_dereference`.
That implementation was wrongly selected over `bls12_381_plus`
after adding dependency `hd-keys-curves`, which implied
`blsful/default` -> `blsful/blst` -> `blsful/blstrs_plus`.
@Ansonhkg Ansonhkg mentioned this pull request Feb 19, 2024
5 tasks
@Ansonhkg Ansonhkg deleted the branch staging/3.1.5 February 19, 2024 16:09
@Ansonhkg Ansonhkg closed this Feb 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants