May 5, 2024
264 XMR
4 contributors
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. 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 layer 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, specifically on the database implementation.
This CCS will fund part of a larger effort to create an alternative Monero node implementation (among other things).
As such, things will initially be slow-going as groundwork is laid. This CCS specifically may not directly benefit monero-core immediately, yet it's work that must be completed such that Cuprate can benefit monero-core (and Monero) in the future.
I'm hinto-janai.
Past CCS: https://ccs.getmonero.org/proposals/gupax.html.
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 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 easy hot-swapping of databases to test for the various operations Cuprate will be performing. In the end, a single database will be selected after testing, although the layer will continue to exist.
The database implementations in mind (for now) include:
Both of these will be forked and maintained by Cuprate as there are monerod-specific things that must be added (e.g output lookup using sub-keys).
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):
get_info)./cuprated --option)Most likely, the RPC server would be the next thing I would be working on.
And there are things that are planned, but for the very distant future:
C/C++ <-> Rust bindings 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 nicemonerod)These points are laid out to showcase what else must/could be done for Cuprate to reach some level of parity with monerod.
Cuprate has an advantage in that it has an 8+ year old codebase as reference - although we are starting with a blank canvas, we have a finished painting next to us, displaying all the very good, okay, and not-so-good parts.
As such, we can focus on things other than making it work, notably: documentation, maintenance, and correctness.
Other than documenting the Monero protocol itself, we plan to write documentation for internal subsystems such that future Cuprate contributors/maintainers will be able to pick up easily where we left off. What this means for me and this CCS is that I'll be documenting how this database "layer" fits in with the rest of Cuprate, and answer all the "what does this do?", "how does this work?", "why was it done like this?" questions. If I were to continue working on Cuprate past this CCS, i.e. the RPC server, all RPC types would also be documented (and the internals as well) - the same goes for any future subsystems.
Other notable projects following this pattern: Tor, Bitcoin, Ethereum, Zcash.
I propose to work for 44 hours/week for 3 months.
By the end of this proposal, Cuprate will have a working database. I believe 3 months is enough time to create and refine an implementation enough for usage.
It is hard to separate large single implementations like this cleanly into goals/timeframes as usually many things get worked on at any given moment - although, there are 3 bigger milestones this CCS has:
Milestone 3 is only to be paid out upon:
This means if the database takes 428~ hours to complete, I will continue to work for 100~ more hours (most likely on the things listed in Future) to complete milestone 3.
View community discussion, comments, and proposal updates on GitLab
November 6, 2023
153 XMR
7 contributors
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. 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 layer 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, specifically on the database implementation.
This CCS will fund part of a larger effort to create an alternative Monero node implementation (among other things).
As such, things will initially be slow-going as groundwork is laid. This CCS specifically may not directly benefit monero-core immediately, yet it's work that must be completed such that Cuprate can benefit monero-core (and Monero) in the future.
I'm hinto-janai.
Past CCS: https://ccs.getmonero.org/proposals/gupax.html.
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 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 easy hot-swapping of databases to test for the various operations Cuprate will be performing. In the end, a single database will be selected after testing, although the layer will continue to exist.
The database implementations in mind (for now) include:
Both of these will be forked and maintained by Cuprate as there are monerod-specific things that must be added (e.g output lookup using sub-keys).
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):
get_info)./cuprated --option)Most likely, the RPC server would be the next thing I would be working on.
And there are things that are planned, but for the very distant future:
C/C++ <-> Rust bindings 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 nicemonerod)These points are laid out to showcase what else must/could be done for Cuprate to reach some level of parity with monerod.
Cuprate has an advantage in that it has an 8+ year old codebase as reference - although we are starting with a blank canvas, we have a finished painting next to us, displaying all the very good, okay, and not-so-good parts.
As such, we can focus on things other than making it work, notably: documentation, maintenance, and correctness.
Other than documenting the Monero protocol itself, we plan to write documentation for internal subsystems such that future Cuprate contributors/maintainers will be able to pick up easily where we left off. What this means for me and this CCS is that I'll be documenting how this database "layer" fits in with the rest of Cuprate, and answer all the "what does this do?", "how does this work?", "why was it done like this?" questions. If I were to continue working on Cuprate past this CCS, i.e. the RPC server, all RPC types would also be documented (and the internals as well) - the same goes for any future subsystems.
Other notable projects following this pattern: Tor, Bitcoin, Ethereum, Zcash.
I propose to work for 44 hours/week for 3 months.
By the end of this proposal, Cuprate will have a working database. I believe 3 months is enough time to create and refine an implementation enough for usage.
It is hard to separate large single implementations like this cleanly into goals/timeframes as usually many things get worked on at any given moment - although, there are 3 bigger milestones this CCS has:
Milestone 3 is only to be paid out upon:
This means if the database takes 428~ hours to complete, I will continue to work for 100~ more hours (most likely on the things listed in Future) to complete milestone 3.
View community discussion, comments, and proposal updates on GitLab
To be paid: 33% (51)
Completion date: 13 March 2024
To be paid: 33% (51)
Completion date: 5 May 2024
To be paid: 33% (51)
Completion date: 5 May 2024
Funds Awarded: 51
Date: 9 April 2024
Funds Awarded: 102
Date: 14 May 2024