Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Project roadmap for 2025 #376

Open
hinto-janai opened this issue Jan 28, 2025 · 0 comments
Open

Project roadmap for 2025 #376

hinto-janai opened this issue Jan 28, 2025 · 0 comments
Labels
C-discussion General discussion or questions.

Comments

@hinto-janai
Copy link
Contributor

hinto-janai commented Jan 28, 2025

This issue documents Cuprate's roadmap for 2025.

Last updated: 2025-01-28

  • Beneficiaries
  • Project roadmap
    • Q1
      • Alpha cuprated release cycle
      • Fast-sync
      • Transaction pool relay rules
      • Logging
      • STDIN commands
    • Q2/Q3/Q4
      • FCMP++
      • RPC
      • Tor (arti) integration
    • Non-goals for 2025

Beneficiaries

TODO: this section is not yet finished.

It is worth identifying the stakeholders/beneficiaries before laying out any value hierarchy for Cuprate as it is the aim of any project to bring value to those groups and set the roadmap accordingly. Being a public node project, Cuprate benefits a large portion of Monero, particularly:

  1. Organizations (wallets, exchanges, services, businesses)
  2. Operators (individual users)
  3. Developers

cuprated's RPC interface is planned to be practically no different than monerod, as such, current services utilizing daemon RPC should be able to swap monerod for cuprated with no trouble for a faster experience. This is a large incentive for any user of monerod, particularly any organization operating at scale.

Individual users benefit from the organization-level benefits as well as other 'smaller' practical benefits, mostly stemming from being a modern implementation of Monero, e.g. sync speeds, documentation, etc.

Regarding developers, the libraries that make up Cuprate's node implementation are all re-usable, open-source, and increasingly more importantly, in Rust. For all practical purposes, this is a non-trivial detail that is important for future development.

Project roadmap

Q1

These goals will be focused on throughout January-March 2025.

Alpha cuprated release cycle

Cuprate has begun working on finalizing an alpha release cycle here:

There are a few other details that must be decided, where after, the first release is expected in 2025 Q1. Alpha releases are set to occur every 4 weeks from there after.

Fast-sync

TODO

Transaction pool relay rules

TODO

Logging

TODO

STDIN commands

TODO

Q2/Q3/Q4

These goals will be focused on throughout April-December 2025.

FCMP++

FCMP++ in monerod is still be worked on, thus work on this has not yet started, although it must eventually be implemented in cuprated in order to continue to stay compatible with the network.

RPC

Much of the core functionality of monerod has already been implemented: transaction/block {sync, verification, propagation}. One of the remaining core functionality is a wallet-compatible RPC system. As mentioned earlier, there are large incentives for this to be done for organizations operating at scale.

Tor (arti) integration

As noted before, one of the aspects of Monero's privacy that could be further worked on is the P2P network. As arti can be embedded within cuprated, the barrier of entry for Tor usage can be lowered significantly, as such, a more anonymous P2P network can be achieved. Due to these reasons, this has remained a high priority for Cuprate since the beginning of the project 1 2.

Non-goals for 2025

There is a long bucket list for Cuprate, yet the project is limited in time and resources. As such, some items must take precedence over others. This is an incomplete list of items that Cuprate will likely not implement (in 2025) in order to focus on the core goals laid out above:

  • Other interfaces (e.g. ZMQ, WebSockets)
  • Non-node related efforts (e.g. wallet, GUI)
  • Optimizations for certain hardware
  • Novel architecture/implementations
  • Stability guarantees for crates and binary interfaces
  • Reproducible builds
  • Expanded build targets

It is worth noting that:

  1. This roadmap is made under the assumption that current developer resources will stay the same
  2. These values can always be changed in the future
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-discussion General discussion or questions.
Projects
None yet
Development

No branches or pull requests

1 participant