Skip to content
Snippets Groups Projects
Forked from monero-project / CCS Proposals
372 commits behind the upstream repository.
hinto-2023-nov.md 6.47 KiB
layout: wip
title: hinto-janai full-time work on Cuprate (3 months)
author: hinto-janai
date: Nov 6, 2023
amount: 153
milestones:
  - name: Internals
    funds: 33% (51)
    done: 13 March 2024
    status: finished
  - name: API
    funds: 33% (51)
    done:
    status: unfinished
  - name: Integration + 3 months of work
    funds: 33% (51)
    done:
    status: unfinished
payouts:
  - date: 9 April 2024
    amount: 51
  - date:
    amount:
  - date:
    amount:

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:

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):