Cuprate is an alternative Monero node implementation, currently solely worked on by Boog900.
I've been in contact with Boog and there are many sections within Cuprate that can be worked on in parallel, currently the most pressing section is the database implementation. This work was left unfinished by SyntheticBird45 before they left the project. Boog is currently working on block downloading/verification/consensus with cobbled together database-like functions - this means an actual database implementation can be worked on in parallel without any merge conflicts, and can be cleanly slotted in once complete.
This CCS is to support me working on full-time on Cuprate for the next 3 months.
The 3-month goal is for the completion of the database "layer" layed out below with at least
The design document and active PR is here: https://github.com/Cuprate/cuprate/pull/35 and will be updated as things change.
The main goal is to create a layer that separates the underlying database (
sled, etc) and the higher-level functions that are called by the other portions of Cuprate, e.g,
get_block(). The aim here is to allow for very pain-free hot-swapping of databases to test for the specific operations Cuprate will be doing.
In the end, a single database will be selected after testing, although the layer will continue to exist. The hot-swapping ability and/or the ability to add more databases in the future remains. A key point is that there is no runtime overhead to this layer - it is just compile-time types.
The overall design is mostly from Boog900 - I am simply implementing it.
There's plenty more work to be done after the database. Boog plans on handling P2P code after his current CCS, which means I could possibly work on these things in the future (in parallel with Boog's work):
- RPC interface (e.g.
- Transaction-pool related (e.g. Dandelion++)
- Application interface linking everything together (e.g.
Most likely, the RPC interface would be the next thing I would be working on.
And there are things that are planned, but for the very distant future:
- ZMQ support
- Tor/i2p support: Tor is quite feasible today, i2p less so
- RandomX: Currently, there exists multiple (quite rough)
C/C++ <-> Rustbindings but as RandomX is in active use (and will most likely be for the foreseeable future) another implementation or more realistically, a maintained "Rust"-like shim on-top would be nice
- CryptoNight: Same as RandomX but less important as this is only used for legacy purposes
- P2P encryption (preferably compatible with the proposal for
I am already familiar with Tor's
arti and the RandomX bindings - so I could immediately start work on those (in the very distant future) after Cuprate has a minimal working product (Monero node).
I propose to work for 44 hours/week for 3 months. The proposal's milestones are broken into 3, one for each month.
If the database implementation is finished before the end of this proposal, the next tasks in
Future will be worked on - or whatever is necessary at the time for the codebase.
- Hours: 528
- Rate: $45 USD/hour
- XMR: $164 (20-day EMA, Kraken, 2023/11/06)
- Total: 144 XMR