Ouroboros Consensus

Implementation of the Ouroboros family of consensus algorithms.

Libraries and executables

This repository provides four packages, with the following dependencies among them:

flowchart TD
    D[ouroboros-consensus-diffusion] --> C
    A[ouroboros-consensus-cardano] --> B[ouroboros-consensus-protocol]
    A --> C
    B --> C[ouroboros-consensus]

The packages contain many test-suites that complicate the dependency graph as they create new depencency arcs.

This repository also provides four executables:

ouroboros-consensus-cardano/app/db-analyser.hs: for analyzing ChainDBs as the ones created by the node. This helps identifying performance hotspots and testing that the validating logic remains correct.
ouroboros-consensus-cardano/app/db-synthesizer.hs: for quickly generating chains to be used in benchmarking.
ouroboros-consensus-cardano/app/db-truncater.hs: for truncating an immutable DB.
ouroboros-consensus-cardano/app/immdb-server.hs: for serving a immutable DB stored locally.

To list all the available Cabal components, one can use the following script because unfortunately, cabal doesn't have a command to list the available targets:

for f in $(find ouroboros-consensus* *sop* -type f -name "*.cabal"); do
    printf "Components of package %s:\n" $f;
    grep -E "^(library|test-suite|executable|benchmark)" $f --color=never | column -t | sort | sed 's/^/\t/'
done

Building the project

We use cabal to build our project, potentially inside a Nix shell (nix develop or nix-shell). It should suffice with:

> cabal build all

Specific executables can be executed through cabal once built:

> cabal run db-analyser

Testing the project

The project is tested with numerous Haskell test suites. To run every test suite, one can use:

> cabal test all

For running specific test-suites (such as consensus-test), we recommend one of the following commands:

> cabal run ouroboros-consensus:test:consensus-test -- <args>
> cabal test ouroboros-consensus:test:consensus-test --test-show-details=direct

Note the second one cannot be used when we want to provide CLI arguments to the test-suite.

Using Consensus as a dependency

We make releases to the Cardano Haskell Package repository from where you should pull new releases.

To use CHaP, follow their Readme, but in short:

Add this at the top of your cabal.project file:

repository cardano-haskell-packages
  url: https://input-output-hk.github.io/cardano-haskell-packages
  secure: True
  root-keys:
    3e0cce471cf09815f930210f7827266fd09045445d65923e6d0238a6cd15126f
    443abb7fb497a134c343faf52f0b659bd7999bc06b7f63fa76dc99d631f9bea1
    a86a1f6ce86c449c46666bda44268677abf29b5b2d2eb5ec7af903ec2f117a82
    bcec67e8e99cabfa7764d75ad9b158d72bfacf70ca1d0ec8bc6b4406d1bf8413
    c00aae8461a256275598500ea0e187588c35a5d5d7454fb57eac18d9edb86a56
    d4a35cd3121aa00d18544bb0ac01c3e1691d618f462c46129271bccf39f7e8ee

Run cabal update to pull in the latest index.
Specify which version of the index you want for both Hackage and CHaP. Note that it has to be higher or equal to the highest timestamp of the released versions of the packages that you want to use as dependencies:
```
index-state:
 , hackage.haskell.org      2023-04-12T00:00:00Z
 , cardano-haskell-packages 2023-04-23T00:00:00Z
```

At this point, you should be able to declare our libraries as dependencies in your build-depends list on your cabal files.

If you use Nix, see the CHaP website on how to configure CHaP for haskell.nix.

The Consensus sublibraries---which are used for our internal testing---are visible and buildable by default only because the appropriate Cabal and/or Nix infrastructure to guard them behind an explicit opt-in is currently immature and fragile. WARNING breaking changes to the these libraries are not reflected in the package versions. That is why they all have the unstable- prefix in their name; use at your own risk, and please reach out to us if this policy of ours is an excessive burden on your use case.

How to contribute to the project

Your help is greatly appreciated. Please see our CONTRIBUTING document.

How to submit an issue

Issues can be filled in our GitHub issue tracker. Please use the provided issue templates.

Documentation

We have several sources of documentation:

Haddocks: our code is full of haddock annotations and comments that try to clarify expected behaviors and subtleties. Reading through the code should provide most of the information on how is Consensus implemented.
Website: this website provides access to the markdown documentation to which step by step we want to move the bulk of the "higher level documentation" as well as achitectural documentation.
Report: this in-depth technical report describes many of the deep choices made in the implementation of the Consensus layer, as well as non-trivial lemmas or properties of the Consensus algorithms that have perspired to the implementation. Although incomplete in some sections, it is a mandatory reading for anyone looking to understand why Consensus does what it does. (rendered)

input-output-hk / ouroboros-consensus