The contest will open for submissions Monday, April 28th at 17:00 UTC, and we will stop accepting submissions Monday, June 30th at 17:00 UTC!
The goal of this contest is to provide optimized implementations of
helioselene
and
ec-divisors.
While any method of achieving faster performance will be accepted, the
following scopes of work are highlighted.
helioselene uses
crypto-bigint for its
arithmetic. Replacing its field arithmetic with a tailored implementation will
likely provide significant savings. The prime used for the field introduced by
the Helios/Selene cycle is a Crandall prime with fast reduction algorithms
available accordingly.
ec-divisors performs polynomial multiplications/divisions which are quite
expensive without an FFT. While we can't assume it'll be used with curves which
are FFT friendly, it would be valid to define a trait to specify a FFT-friendly
multiplicative group to use with a curve (so long as such groups are feasible
to find for arbitrary curves). This would enable implementing
ECFFT, reducing the computational
complexity of ec-divisors.
- Implementations must run in constant time.
Implementations will be reviewed for a variety of non-constant-time operations. All branches and memory access must be constant with regards to the secrets operated over. We do assume shifts and multiplications execute in constant time.
Additionally, code will be run through
wasm-cycles to verify a
constant cycle count when compiled for wasm32v1-none. This is
incomprehensive to certain issues such as cache side-channel attacks, yet
represents an automated way to eliminate some types of non-constant-time code.
- Submissions must be written by the submitter and licensed under MIT at time of submission.
Code written by third parties must be included as a properly attributed dependency and not directly submitted. Code generated by LLMs also will not be accepted.
- Submissions must compile with both Rust stable 1.69 and 1.84.
Usage of nightly features is not allowed.
- Submissions must support targets with alloc yet not std.
wasm32v1-none is the provided example of such a target. If the
submission builds and runs on it, it meets this criteria.
This requirement does prevent the usage of threads which are expected to be used at a higher level by calling code.
- Submissions must not have platform-specific code.
While various intrinsics would produce the best performance on their respective targets, the point of this competition is to create baseline libraries usable regardless of context.
-
Submissions must not include any unsafe code.
-
Dependencies must be pre-approved.
Please create an issue requesting to use a dependency, or contact @jberman:monero.social on Matrix. We will approve dependencies on a case-by-case basis.
-
The total maximum source code size is 1 million bytes.
-
Submissions which rely on tables/caches built at time of compilation must contain code to deterministically reproduce those tables. This code must be able to be called at runtime.
This reproduction code is counted towards the total code size. If a table/cache cannot be built at compile time, then the time to build the table will be included in the total runtime, amortized over 10 thousand calls.
- Submissions must pass the provided test suite and run with the provided benchmark.
Modifications to the test suite and benchmark are not allowed, except for
adding/extended trait implementations for elliptic curves tested with the
ec-divisors lib.
- Submissions must score at least 20% better than the reference.
This is the baseline performance improvement target intended to disqualify trivial submissions.
- Anonymous submissions are allowed.
Submissions have a joint score based on:
- Their benchmarks while running on a machine with specs listed below
- Their cycle count from
wasm-cycles
Machine specs (we may use a different machine with similar specs):
- AMD Ryzen 5600G (your code must not take advantage of the integrated graphics)
- Debian 12
- 16GB RAM
Submissions which allocate more than 96 MB of WASM pages will have their score decreased by 10% for each additional 32 MB allocated (allocating 96.1 MB will face a 10% penalty and allocating 128.1 MB will face a 20% penalty).
We reserve the right to select a winner based on our discretion, and rule out submissions for reasons we may not have identified above. For example, if the fastest code has issues we did not identify above, we may select the 2nd fastest code. We aim to ship the winning code in Monero.
The judges will be:
- @j-berman
- @jeffro256
Judges provide a good-faith promise that we will not participate as contestants in the competition.
We may add judges in the future at our discretion.
If you have any questions, do not hesitate to ask in IRC/Matrix #monero-dev, or create an issue.
The best submission for an optimized helioselene will be awarded 100 XMR.
The best solution for an optimized ec-divisors will be awarded 250 XMR.
For helioselene, visit helioselene-contest.
For ec-divisors, visit ec-divisors-contest.
-
Create a private fork of this repository.
-
Submit a PR to your private fork that includes your code.
-
Invite the judges (@j-berman and @jeffro256) as collaborators to the repository.
We will acknowledge receipt of your submission via a "thumbs up" reaction to your PR.
You may also submit a patch to @jberman:monero.social on Matrix.