diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md new file mode 100644 index 0000000..e01ca94 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -0,0 +1,25 @@ +--- +name: Bug Report +about: Create a report to help us squash bugs! + +--- + +∂ + +## Summary of Bug + + + +## Version + + + +## Steps to Reproduce + + + + diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md new file mode 100644 index 0000000..7d5ed5d --- /dev/null +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -0,0 +1,35 @@ +--- +name: Feature Request +about: Create a proposal to request a feature + +--- + + + +## Summary + + + +## Problem Definition + + + +## Proposal + + + +____ + +#### For Admin Use + +- [ ] Not duplicate issue +- [ ] Appropriate labels applied +- [ ] Appropriate contributors tagged +- [ ] Contributor assigned/self-assigned diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md new file mode 100644 index 0000000..dcb2f6b --- /dev/null +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -0,0 +1,26 @@ + + +## Description + + + +closes: #XXXX + +--- + +Before we can merge this PR, please make sure that all the following items have been +checked off. If any of the checklist items are not applicable, please leave them but +write a little note why. + +- [ ] Targeted PR against correct branch (main) +- [ ] Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work. +- [ ] Wrote unit tests +- [ ] Updated relevant documentation in the code +- [ ] Added a relevant changelog entry to the `Pending` section in `CHANGELOG.md` +- [ ] Re-reviewed `Files changed` in the Github PR explorer diff --git a/CHANGELOG.md b/CHANGELOG.md new file mode 100644 index 0000000..4b22a95 --- /dev/null +++ b/CHANGELOG.md @@ -0,0 +1,29 @@ +## Pending + +### Breaking changes +- #12 Make FpVar's ToBitsGadget output constant length bit vectors. + +### Features + + +### Improvements +- #5 Speedup BLS-12 pairing +- #13 Add ToConstraintFieldGadget to ProjectiveVar +- #15, #16 Allow cs to be none when converting a montgomery point into a twisted edwards point +- #20 Add conditional select gadget to Uints +- #21 Add Uint128 +- #22 Reduce density of `three_bit_cond_neg_lookup` +- #23 Reduce allocations in Uints +- #33 Speedup scalar multiplication by a constant +- #35 Construct a FpVar from bits +- #36 ImplementToConstraintFieldGadget for `Vec` + +### Bug fixes +- #8 Fix bug in three_bit_cond_neg_lookup when using a constant lookup bit +- #9 Fix bug in short weierstrass projective curve point's to_affine method +- #29 Fix `to_non_unique_bytes` for `BLS12::G1Prepared` +- #34 Fix `mul_by_inverse` for constants + +## v0.1.0 + +Initial release \ No newline at end of file diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..d656528 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,65 @@ +# Contributing + +Thank you for considering making contributions to `arkworks-rs/r1cs-std`! + +Contributing to this repo can be done in several forms, such as participating in discussion or proposing code changes. +To ensure a smooth workflow for all contributors, the following general procedure for contributing has been established: + +1) Either open or find an issue you'd like to help with +2) Participate in thoughtful discussion on that issue +3) If you would like to contribute: + * If the issue is a feature proposal, ensure that the proposal has been accepted + * Ensure that nobody else has already begun working on this issue. + If they have, please try to contact them to collaborate + * If nobody has been assigned for the issue and you would like to work on it, make a comment on the issue to inform the community of your intentions to begin work. (So we can avoid duplication of efforts) + * We suggest using standard Github best practices for contributing: fork the repo, branch from the HEAD of `main`, make some commits on your branch, and submit a PR from the branch to `main`. + More detail on this is below + * Be sure to include a relevant change log entry in the Pending section of CHANGELOG.md (see file for log format) + * If the change is breaking, we may add migration instructions. + +Note that for very small or clear problems (such as typos), or well isolated improvements, it is not required to an open issue to submit a PR. +But be aware that for more complex problems/features touching multiple parts of the codebase, if a PR is opened before an adequate design discussion has taken place in a github issue, that PR runs a larger likelihood of being rejected. + +Looking for a good place to start contributing? How about checking out some good first issues + +## Branch Structure + +`r1cs-std` has its default branch as `main`, which is where PRs are merged into. Releases will be periodically made, on no set schedule. +All other branches should be assumed to be miscellaneous feature development branches. + +All downstream users of the library should be using tagged versions of the library pulled from cargo. + +## How to work on a fork +Please skip this section if you're familiar with contributing to opensource github projects. + +First fork the repo from the github UI, and clone it locally. +Then in the repo, you want to add the repo you forked from as a new remote. You do this as: +```bash +git remote add upstream git@github.com:arkworks-rs/r1cs-std.git +``` + +Then the way you make code contributions is to first think of a branch name that describes your change. +Then do the following: +```bash +git checkout main +git pull upstream main +git checkout -b $NEW_BRANCH_NAME +``` +and then work as normal on that branch, and pull request to upstream master when you're done =) + +## Updating documentation + +All PRs should aim to leave the code more documented than it started with. +Please don't assume that its easy to infer what the code is doing, +as that is almost always not the case for these complex protocols. +(Even when you understand the paper!) + +Its often very useful to describe what is the high level view of what a code block is doing, +and either refer to the relevant section of a paper or include a short proof/argument for why it makes sense before the actual logic. + +## Performance improvements + +All performance improvements should be accompanied with benchmarks improving, or otherwise have it be clear that things have improved. +For some areas of the codebase, performance roughly follows the number of field multiplications, but there are also many areas where +hard to predict low level system effects such as cache locality and superscalar operations become important for performance. +Thus performance can often become very non-intuitive / diverge from minimizing the number of arithmetic operations. \ No newline at end of file