|
1 | 1 | # Amaru Simulator |
2 | 2 |
|
3 | | -This component aims at implementing a _Simulator_ for the Ouroboros Consensus, in Rust, using Amaru components. The main goal of this work is to be able to test the consensus part as deeply as possible, using different strategies, in increasing order of fidelity: |
| 3 | +This component aims at implementing a _Simulator_ for the Ouroboros Consensus, |
| 4 | +in Rust, using Amaru components. The main goal of this work is to be able to |
| 5 | +test the consensus part as deeply as possible, using different strategies, in |
| 6 | +increasing order of fidelity: |
4 | 7 |
|
5 | | -1. ✅ In-process deterministic testing, completely simulating the environment, allowing arbitrary fault injections and full control over concurrency and other side-effects |
6 | | -2. ✅ [Maelstrom](https://github.com/jepsen-io/maelstrom/)-like testing through stdin/stdout interface ignoring network interactions |
7 | | -3. 🔴 [Jepsen](https://github.com/jepsen-io/jepsen)-like testing through full-blown deployment of a cluster and actual networking stack |
| 8 | +1. ✅ In-process deterministic testing, completely simulating the environment, |
| 9 | + allowing arbitrary fault injections and full control over concurrency and |
| 10 | + other side-effects |
| 11 | +2. ✅ [Maelstrom](https://github.com/jepsen-io/maelstrom/)-like testing through |
| 12 | + stdin/stdout interface ignoring network interactions |
| 13 | +3. 🔴 [Jepsen](https://github.com/jepsen-io/jepsen)-like testing through |
| 14 | + full-blown deployment of a cluster and actual networking stack |
8 | 15 | 4. 🔴 [Antithesis](https://antithesis.com) support |
9 | 16 |
|
| 17 | +## Overview |
| 18 | + |
| 19 | +The main components of the simulator are: |
| 20 | + |
| 21 | +* Test case generation, found in |
| 22 | + [`src/simulator/generate.rs`](src/simulator/generate.rs), which uses the |
| 23 | + pre-generated block tree which is saved in |
| 24 | + [`tests/data/chain.json`](tests/data/chain.json); |
| 25 | +* The (discrete-event) simulator itself, lives in |
| 26 | + [`src/simulator/simulate.rs`](src/simulator/simulate.rs); |
| 27 | +* The property-based test and property that uses the simulator, defined in |
| 28 | + [`src/simulator/mod.rs`](src/simulator/mod.rs); |
| 29 | + and property that uses the simulator is defined; |
| 30 | +* The actual Rust `#test` which gets picked up by `cargo test`, found in |
| 31 | + [`tests/simulation.rs`](tests/simulation.rs). |
| 32 | + |
10 | 33 | ## Usage |
11 | 34 |
|
12 | | -The `simulator` executable is a pared-down version of Amaru where network communications are abstracted away. It's packaged as a test so running it amounts to: |
| 35 | +The `simulator` test is a pared-down version of Amaru where network |
| 36 | +communications are abstracted away. |
| 37 | + |
| 38 | +The test can be run as follows (environment variables can be used to override |
| 39 | +options, we show the default values here): |
13 | 40 |
|
14 | 41 | ``` |
15 | | -cargo test -p amaru-sim |
| 42 | +AMARU_NUMBER_OF_TESTS=50 # Set the number of test cases to generate. \ |
| 43 | +AMARU_NUMBER_OF_NODES=1 # Set the number of nodes in a simulation. \ |
| 44 | +AMARU_NUMBER_OF_UPSTREAM_PEERS=2 # Set the number of upstream peers. |
| 45 | +AMARU_DISABLE_SHRINKING=0 # Set to 1 to disable shrinking. \ |
| 46 | +AMARU_TEST_SEED= # Seed to use to reproduce a test case. \ |
| 47 | +AMARU_PERSIST_ON_SUCCESS=0 # Set to 1 to persist pure-stage schedule on success. \ |
| 48 | +AMARU_SIMULATION_LOG="error" # Only show error-level logging. \ |
| 49 | +\ |
| 50 | +cargo test run_simulator |
16 | 51 | ``` |
17 | 52 |
|
18 | | -By default, it only logs `error` level and above log entries, but one filter logs by setting the `AMARU_SIMULATION_LOG` environment variable to an appropriate value. |
| 53 | +## Debugging failures |
| 54 | + |
| 55 | +When the test fails, the output looks something like this: |
| 56 | + |
| 57 | +``` |
| 58 | + Minimised input (0 shrinks): |
| 59 | +
|
| 60 | + Envelope { src: "c1", dest: "n1", body: Fwd { msg_id: 0, slot: Slot(31), hash: "2487bd", header: "828a0118" } } |
| 61 | + Envelope { src: "c1", dest: "n1", body: Fwd { msg_id: 1, slot: Slot(38), hash: "4fcd1d", header: "828a0218" } } |
| 62 | + Envelope { src: "c1", dest: "n1", body: Fwd { msg_id: 2, slot: Slot(41), hash: "739307", header: "828a0318" } } |
| 63 | + Envelope { src: "c1", dest: "n1", body: Fwd { msg_id: 3, slot: Slot(55), hash: "726ef3", header: "828a0418" } } |
| 64 | + Envelope { src: "c1", dest: "n1", body: Fwd { msg_id: 4, slot: Slot(93), hash: "597ea6", header: "828a0518" } } |
| 65 | + [...] |
| 66 | +
|
| 67 | +History: |
| 68 | +
|
| 69 | + 0. "c1" ==> "n1" Fwd { msg_id: 0, slot: Slot(31), hash: "2487bd", header: "828a0118" } |
| 70 | + 1. "n1" ==> "c1" Fwd { msg_id: 0, slot: Slot(31), hash: "2487bd", header: "828a0118" } |
| 71 | + 2. "c2" ==> "n1" Fwd { msg_id: 0, slot: Slot(31), hash: "2487bd", header: "828a0118" } |
| 72 | + 3. "c2" ==> "n1" Fwd { msg_id: 1, slot: Slot(38), hash: "4fcd1d", header: "828a0218" } |
| 73 | + 4. "n1" ==> "c2" Fwd { msg_id: 1, slot: Slot(38), hash: "4fcd1d", header: "828a0218" } |
| 74 | + [...] |
| 75 | +
|
| 76 | +Error message: |
| 77 | +
|
| 78 | + tip of chains don't match, expected: |
| 79 | + (Bytes { bytes: "fcb4a51..." }, Slot(990)) |
| 80 | + got: |
| 81 | + (Bytes { bytes: "gcb4a51..." }, Slot(990)) |
| 82 | +
|
| 83 | +Saved schedule: "./failure-1752489042.schedule" |
| 84 | +
|
| 85 | +Seed: 42 |
| 86 | +``` |
| 87 | + |
| 88 | +Let's break the components down: |
| 89 | + |
| 90 | +* The minimised failing test case is printed so that it can be copy-pasted into a |
| 91 | + `#test` to create a regression test; |
| 92 | +* The history is the same as test case, but the `src` and `dest` of each |
| 93 | + message has been pretty printed to be easier to read and it also contains the |
| 94 | + responses that we got back from the system under test. The history is what the |
| 95 | + property is checked against; |
| 96 | +* The error message is how the property failed; |
| 97 | +* Saved schedule is the execution schedule from `pure-stage`, which can provide |
| 98 | + low-level details about how the stage processing happened. See the following |
| 99 | + [note](https://github.com/pragma-org/amaru/wiki/log-::-2025%E2%80%9006#debugging-simulation-tests-failure) |
| 100 | + for more details of how to use this information; |
| 101 | +* The seed is what was used to produce the test case, it can be used to replay |
| 102 | + the test (see `AMARU_TEST_SEED` above). |
19 | 103 |
|
20 | 104 | ## References |
21 | 105 |
|
22 | | -* [Cardano Consensus and Storage Layer](https://ouroboros-consensus.cardano.intersectmbo.org/assets/files/report-b72e7d765cfee85b26dc035c52c6de84.pdf) |
23 | | -* [Ouroboros Network Specification](https://ouroboros-network.cardano.intersectmbo.org/pdfs/network-spec/network-spec.pdf) |
| 106 | +* [Cardano Consensus and Storage |
| 107 | + Layer](https://ouroboros-consensus.cardano.intersectmbo.org/assets/files/report-b72e7d765cfee85b26dc035c52c6de84.pdf) |
| 108 | +* [Ouroboros Network |
| 109 | + Specification](https://ouroboros-network.cardano.intersectmbo.org/pdfs/network-spec/network-spec.pdf) |
0 commit comments