Newer
Older
title: Boog900 full time work on Cuprate (3 months)
author: Boog900
date: January 27, 2024
amount: 190
milestones:
- name: The PeerSet + Routing methods excluding D++
funds: 54 XMR
done: 15 June 2024
status: finished
- name: D++ Routing method + Network Initialisation
funds: 54 XMR
done: 15 June 2024
status: finished
- name: The Block Downloader + Syncer
funds: 54 XMR
done: 15 June 2024
status: finished
- name: P2P Documentation
funds: 28 XMR
done: 18 July 2024
status: finished
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
---
This proposal is to continue my work on [Cuprate](https://github.com/Cuprate/cuprate), specifically I will be working on
Cuprate's P2P layer and syncing. While doing this I will also expand [monero-book](https://monero-book.cuprate.org), which I created during my last CCS,
with the P2P types, message encoding and message flows (handshakes etc).
# Who
I am [Boog900](https://github.com/Boog900), you can see my last CCS [here](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/405).
# What
As well as continuing to lead coordination of Cuprate, I will also be an active maintainer for monero-rs, during the past few months
I have been reviewing and merging PRs and have released a new version: [ v0.20.0 ](https://github.com/monero-rs/monero-rs/releases/tag/v0.20.0)
For this CCS I will be working on getting Cuprate's P2P layer into a working state.
Currently Cuprate's P2P has:
- Levin header decoding/ encoding
- Every P2P message decoding/ encoding
- Handshakes.
- Rough individual peer message routing.
- A P2P address book.
What I will be doing:
## Hardening Individual Peer Message Routing
Individual peer message routing needs to be hardened, currently we don't do any checks the data received is the data we
asked for, we should be doing these checks in the connection task before handing the message to the rest of Cuprate.
## The PeerSet
The `PeerSet` is the structure that holds all currently connect peers on a certain network, it will have methods to get
peers by direction (Inbound, Outbound) or by a custom strategy, e.g a load balancing algorithm. This structure is then
used by the different routing methods.
## All The Routing Methods
The routing methods are how the rest of Cuprates interact with the P2P network. The goal is to have there be one end point
that the rest of Cuprate can send requests to. This end point will need to be made up of multiple `tower::Services` for the different
routing methods (broadcast to all, etc).
I will also be creating the Dandelion++ routing method, which will handle keeping the current d++ state, selecting out peers to route to and
keeping track of stem routes. It won't handle all of D++ as that requires knowledge of the tx-pool, but it will handle all the routing
side.
## Network Initialisation
I will make the network initialisation code, to start the network and return the end point that requests can be sent to.
## The Block Downloader
The block downloader will be a `futures::Stream` that will handle finding the chain with the most PoW from the `PeerSet` and will download
this chain from the peer(s), giving the downloaded blocks back to the caller to then verify and add to our chain.
## The Syncer
The syncer will handle synchronisation after falling behind, it will use [the block downloader](#the-block-downloader) and
the consensus service I created for my last CCS. It will get the blocks from the downloader, verify them and then
giving them to the database*.
*the database will not be worked on for this CCS, see [hinto's CCS](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/422).
If this CCS and [hinto's CCS](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/422) are accepted then when both are complete Cuprate will
be able to sync, verify and store the blockchain.
## Documentation
There are already documents describing the [levin header format](https://github.com/monero-project/monero/blob/master/docs/LEVIN_PROTOCOL.md) and [epee binary format](https://github.com/monero-project/monero/blob/master/docs/PORTABLE_STORAGE.md).
I will be documenting the format of each P2P message (how they are encoded, the fields) and successful message flows: handshakes, syncing etc.
# Why
I believe that having an alternative node is needed to help to protect against implementation issues like [this one](https://github.com/monero-project/monero/pull/9013) I found during my
last CCS.
Having an accessible P2P library and documentation will make it easier for devs to build software that needs to interact with the P2P network.
# Milestones
1. The PeerSet + Routing methods excluding D++
2. D++ Routing method + Network Initialisation
3. The Block Downloader + Syncer
4. Documentation
# Funding
I am asking for $45/hr for 50hrs/week for 3 months at $142/XMR this gives 190 XMR