Cuprate

an upcoming experimental, modern & secure monero node. Written in Rust

(there is nothing working at the moment, stay tuned if you want to see some adventures)

 

Introduction

Why?

Monero is actively used across the world and gains more and more users through the years. Unfortunately, it is clearly targeted by numerous adversaries with different set of ressources. As of now we are targeted by media disinformation, other cryptocurrency communities & even governements. The life of the project depends now on our efforts to make Monero usable by anyone while also remaining resilient against an attack.

The current state of Monero developpement is encouraging. Farcaster & COMIT have successfuly developped XMR<>BTC Atomic Swap, ETH<>XMR bridge is on the way, and other are draft. Not only it is a great addition to the UX but it also give monero resilience by developping way for people to access it in case of ban. Seraphis is on the way to make Monero even more private. As of consensus security, p2pool is now mature and actively used.

We can clearly applaud all the efforts that have been done. But there is still works to do. For example, we still don't have developped traffic obfuscation to bypass DPI. Without, it'll be easy for governements to dramatically reduce the access to the monero network, and by that reduce the number of people that could escape the financial system.

Cuprate is an ongoing effort to release an alternative implementation of the Monero Node with new features. It is developped in Rust and therefore enjoy from many advantages in term of security and stability. It will also help developping new features with high-level, safe and maintained librairies available in the rust ecosystem.

Releasing an alternative node will reinforce the Monero Network if a security vulnerability is discovered in the current node maintained by the monero-core team. It will also encourage (i hope) more open-source developers to contribute to the project.

Status

Status of current parts being work on can be found in the pull request section.

@boog900 have delivered the net code and is working on ringCT & P2P.

@SyntheticBird45 is working on the database part.

Contributions

Any help is appreciated. If you want to help but don't know where to start, you can take a look at the issues section

We encourage anyone to review the work being done, discuss about it or propose agressive optimizations (at architectural level if needed, or even micro-optimizations in 'monolithic components').

For non-developers people, you can also propose ideas in the discussion section. The sooner we hear about your ideas, the better the chance are we implement them into Cuprate.

Code & Repository

No unsafe code is permitted in the project, and the codebase will never contain .expect() or panic!(). We discourage the use of .unwrap(), as it implied that all patterns are correctly handled. This way the node will never suddenly crash.

The repository is a cargo workspace. You will find every corresponding codebase in their crates folders. These crates are librairies and the main crates used to compile the node can be found in src/

Security measures

Exploit Mitigations

As specified in the cargo.toml, cuprate releases are compiled with several rustflags & cargoflags to improve binary security:

Debug informations are cleared & symbols are stripped.

Even if the source code is available, sometimes you can find bugs in a program by looking at the metadata left by the compiler at assembly level. Stipping these metadata help mitigating some vulnerability analysis. Of course someone could recompile it without these flags. The same way some people could tunes some compilation flags if they decide to compile it by themselves. But it is likely to change call hierarchy and other data that could ruin a potential vulnerability.

In case of panic, the node immediately abort.

This isn't to be annoying. This is security measure. Most of the times, exploits are designed to use vulnerabilities that don't crash the targeted process but is definitely modifying it's behavior. In such case, where a function doesn't end properly, the sanest way to deal with it, is to stop all the threads immediately. If you don't, you risk to trigger a vulnerability or execute potential malware code.

Forward-Edge Control-Flow Integrity

This is an exploit mitigation that can be enable in GCC & LLVM to fight against Return-oriented programming. This isn't enabled by default in Rust, because to make a rop chain you need first to corrupt a pointer (which is *normally* impossible), but since we focus on security it's worth enabling it. CFI is basically a combination of added code to verify if the program is respecting it's functions call hierarchy or if its calling part of the binary it shouldn't do.

Compiling as a Position Indepent Executable

This is a type of executable that permit its machine code to be executed regardless of it's address layout by dynamically playing with its global offset table. This way, functions called each others based on offset instead of absolute address. It permit better security because at each execution the address being used in the execution stack change. This is great to make a potential exploit unreliable on targeted machines.

Using stack-protector=all

Stack protector are a set of strategy used by LLVM & GCC to detect buffer overflow & general memory corruption. By setting it as all, we tell LLVM to enable this strategy to all functions. Making it as difficult as possible to corrupt memory without being detected (=abort).

Dependencies

Dependencies

Dependencies	Reason
monero-rs	Used to define monero's type and serialize/deserialize data.
serde	serialize/deserialize support.
thiserror	used to Derive(Error) in the codebase.
libmdbx	safe wrapper for mdbx implementation.

License

Cuprate is licensed under MIT-AGPL. the corresponding license to each crates can be found in their respective folders.

Improvements & Features

Traffic Obfuscation

Different protocol to bypass DPI will be available, such as with a proposal for Levin protocol (TLS based, see https://github.com/monero-project/monero/issues/7078) and QUIC like Syncthing have done, but with offset and timing mitigations. Unless the monero-core team decide to implement these protocols, they'll only by available between cuprate peers.

Blockchain Storage

LMDB is replaced by MDBX, a spiritual successor of LMDB with insane performance, already used by the reth Ethereum's rust client. HSE (Heterogeneous Storage Engine for Micron, optimized for SSD & random writes & reads) is also going to be implemented, as a more dsitributed and scalable alternative.

Sandboxing & System

- For Linux : There will be maintained SELinux/Apparmor policy for this node for major linux distributions. It will internally use seccomp to limit syscalls being used. Landlock is also going to be setup in order to improve isolation of the node with rest of the OS.
- For Windows : It still need some research but we could use capability primitives & WinAPI to limit access to certain system functions.
- For macOS : There is unfortunately no library to setup some isolation, as Apple seems to have deprecated Seatbelt.

RPC

ZeroMQ as well as gRPC will be available to communicate with the node. Powered by tonic library from Tokio

Terminal Interface

More accessible interface based on the excellent [tui](https://lib.rs/crates/tui) library. There will be Geolocation of peers on map, VPN Detection, Ressource usages, statistics etc...

Tor connections

arti_client library will be embedded to make possible connections to tor peers without a system daemon or proxy (for the moment arti_client can't handle onion services, but it'll certainly in the near future). i2p support is not planned at the moment

Regressions

• No integrated miner planned
• LMDB support removed. Which means that the blockchain synced by monerod is incompatible with cuprate.
• Some funny messages in the original codebase will be lost.

PGP keys

If you wish to contact contributors privately, you can import our gpg keys from the pgp_keys folder.