Newer
Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
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
---
layout: fr
title: hinto-janai full-time work on Cuprate (3 months)
author: hinto-janai
date: August 9, 2024
amount: 221
milestones:
- name: JSON RPC handlers
funds: 40% (88.4)
done:
status: unfinished
- name: Binary/other RPC handlers
funds: 40% (88.4)
done:
status: unfinished
- name: Other work
funds: 20% (44.2)
done:
status: unfinished
payouts:
- date:
amount:
- date:
amount:
- date:
amount:
---
## What
[Cuprate](https://github.com/Cuprate/cuprate) is an alternative Monero node implementation.
The next section that needs work is the RPC handlers. The design, interface, routing, types, and (de)serialization were completed in my previous CCS, see here:
- Past CCS: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/456
- RPC interface tracking issue: https://github.com/Cuprate/cuprate/issues/183
- RPC book: https://architecture.cuprate.org/rpc/intro.html
This CCS is for the handlers, i.e. the functions that turn requests into responses.
Once the handlers are complete, Cuprate will have a working RPC stack that [mostly](https://architecture.cuprate.org/rpc/differences/intro.html) mirrors `monerod`.
## Who
I'm [hinto-janai](https://github.com/hinto-janai).
## RPC handlers
The 1st/2nd milestones are for the RPC handlers. This is the majority of the work.
This includes:
- JSON RPC handlers (methods behind `/json_rpc`)
- Binary RPC handlers (binary endpoints, e.g. `/get_blocks.bin`)
- Other handlers (other JSON endpoints, e.g. `/get_height`)
The RPC handlers will most likely be in its own library/section, built on-top of the RPC libraries Cuprate has so far. The current RPC interface library ([`cuprate-rpc-interface`](https://github.com/Cuprate/cuprate/tree/main/rpc/interface)) allows for custom handlers, as in, the mapping of `request` -> `response` can be customized. The handler created in this CCS will be a standard implementation that (mostly) follows `monerod`'s behavior, i.e. request comes in, get some data from the database and such, return a response. Although, other implementations are possible, such as an RPC handler that caches blocks, as mentioned in [this meeting](https://github.com/monero-project/meta/issues/996#issuecomment-2086710102).
Testing, [crate (library) documentation](https://doc.cuprate.org), and [architecture book](https://architecture.cuprate.org) sections will also be written.
### Binary strings
There are a few RPC methods that require further discussion before implementation in Cuprate, see the [binary strings proposal](https://github.com/monero-project/monero/issues/9422).
If the above proposal finds consensus on future `monerod` behavior, this CCS will implement that behavior.
If more time is required for the proposal, the related endpoints/methods will be left in a semi-unfinished state until behavior is agreed upon, where after Cuprate will implement that behavior.
If the proposal does not move forward, Cuprate is planning to fallback to implementing `monerod`'s current behavior.
## Other work
The 3rd milestone is for any miscellaneous work that needs to be done for Cuprate, but also, these 2 concrete things:
- Lints
- Benchmarking
I'd like to focus on these as:
- If they're always pushed to the side, they'll never get done
- I believe it's important to establish these early on in the project
I started integrating lints & benchmarks into Cuprate last CCS, this CCS will finish integrating them for all the libraries I've written so far, and [other libraries](https://architecture.cuprate.org/appendix/crates.html) if time allows.
The issues tracking the progress of these two can be found here:
- https://github.com/Cuprate/cuprate/issues/207 (lints)
- https://github.com/Cuprate/cuprate/issues/208 (benchmarks)
## Funding
I am asking for $65 + 0.05 XMR per hour for 480 hours at $158/XMR. This gives 221 XMR.