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

Make it no-std #67

Open
davidp94 opened this issue Dec 6, 2018 · 10 comments
Open

Make it no-std #67

davidp94 opened this issue Dec 6, 2018 · 10 comments

Comments

@davidp94
Copy link

davidp94 commented Dec 6, 2018

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

afck commented Dec 6, 2018

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

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.

@gitcoinbot
Copy link

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

ibalajiarun commented Dec 4, 2019

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

afck commented Dec 4, 2019

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

ibalajiarun commented Dec 5, 2019

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

afck commented Dec 5, 2019

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

gitcoinbot commented Feb 16, 2020

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

afck commented Feb 18, 2020

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

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

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

No branches or pull requests

4 participants