Git-Mirrors/monero-ccs-proposals
1
0
Fork 0
mirror of https://repo.getmonero.org/monero-project/ccs-proposals.git synced 2024-10-01 01:35:55 -04:00
Code Issues Packages Projects Releases Wiki Activity
e13e62ea93
monero-ccs-proposals/boog_2_months_cuprate.md
luigi1111 f466ee11f7 Update boog_2_months_cuprate.md - done
2024-01-26 21:13:37 +00:00

4.4 KiB
Raw Blame History

layout title author date amount milestones payouts
cp Boog900 full time work on Cuprate, the Rust Monero node (2 months) Boog900 August 03, 2023 130
name funds done status
Consensus rules up to RingCT 53 XMR 27 October 2023 finished
name funds done status
All Consensus rules up to present 53 XMR 10 January 2024 finished
name funds done status
Consensus Rules document 24 XMR 10 January 2024 finished
date amount
5 November 2023 53
date amount
26 January 2024 77

Cuprate is a WIP Rust Monero node that SyntheticBird45 started back in Feburary, I joined the project not long after that, but sadly me and SyntheticBird have not been able to spend much time on it. Even more sad is that recently SyntheticBird decided to stop working on Cuprate for personal reasons that I will not get into here.

This CCS is to support me working on Cuprate full time for the next 2 months, In this time I will complete the transaction/ block verification. While doing this, I will also create a consensus rules document, which will document all of Moneros consensus rules from genesis to the current rules.

Why

Currently, Monero only has one node written in C/C++, many would see this as an issue. Having only one implementation makes us more vulnerable to implementation bugs, having another node will help us to spot and fix these issues.

monerods code is also a bit of a mess, as many devs who have worked on it would agree. Cuprate is a fresh start and is built with modularity in mind which will lead to a cleaner and easier to understand codebase.

Having a consensus rules document will make it easier for developers to build software to interact with Monero. It will also make it easier to spot potential issues with consensus rules.

Who

I am Boog900, the current, and now solo, maintainer of Cuprate.

Design

For an overview of the design see here

What Has Been Done

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

There is still a lot to do here, but monero-serai has already done verifying for bulletproofs(+) and CLSAG. My PR to monero-serai also contained an unverified MLSAG verify function and a WIP Borromean range proofs function.

Database

The initial database abstraction is complete, and we have defined the tables (we have copied monerod for the moment). We have also created the methods to add and get blocks and transactions from the database.

Still to-do: We need to investigate the database schema for optimizations.

Tasks

We need to implement/ get ready for production verifying for MLSAG, borromean range proofs and V1 ring signatures, there are other checks we need to do, but these are the big ones. As Monero does not have a protocol document, we will have to go through monerod to find every check it performs and do them in Cuprate.

Cuprates consensus checks will be grouped together in a single location, so they are clear and not spread around the codebase, they will also reference the consensus rules document at every check. If some checks are done elsewhere, for example some are done at deserialization, we will either duplicate the check or, if its expensive, we will put a comment referencing the check and the consensus rules in the single location.

We also need to create bindings for Moneros legacy CryptoNight POW algorithms and select a Random-X binding. There is a Rust Random-X implementation, which we plan to implement as an option, but we won't enforce it as it lacks review/ usage.

As our P2P/ database code still needs some work, we will be using monerods RPC interface to test the code.

All code produced for this CCS will be licensed under MIT.

Milestones

  1. All Consensus rules up to RCT
    Implement verification for transactions and blocks before RCT.
  2. All Consensus rules up to present
    Implement verification for all transactions and blocks.
  3. Creation of the consensus rules document

Funding

I am asking for $45/hr for 50hrs/week for 2 months at $148/XMR this gives 130 XMR