hinto-janai - full-time work on Cuprate (3 months)
What
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.
Benefitting Monero
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.
Who
I'm hinto-janai.
Past CCS: https://ccs.getmonero.org/proposals/gupax.html.
Design
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:
- LMDB (via heed)
- sanakirja (a database similar and originally based off LMDB)
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.
Future
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 server (e.g.
get_info
) - Transaction-pool related (e.g. Dandelion++)
- Application interface linking everything together (e.g.
./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:
- ZMQ support
- Tor/i2p support: Tor is quite feasible today, i2p less so
- RandomX: Currently, there exists multiple (quite rough)
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 nice - CryptoNight: Same as RandomX but less important as this is only used for legacy purposes
- P2P encryption (preferably compatible with the proposal for
monerod
)
These points are laid out to showcase what else must/could be done for Cuprate to reach some level of parity with monerod
.
Why
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.
Proposal
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:
- Internals: implementing the database and functions themselves
- API: cleanup of the interface and many other miscellaneous things for external usage
- Integration: slotting the database into Cuprate, and at least 3 months of work
Milestone 3 is only to be paid out upon:
- A complete database has been integrated into Cuprate
- 3 months of work has been done
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.
- Hours: 528
- Rate: $45 USD/hour
- XMR: $155 (20-day EMA, Kraken, 2024/01/15)
- Total: 153 XMR
Merge request reports
Activity
Just commenting to confirm my approval of this proposal, having an extra person working on Cuprate will really speed up development.
To recap from my current CCS what Cuprate currently has:
P2P
The peer-to-peer code is mostly complete; I have implemented levin headers, the epee binary format and all p2p messages. I have also done the p2p address book, individual peer request routing, handshakes and pruning calculations.
Blockchain Data
I made a PR to monero-serai adding decoding/encoding/hashing of legacy transactions and blocks so this is complete.
Consensus Checks
I have implemented all consensus checks for blocks and version 1 (pre-RCT) transactions. Version 2 transactions are currently being worked on with a PR to monero-serai adding/ fixing verification for MLSAG and Borromean signatures. monero-serai already supports verification of bulletproofs(+) and CLSAGs.
Database
I intend to redo the database, not to discredit what SyntheticBird45 has done but because I think we could redefine the traits in a simpler way which will have a cascading effect through the database crate so it makes more sense for a fresh start, plus they themselves were working on a big change to the database before they left which never got merged.
Currently the blockchain scanning binary is using an RPC load balancer in place of a database with some data that can't be retrieved over RPC but needed for consensus checks being stored in a cache. An actual database would be able slot into the consensus crate with no changes to the crate.
Edited by Boog 900Not much interaction on the gitlabs for this proposal (although it was a needle in a haystack for most of its life) so lets change that, and look closer at this proposal / attempt some kind of conflict/resolution.
Only people who care about this proposal are 1) re-write it in rust people 2) other cuprate devs and 3) kayabanerve (who wants a rust node that his serai dex can fall back on) / obtain pull requests from cuprate devs.
There are no verifiable milestones only time frames listed with no assurances of the work being reviewed.
boog's proposal had specific goals/milestones. each of which would be directly beneficial to the monero project.
A 'monero-node-in-rust' has none? barely any? a little? support from -dev who are in the trenches working on the painting that cuprate can place tracing paper over, clinging for any help they can get. -devs lack of support for a rust node seen in the comments here.
What are we going to get for 144XMR here? what % of your hours are directly useful to the monero core implementation?
"Future" .. "i plan to" .. "the distant future", why are you writing fairy tales? can we not simply discuss what people would be getting by donating to this proposal?
- re-write it in rust people
That's what the project is so literally every person who supports this can be put in that category even if their reason isn't blind "rewrite everything in Rust".
boog's proposal had specific goals/milestones. each of which would be directly beneficial to the monero project.
The bulk of the CCS was beneficial because of the potential to find bugs, 106/130 XMR was to re-write the rules in Rust, whose to say hinto wont find bugs working on the database? although I admit hinto will not need to go through monerod as meticulously as I had to for the consensus rules but the potential to find bugs in monerod is still there.
dev who are in the trenches working on the painting that cuprate can place tracing paper over
This is not a fair comment, but I don't think you meant it how I'm interpreting it, Cuprate is not just a line for line rewrite it is a new design. The benefits of this are already visible, the
scan_chain
binary I wrote for my CCS which downloads blocks/ txs over public nodes RPC and verifies them with outputs which are also got over RPC is faster than monerod doing full verification of blocks, getting outputs locally. Obviously this is not Cuprate but it is an indication that improvements can be made.-devs lack of support for a rust node seen in the comments here.
those are year old comments on a very bad proposal.
What are we going to get for 144XMR here? what % of your hours are directly useful to the monero core implementation?
Why does this proposal need to directly benefit monero-core when many don't need to meet this requirement. What you are getting for 144XMR is a database which Cuprate will use to store the blockchain, this database will be accessible as a crate (library) which would allow easier investigation of a database than what monerod currently offers.
Yes sadly this doesn't really benefit monero-core right now but it will benefit Monero.
Personally I see Monero having another independent implementation as being highly valuable and important for the future of Monero itself. My views on the project are exactly the same as previously commented.
A 'monero-node-in-rust' has none? barely any? a little? support from
The specific comments were related to the unrealistic timeframe expectations, so I think claiming that is wrong, given other comments to boog's recent proposal. Cuprate needs multiple experienced people working on it consistently to succeed and I think funding more experienced developers is a wise choice, as long as we have a clear process which can be reviewed and evaluated.
I do agree however that the proposal can be improved with some clear milestones.
Edited by yamabiiko
Hi, I support the merging of this CCS. hinto-janai has demonstrated strong competence and skills. Having another person work alongside Boog900 on this project will be beneficial in getting Cuprate up and running in the near future. For having worked on Cuprate and therefore monerod database myself, I can attest that the amount of work is tremendous for only one dev. And I've confidence into hinto-janai at giving himself to the task
mentioned in merge request !431 (merged)
For visibility: https://libera.monerologs.net/monero-community/20240122#c323962
luigi1112: I would like to have some opinions from other devs working on core not just community members
luigi1111: Although we kinda agreed already funding an alt impl was fine, this is mostly about cost I guessEdited by plowsoffThe labour rate per hour is reasonable for someone who can read and write C++ and Rust. Then, is up to three months reasonable for porting the database C++ code to Rust? I'm not a real programmer, so I'm not sure. But evidence suggests the complexity of the task is high. A snippet of a recent Seraphis meeting log:
<dangerousfreedom> I agree and look forward to see someone working on writing things on a proto blockchain instead of having it in memory <jeffro256> I some experience with modifying/working with the LMDB code in the codebase. Anyone else ? <dangerousfreedom> That's great jeffro256 :D <rbrunner7> I always thought that stuff looks mighty strage and shied away <rbrunner7> *strange <jeffro256> The LMDB API can be very intimidating at times <dangerousfreedom> I would like to learn and help also. Let's see how things go <jeffro256> best thing you can do to learn is to 1) understand what the methods of BlockchainLMDB are meant to acheive and then 2) study how that class uses LMDB to accomplish that <dangerousfreedom> +1 <jeffro256> Theres a lot of common patterns used <jeffro256> Then you can get a feel for how the cursors work <jeffro256> And which flags mean what <rbrunner7> Yeah, sometimes you just have to grok the overall approach, and then pieces fall into place
A lack of documentation about Monero's LMDB API can slow down development on that part of the C++ code. AFAIK, most of the database contents are undocumented serialized C++ objects: https://monero.stackexchange.com/questions/10919/understanding-the-structure-of-moneros-lmdb-and-how-explore-its-contents-using
Maybe it is a little late, But we did have documented the monerod database at the time. You can find it on this repository: https://github.com/Cuprate/old_book/tree/main/src/monero/database
mentioned in commit b3793ee9
Milestone 1
Progress is going as expected, currently on day 39.
cuprate_database
's main "base" component is complete.Around 4 databases were tested with during this time:
- LMDB
- MDBX
- sanakirja
- redb
In the end, LMDB and
redb
were chosen.These are some extremely unrealistic synthetic benchmarks of the 2 database backends that are currently implemented,
LMDB
(viaheed
) andredb
.- Measured in seconds
- Single threaded
-
safe
= sync to disk per transaction -
fast
= never forcefully sync to disk (until the end) - Iterations = 5,000,000
function LMDB (safe) redb (safe) LMDB (fast) redb (fast) tx_ro 0.208 0.294 0.216 0.295 tx_rw 0.153 16.08 0.153 2.635 open_db_ro 0.148 0.773 0.150 0.757 open_db_rw 0.149 1.319 0.151 1.328 put 2.714 6.636 2.722 6.603 get 1.936 2.892 1.906 2.924 get (random) 2.477 3.285 2.472 3.259 get_range 0.053 0.268 0.053 0.264 delete 2.814 11.18 2.838 11.11 put 2.698 7.016 2.669 8.176 delete (random) 3.772 12.77 3.747 13.62 This data should not be taken too seriously as the tests are very unrealistic and nothing has been optimized; it's just to get a sense of things. Testing code here.
The internal documentation (
cargo doc cuprate_database
) is complete, and the mainREADME.md
documentation is waiting on other parts to be implemented.The other major components left to be implemented for external usage are:
- The database thread-pool system (multiple readers, request/response message passing)
- Monero-specific data types & operations (e.g.
Block
,get_block()
)
and of course their documentation and tests.
PRs
Cuprate (database):
- https://github.com/Cuprate/cuprate/pull/35
- https://github.com/Cuprate/cuprate/pull/60
- https://github.com/Cuprate/cuprate/pull/61
- https://github.com/Cuprate/cuprate/pull/62
- https://github.com/Cuprate/cuprate/pull/68
- https://github.com/Cuprate/cuprate/pull/77
- https://github.com/Cuprate/cuprate/pull/79
- https://github.com/Cuprate/cuprate/pull/80
- https://github.com/Cuprate/cuprate/pull/81
- https://github.com/Cuprate/cuprate/pull/85
Cuprate (misc):
- https://github.com/Cuprate/cuprate/pull/32
- https://github.com/Cuprate/cuprate/pull/34
- https://github.com/Cuprate/cuprate/pull/36
- https://github.com/Cuprate/cuprate/pull/44
- https://github.com/Cuprate/cuprate/pull/45
- https://github.com/Cuprate/cuprate/pull/50
- https://github.com/Cuprate/cuprate/pull/52
- https://github.com/Cuprate/cuprate/pull/55
- https://github.com/Cuprate/cuprate/pull/56
- https://github.com/Cuprate/cuprate/pull/64
- https://github.com/Cuprate/cuprate/pull/67
- https://github.com/Cuprate/cuprate/pull/70
- https://github.com/Cuprate/cuprate/pull/67
Upstream:
Payout
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Key: https://github.com/Cuprate/cuprate/blob/main/misc/gpg_keys/hinto-janai.asc Asking for milestone 1's payout for: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/422 to the following address: 44hintoFpuo3ugKfcqJvh5BmrsTRpnTasJmetKC4VXCt6QDtbHVuixdTtsm6Ptp7Y8haXnJ6j8Gj2dra8CKy5ewz7Vi9CYW -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQxxRRar6Wo3xwdsqbUfOBfoXWkmQUCZfJN7QAKCRDUfOBfoXWk mbu7AP4ivj+txl119+ZAPTDe2g17kPRJa2PqcFOmktzLG+FXBwEAz+WRkWG/84iK Ge+G+lQLq4duiBNg23Tii5txRab2wAk= =wvF1 -----END PGP SIGNATURE-----
Edited by hintoMilestone 2 & 3
The last 2 milestones took a week longer than expected, although they are now complete:
- Monero-specific database operations; AKA the
ops
- Database thread-pool system + asynchronous request/response API for Cuprate; AKA the
service
The majority of the code was written in these PRs:
ops
:service
:All PRs since last update (20, all within
Cuprate/cuprate
):cuprate_database
's design document is also complete, read here:database/README.md
.The user documentation was also updated to reflect all changes - I wish I could link to this work here but it must be generated with tooling; there are instructions in the
README.md
here.The introduction at least can be read (in an un-formatted way) here, which looks like this when generated:
Payout
I am requesting the payout of milestone 2 and 3 (102 XMR) to the previous address posted.
- Monero-specific database operations; AKA the
mentioned in merge request !455 (closed)
mentioned in merge request !456 (merged)
mentioned in merge request !469 (merged)
mentioned in merge request !518 (merged)
mentioned in merge request !539 (closed)
mentioned in merge request !543