Add constants/ crate

[hinto-janai]

What

Adds a cuprate_constants crate in the root constants/ folder.

Closes #189.

Why, where

See #189.

How

See below review.

[Asurar0]

Will P2P constants be included in this crate as well?

https://github.com/Cuprate/cuprate/blob/main/p2p/p2p-core/src/constants.rs
https://github.com/Cuprate/cuprate/blob/main/p2p/p2p/src/constants.rs

[hinto-janai]

Will P2P constants be included in this crate as well?

I haven't checked in depth but if they are pub(crate) and not needed elsewhere, probably not. Constants like CRYPTONOTE_MAX_BLOCK_HEIGHT doesn't really belong anywhere yet is needed by multiple crates - these are the type of constants this crate will contain.

[hinto-janai]

Constants are separated into feature gated modules.

There's more modules that could be added from https://github.com/monero-project/monero/blob/master/src/cryptonote_config.h but it seems lots of them don't need to public and/or belong in a more specific crate.

For now I only added modules that needs to be used in multiple places.

[hinto-janai]

cuprate_helper::constants was moved here.

[hinto-janai]

This generates const/statics for genesis block/tx data for all networks.

[Boog900]

As much as this is cool, do we actually need this much info?

The consensus-rules crate has a genesis module which is pretty much this just less complex

[hinto-janai]

The DB needs access to genesis data and RPC could benefit from access to the genesis hash.

I know cuprate_consensus_rules::genesis exists but it only contains a single non-const function that generates a Block per call.

[Boog900]

RPC could benefit from access to the genesis hash.

This request is already impl'd in the DB for the block downloader:

cuprate/storage/blockchain/src/service/read.rs

Line 527 in 5eb712f

fn find_first_unknown(env: &ConcreteEnv, block_ids: &[BlockHash]) -> ResponseResult {

We don't explicitly check the genesis hash, however if the genesis hash doesn't match BlockchainResponse::FindFirstUnknown(None) is returned.

The DB needs access to genesis data

We could check if the DB has the genesis block in the binary and then add it, instead of requiring the DB to do it it self. This is what I did in the blockchain manager branch.

[hinto-janai]

This request is already impl'd in the DB for the block downloader

We could check the hash at the RPC level before touching the DB, anyway, removed the module. If I find more usecases I'd like to add this back.

[hinto-janai]

CRYPTONOTE_MAX_BLOCK_HEIGHT is replaced by cuprate_constants::block::MAX_BLOCK_HEIGHT[_USIZE] throughout the codebase.

Also, I think Cuprate is far enough removed from the original CryptoNote that we can start dropping the CRYPTONOTE_ prefix.

[Boog900]

I don't think we should include block time/output lock time constants here, unless you need to use them elsewhere?

[hinto-janai]

@Boog900 ready.

[hinto-janai]

Actually, we need block time targets here: https://github.com/monero-project/monero/blob/9866a0e9021e2422d8055731a586083eb5e2be67/src/rpc/core_rpc_server.cpp#L531

edit: nvm, it's not technically required but it does seem wasteful to have to go through messages and talk to the DB for a constant.

[Boog900]

Actually, we need block time targets here

To get that you will need the current hard-fork even with constants, and if you have the current HF you can just call this:

cuprate/types/src/hard_fork.rs

Line 124 in 521bf87

pub const fn block_time(&self) -> Duration {

I would recommend going through the context cache to get the current HF.