Make it no-std

[davidp94]

Would it be possible to make it no-std so it could run basically in an enclave (for example https://github.com/baidu/rust-sgx-sdk )

[afck]

I like the idea, and we'd welcome any contributions to make that happen!
However, I think there are a few challenges, e.g.:

• First we'd need to make sure all our dependencies support no-std, in particular pairing, which is currently not being actively developed. (Might need to fork it?)
• Our polynomials use Vecs, so we'd need to find a different solution for those.
• We have plans to do some special allocation for page locking (Efficiently allocate memory for secrets in locked pages. #42). That should probably simply be disabled for no-std.

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

This issue now has a funding of 250.0 DAI (250.0 USD @ $1.0/DAI) attached to it.

• If you would like to work on this issue you can 'start work' on the Gitcoin Issue Details page.
• Want to chip in? Add your own contribution here.
• Questions? Checkout Gitcoin Help or the Gitcoin Slack
• $87,683.52 more funded OSS Work available on the Gitcoin Issue Explorer

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

Workers have applied to start work.

These users each claimed they can complete the work by 11 months, 1 week from now.
Please review their action plans below:

1) iamonuwa has applied to start work (Funders only: approve worker | reject worker).

Am available to fix this with the team. I write rust and understand the requirements of the task

Learn more on the Gitcoin Issue Details page.

[ibalajiarun]

I am working on making this library work with SGX. I am trying to get rid of rand04_compat dependency and just use rand. I tried simply calling gen() instead of gen04() but I got the following error. Anyone with the idea on what gen04 does that gen doesn't? I tried the docs, but they dint help me much.

error[E0277]: the trait bound `rand::distributions::Standard: rand::distributions::Distribution<pairing::bls12_381::ec::g2::G2>` is not satisfied
   --> src/lib.rs:587:34
    |
587 |     ChaChaRng::from_seed(digest).gen()
    |                                  ^^^ the trait `rand::distributions::Distribution<pairing::bls12_381::ec::g2::G2>` is not implemented for `rand::distributions::Standard`
    |
    = help: the following implementations were found:
              <rand::distributions::Standard as rand::distributions::Distribution<()>>
              <rand::distributions::Standard as rand::distributions::Distribution<(A, B)>>
              <rand::distributions::Standard as rand::distributions::Distribution<(A, B, C)>>
              <rand::distributions::Standard as rand::distributions::Distribution<(A, B, C, D)>>
            and 66 others```

[afck]

The problem is that pairing 0.14 uses rand 0.4. If you use gen() from rand 0.6 it expects its return type to implement the Distribution trait from rand 0.6, not the Distribution trait from rand 0.4, which is considered a different trait with the same name.

I hope we'll be able to remove rand04_compat once we upgrade to a newer pairing version.

For no-std, we'll also need our dependencies (e.g. pairing and probably bls12_381) to support that.

[ibalajiarun]

@afck thanks for the input! mesalock linux seems to be doing some work on making SGX version's of some rust libraries. I was able to replace most of them except pairing and rand04_compat. I guess I first need to fork pairing and get it to be compatible with SGX.

[afck]

Yes, once pairing supports no-std, I think it should be easy for threshold_crypto.
I'd open an issue with pairing first, though: They are very responsive, and maybe there's no need for a fork at all!

[gitcoinbot]

Issue Status: 1. Open 2. Cancelled

---

Workers have applied to start work.

These users each claimed they can complete the work by 2 months, 4 weeks from now.
Please review their action plans below:

1) jakender has applied to start work (Funders only: approve worker | reject worker).

Firstly, I would remove all usages of the Rust standard library from the repository.

Then, I would write a custom implementation of the standard library without using any platform specific APIs so that it wouldn’t be tied to any platform.

After that, I would implement all the functions, structs, struct methods, and modules and packages with the custom standard library, replacing the old code.

Learn more on the Gitcoin Issue Details page.

[afck]

custom implementation of the standard library

Which parts would need a custom implementation? At least alloc::vec::Vec should be usable even in a no_std environment.

The bigger problem is to make pairing no_std, and it would be great if we could avoid forking that in the long run, so I'd say this issue is blocked by zkcrypto/pairing#111.

[gitcoinbot]

Issue Status: 1. Open 2. Cancelled

---

The funding of 250.0 SAI (250.0 USD @ $1.0/SAI) attached to this issue has been cancelled by the bounty submitter

• Questions? Checkout Gitcoin Help or the Gitcoin Slack
• $73,871.27 more funded OSS Work available on the Gitcoin Issue Explorer