cuprate/consensus
hinto-janai 4b93dbec4c
workspace: enforce crate/directory naming scheme ()
* rename all directories and crates

* fix all `use`

* fix doc link

* `dandelion/` -> `dandelion-tower/`

* fix epee-encoding test

* fix `json-rpc`

* fix pruning

* crate import fixes

* fix leftover merge conflicts

* fix `epee-encoding`
2024-06-24 02:30:47 +01:00
..
fast-sync workspace: enforce crate/directory naming scheme () 2024-06-24 02:30:47 +01:00
rules workspace: enforce crate/directory naming scheme () 2024-06-24 02:30:47 +01:00
src Consensus: block batch prepper () 2024-06-07 21:23:48 +01:00
tests Consensus: use cuprate-types types () 2024-06-04 18:19:35 +01:00
Cargo.toml Consensus: use cuprate-types types () 2024-06-04 18:19:35 +01:00
README.md Cleanup & Document consensus () 2024-05-31 01:52:12 +01:00

Consensus Rules

This folder contains 2 crates:

  • cuprate-consensus-rules (rules/ directory)
  • cuprate-consensus

cuprate-consensus-rules contains the raw-rules and is built to be a more flexible library which requires the user to give the correct data and do minimal calculations.

cuprate-consensus on the other hand contains multiple tower::Services that handle transaction/block verification as a whole with a context service that keeps track of blockchain state. cuprate-consensus uses cuprate-consensus-rules internally.

If you are looking to use Monero consensus rules it's recommended you try to integrate cuprate-consensus and fall back to cuprate-consensus-rules if you need more flexibility.