Open davidp94 opened 5 years ago
I like the idea, and we'd welcome any contributions to make that happen! However, I think there are a few challenges, e.g.:
pairing
, which is currently not being actively developed. (Might need to fork it?)Vec
s, so we'd need to find a different solution for those.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.
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.
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```
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.
@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.
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!
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.
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 https://github.com/zkcrypto/pairing/issues/111.
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
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 )