Conversation
Transaction cost differencesNo cost or size differences found |
End-to-end benchmark differencesComparing this PR ( Sustained load (3 nodes, 3x5000 txs)
Plateau 1000 UTxO (1 node, 4000 txs)
Round-trip latency (3 nodes, closed-loop, 3x250 txs)
|
Transaction costsSizes and execution budgets for Hydra protocol transactions. Note that unlisted parameters are currently using
Script summary
|
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | 5476 | 9.13 | 2.99 | 0.49 |
| 2 | 5573 | 10.34 | 3.41 | 0.50 |
| 3 | 5671 | 10.14 | 3.31 | 0.51 |
| 5 | 5858 | 11.65 | 3.82 | 0.53 |
| 10 | 6338 | 14.24 | 4.65 | 0.58 |
| 50 | 10180 | 35.40 | 11.26 | 0.97 |
| 100 | 14980 | 62.17 | 19.61 | 1.45 |
| 114 | 16327 | 69.73 | 21.99 | 1.59 |
Cost of Increment Transaction
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | 2322 | 21.15 | 7.52 | 0.48 |
| 2 | 2452 | 21.55 | 8.30 | 0.49 |
| 3 | 2583 | 22.70 | 9.34 | 0.51 |
| 5 | 2845 | 24.55 | 11.25 | 0.55 |
| 10 | 3501 | 30.05 | 16.34 | 0.66 |
| 50 | 8742 | 70.97 | 55.81 | 1.51 |
| 75 | 12017 | 97.36 | 80.73 | 2.05 |
Cost of Decrement Transaction
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | 641 | 18.46 | 6.68 | 0.38 |
| 2 | 773 | 19.43 | 7.65 | 0.40 |
| 3 | 904 | 20.41 | 8.63 | 0.42 |
| 5 | 1166 | 22.31 | 10.57 | 0.46 |
| 10 | 1822 | 27.03 | 15.40 | 0.56 |
| 50 | 7063 | 67.49 | 54.72 | 1.40 |
| 75 | 10339 | 93.06 | 79.37 | 1.93 |
Close transaction costs
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | 666 | 17.78 | 11.67 | 0.41 |
| 2 | 805 | 18.76 | 12.65 | 0.43 |
| 3 | 935 | 19.72 | 13.62 | 0.45 |
| 5 | 1194 | 21.69 | 15.58 | 0.49 |
| 10 | 1849 | 26.57 | 20.47 | 0.59 |
| 50 | 7090 | 67.89 | 60.13 | 1.44 |
| 74 | 10231 | 92.54 | 83.88 | 1.95 |
Contest transaction costs
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | 700 | 21.50 | 14.91 | 0.46 |
| 2 | 836 | 22.66 | 15.94 | 0.49 |
| 3 | 967 | 23.75 | 16.95 | 0.51 |
| 5 | 1226 | 26.01 | 19.00 | 0.55 |
| 10 | 1877 | 31.81 | 24.17 | 0.66 |
| 50 | 7118 | 80.03 | 65.87 | 1.58 |
| 66 | 9209 | 99.28 | 82.54 | 1.95 |
FanOut transaction costs
Involves spending head output and burning head tokens. Uses ada-only UTXO for better comparability.
Rows first grow the UTxO set at a fixed 10 parties, then show the largest set that still fits per number of parties (burning more participation tokens leaves less room for outputs).
| Parties | UTxO | UTxO (bytes) | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|---|---|
| 10 | 0 | 0 | 5645 | 23.29 | 42.87 | 0.90 |
| 10 | 1 | 57 | 5678 | 25.63 | 45.39 | 0.93 |
| 10 | 5 | 285 | 5815 | 35.88 | 55.71 | 1.10 |
| 10 | 10 | 569 | 5983 | 49.89 | 68.99 | 1.31 |
| 10 | 20 | 1138 | 6323 | 82.42 | 96.97 | 1.79 |
| 1 | 20 | 1137 | 6043 | 76.20 | 95.00 | 1.72 |
| 5 | 20 | 1139 | 6169 | 78.96 | 95.88 | 1.75 |
| 10 | 20 | 1140 | 6325 | 82.42 | 96.97 | 1.79 |
| 20 | 20 | 1140 | 6634 | 89.74 | 99.26 | 1.88 |
| 50 | 15 | 854 | 7394 | 94.70 | 91.88 | 1.90 |
PartialFanOut transaction costs
Largest chunk of ada-only outputs that can be distributed in one partial fanout step, computed dynamically. The last row is the maximum total UTxO count where at least one output can still be distributed.
| Total UTxO | Distributed | UTxO (bytes) | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|---|---|
| 11 | 10 | 569 | 982 | 34.91 | 66.33 | 0.95 |
| 25 | 23 | 1309 | 1428 | 68.24 | 99.40 | 1.48 |
| 30 | 23 | 1308 | 1427 | 68.24 | 99.40 | 1.48 |
| 40 | 23 | 1310 | 1429 | 68.24 | 99.40 | 1.48 |
| 50 | 23 | 1308 | 1423 | 68.24 | 99.40 | 1.48 |
| 100 | 23 | 1308 | 1427 | 68.24 | 99.40 | 1.48 |
| 150 | 23 | 1309 | 1428 | 68.24 | 99.40 | 1.48 |
| 200 | 23 | 1309 | 1424 | 68.24 | 99.40 | 1.48 |
| 200 | 23 | 1311 | 1430 | 68.24 | 99.40 | 1.48 |
PartialFanOut transaction costs (with native tokens)
Largest chunk of native-token outputs that can be distributed in one partial fanout step, computed dynamically. The last row is the maximum total UTxO count where at least one output can still be distributed.
| Total UTxO | Distributed | UTxO (bytes) | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|---|---|
| 11 | 10 | 1060 | 1539 | 42.00 | 68.86 | 1.05 |
| 25 | 21 | 2121 | 2368 | 76.56 | 99.12 | 1.59 |
| 30 | 21 | 2184 | 2434 | 76.59 | 99.17 | 1.59 |
| 40 | 21 | 2310 | 2566 | 76.56 | 99.21 | 1.60 |
| 50 | 21 | 2142 | 2387 | 76.59 | 99.17 | 1.59 |
| 100 | 21 | 2289 | 2545 | 76.56 | 99.17 | 1.60 |
| 150 | 21 | 2184 | 2435 | 76.59 | 99.17 | 1.59 |
| 200 | 21 | 2478 | 2739 | 76.59 | 99.22 | 1.60 |
| 200 | 21 | 2541 | 2809 | 76.56 | 99.27 | 1.61 |
FinalPartialFanOut transaction costs (with native tokens)
Terminal partial fanout step (FanoutProgress → Final) with outputs carrying a native token. Burns all head tokens and proves accumulator exhaustion via BLS proof.
| Distributed | UTxO (bytes) | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|---|
| 1 | 106 | 5525 | 22.10 | 44.31 | 0.89 |
| 5 | 505 | 5840 | 35.58 | 55.79 | 1.10 |
| 10 | 1040 | 6271 | 53.90 | 70.62 | 1.37 |
| 10 | 1030 | 6260 | 53.90 | 70.62 | 1.37 |
End-to-end benchmark results
This page is intended to collect the latest end-to-end benchmark results produced by Hydra's continuous integration (CI) system from the latest master code.
Please note that these results are approximate as they are currently produced from limited cloud VMs and not controlled hardware. Rather than focusing on the absolute results, the emphasis should be on relative results, such as how the timings for a scenario evolve as the code changes.
Generated at 2026-08-10 13:19:21.31869256 UTC
Baseline Scenario
| Number of nodes | 1 |
|---|---|
| Number of txs | 300 |
| Avg. Confirmation Time (ms) | 208.9 |
| P99 | 211.1ms |
| P95 | 210.8ms |
| P50 | 209.3ms |
| Tx validation time p50 (ms) | 134.6 |
| End-to-end TPS | 1385.11 tx/s |
| Backlog drain time (s) | 0.2 |
| Snapshots observed | 3 |
| Snapshots per second | 13.85 /s |
| Avg txs per snapshot | 100.0 |
| Peak node RSS (MB) | 144.4 |
| Number of Invalid txs | 0 |
| Fanout outputs | 2 |
Three local nodes
| Number of nodes | 3 |
|---|---|
| Number of txs | 900 |
| Avg. Confirmation Time (ms) | 1054.7 |
| P99 | 1116.0ms |
| P95 | 1115.0ms |
| P50 | 1079.2ms |
| Tx validation time p50 (ms) | 524.3 |
| End-to-end TPS | 803.15 tx/s |
| Backlog drain time (s) | 1.1 |
| Snapshots observed | 3 |
| Snapshots per second | 2.68 /s |
| Avg txs per snapshot | 300.0 |
| Peak node RSS (MB) | 147.2 |
| Number of Invalid txs | 0 |
| Fanout outputs | 4 |
Scenario benchmark results
This page collects results from the scenario matrix: every combination of cluster size, UTxO shape, and incremental-ops mode is exercised by CI from the latest master code and reported below.
Numbers are approximate. They come from cloud VMs rather than controlled hardware, so the useful signal is the relative change between cells and between commits, not the absolute throughput.
Generated at 2026-08-10 13:32:13.513885425 UTC
Summary across cells
TPS columns are rates (transactions per second); Wall clock (s) is the measured elapsed time from the first tx submission to the last confirmation. Times are rounded to one decimal.
| Scenario | Txs | Wall clock (s) | End-to-end TPS (tx/s) | Sustained TPS (tx/s) | Avg conf (ms) | P95 conf (ms) |
|---|---|---|---|---|---|---|
| Nodes=1, Constant, fire and forget | 30 | 0.0 | 863.36 | n/a | 33.9 | 34.4 |
| Nodes=1, Constant, wait for tx valid | 30 | 0.2 | 174.18 | 173.78 | 5.7 | 6.7 |
| Nodes=1, Growing, fire and forget | 30 | 0.0 | 776.95 | n/a | 37.7 | 38.3 |
| Nodes=1, Growing, wait for tx valid | 30 | 0.2 | 128.96 | 126.63 | 7.7 | 10.4 |
| Nodes=1, Mixed, fire and forget | 30 | 0.0 | 1051.12 | n/a | 27.7 | 28.3 |
| Nodes=1, Mixed, wait for tx valid | 30 | 0.2 | 142.79 | 137.38 | 6.9 | 9.5 |
| Nodes=2, Constant, fire and forget | 60 | 0.1 | 681.92 | n/a | 86.0 | 87.6 |
| Nodes=2, Constant, wait for tx valid | 60 | 0.5 | 117.06 | 115.81 | 16.9 | 24.3 |
| Nodes=2, Growing, fire and forget | 60 | 0.1 | 704.75 | n/a | 83.2 | 84.1 |
| Nodes=2, Growing, wait for tx valid | 60 | 0.7 | 80.31 | 78.12 | 24.6 | 32.1 |
| Nodes=2, Mixed, fire and forget | 60 | 0.1 | 844.16 | n/a | 69.5 | 70.1 |
| Nodes=2, Mixed, wait for tx valid | 60 | 0.7 | 87.65 | 84.43 | 22.6 | 29.0 |
| Nodes=3, Constant, fire and forget | 90 | 0.1 | 687.06 | n/a | 127.3 | 129.7 |
| Nodes=3, Constant, wait for tx valid | 90 | 0.9 | 96.55 | 96.62 | 30.3 | 41.2 |
| Nodes=3, Growing, fire and forget | 90 | 0.2 | 584.00 | n/a | 149.7 | 152.9 |
| Nodes=3, Growing, wait for tx valid | 90 | 1.4 | 65.67 | 67.39 | 44.9 | 63.9 |
| Nodes=3, Mixed, fire and forget | 90 | 0.1 | 647.20 | n/a | 135.5 | 138.8 |
| Nodes=3, Mixed, wait for tx valid | 90 | 1.2 | 77.79 | 74.48 | 38.0 | 51.2 |
Nodes=1, Constant, fire and forget
| Number of nodes | 1 |
|---|---|
| Number of txs | 30 |
| Avg. Confirmation Time (ms) | 33.9 |
| P99 | 34.5ms |
| P95 | 34.4ms |
| P50 | 34.1ms |
| Tx validation time p50 (ms) | 12.0 |
| End-to-end TPS | 863.36 tx/s |
| Backlog drain time (s) | 0.0 |
| Snapshots observed | 2 |
| Snapshots per second | 57.56 /s |
| Avg txs per snapshot | 15.0 |
| Peak node RSS (MB) | 143.6 |
| Number of Invalid txs | 0 |
| Fanout outputs | 2 |
Nodes=1, Constant, wait for tx valid
| Number of nodes | 1 |
|---|---|
| Number of txs | 30 |
| Avg. Confirmation Time (ms) | 5.7 |
| P99 | 11.3ms |
| P95 | 6.7ms |
| P50 | 5.3ms |
| Tx validation time p50 (ms) | 1.9 |
| End-to-end TPS | 174.18 tx/s |
| Sustained TPS | 173.78 tx/s |
| Backlog drain time (s) | 0.0 |
| Snapshots observed | 30 |
| Snapshots per second | 174.18 /s |
| Avg txs per snapshot | 1.0 |
| Peak node RSS (MB) | 144.6 |
| Number of Invalid txs | 0 |
| Fanout outputs | 2 |
Nodes=1, Growing, fire and forget
| Number of nodes | 1 |
|---|---|
| Number of txs | 30 |
| Avg. Confirmation Time (ms) | 37.7 |
| P99 | 38.3ms |
| P95 | 38.3ms |
| P50 | 37.9ms |
| Tx validation time p50 (ms) | 18.6 |
| End-to-end TPS | 776.95 tx/s |
| Backlog drain time (s) | 0.0 |
| Snapshots observed | 2 |
| Snapshots per second | 51.80 /s |
| Avg txs per snapshot | 15.0 |
| Peak node RSS (MB) | 144.1 |
| Number of Invalid txs | 0 |
| Fanout outputs | 31 |
Nodes=1, Growing, wait for tx valid
| Number of nodes | 1 |
|---|---|
| Number of txs | 30 |
| Avg. Confirmation Time (ms) | 7.7 |
| P99 | 13.6ms |
| P95 | 10.4ms |
| P50 | 7.0ms |
| Tx validation time p50 (ms) | 2.0 |
| End-to-end TPS | 128.96 tx/s |
| Sustained TPS | 126.63 tx/s |
| Backlog drain time (s) | 0.0 |
| Snapshots observed | 30 |
| Snapshots per second | 128.96 /s |
| Avg txs per snapshot | 1.0 |
| Peak node RSS (MB) | 143.3 |
| Number of Invalid txs | 0 |
| Fanout outputs | 31 |
Nodes=1, Mixed, fire and forget
Each client first grows its UTxO set (1-in to 2-out) for half of its tx budget, then contracts it back (2-in to 1-out) for the remainder.
| Number of nodes | 1 |
|---|---|
| Number of txs | 30 |
| Avg. Confirmation Time (ms) | 27.7 |
| P99 | 28.3ms |
| P95 | 28.3ms |
| P50 | 27.9ms |
| Tx validation time p50 (ms) | 11.4 |
| End-to-end TPS | 1051.12 tx/s |
| Backlog drain time (s) | 0.0 |
| Snapshots observed | 2 |
| Snapshots per second | 70.07 /s |
| Avg txs per snapshot | 15.0 |
| Peak node RSS (MB) | 142.8 |
| Number of Invalid txs | 0 |
| Fanout outputs | 2 |
Nodes=1, Mixed, wait for tx valid
Each client first grows its UTxO set (1-in to 2-out) for half of its tx budget, then contracts it back (2-in to 1-out) for the remainder.
| Number of nodes | 1 |
|---|---|
| Number of txs | 30 |
| Avg. Confirmation Time (ms) | 6.9 |
| P99 | 14.4ms |
| P95 | 9.5ms |
| P50 | 6.5ms |
| Tx validation time p50 (ms) | 2.0 |
| End-to-end TPS | 142.79 tx/s |
| Sustained TPS | 137.38 tx/s |
| Backlog drain time (s) | 0.0 |
| Snapshots observed | 30 |
| Snapshots per second | 142.79 /s |
| Avg txs per snapshot | 1.0 |
| Peak node RSS (MB) | 143.9 |
| Number of Invalid txs | 0 |
| Fanout outputs | 2 |
Nodes=2, Constant, fire and forget
| Number of nodes | 2 |
|---|---|
| Number of txs | 60 |
| Avg. Confirmation Time (ms) | 86.0 |
| P99 | 87.6ms |
| P95 | 87.6ms |
| P50 | 85.7ms |
| Tx validation time p50 (ms) | 50.0 |
| End-to-end TPS | 681.92 tx/s |
| Backlog drain time (s) | 0.1 |
| Snapshots observed | 2 |
| Snapshots per second | 22.73 /s |
| Avg txs per snapshot | 30.0 |
| Peak node RSS (MB) | 145.3 |
| Number of Invalid txs | 0 |
| Fanout outputs | 3 |
Nodes=2, Constant, wait for tx valid
| Number of nodes | 2 |
|---|---|
| Number of txs | 60 |
| Avg. Confirmation Time (ms) | 16.9 |
| P99 | 25.8ms |
| P95 | 24.3ms |
| P50 | 16.0ms |
| Tx validation time p50 (ms) | 4.1 |
| End-to-end TPS | 117.06 tx/s |
| Sustained TPS | 115.81 tx/s |
| Backlog drain time (s) | 0.0 |
| Snapshots observed | 60 |
| Snapshots per second | 117.06 /s |
| Avg txs per snapshot | 1.0 |
| Peak node RSS (MB) | 144.8 |
| Number of Invalid txs | 0 |
| Fanout outputs | 3 |
Nodes=2, Growing, fire and forget
| Number of nodes | 2 |
|---|---|
| Number of txs | 60 |
| Avg. Confirmation Time (ms) | 83.2 |
| P99 | 84.2ms |
| P95 | 84.1ms |
| P50 | 83.8ms |
| Tx validation time p50 (ms) | 27.3 |
| End-to-end TPS | 704.75 tx/s |
| Backlog drain time (s) | 0.1 |
| Snapshots observed | 2 |
| Snapshots per second | 23.49 /s |
| Avg txs per snapshot | 30.0 |
| Peak node RSS (MB) | 144.9 |
| Number of Invalid txs | 0 |
| Fanout outputs | 62 |
Nodes=2, Growing, wait for tx valid
| Number of nodes | 2 |
|---|---|
| Number of txs | 60 |
| Avg. Confirmation Time (ms) | 24.6 |
| P99 | 35.6ms |
| P95 | 32.1ms |
| P50 | 24.8ms |
| Tx validation time p50 (ms) | 7.3 |
| End-to-end TPS | 80.31 tx/s |
| Sustained TPS | 78.12 tx/s |
| Backlog drain time (s) | 0.0 |
| Snapshots observed | 60 |
| Snapshots per second | 80.31 /s |
| Avg txs per snapshot | 1.0 |
| Peak node RSS (MB) | 146.5 |
| Number of Invalid txs | 0 |
| Fanout outputs | 62 |
Nodes=2, Mixed, fire and forget
Each client first grows its UTxO set (1-in to 2-out) for half of its tx budget, then contracts it back (2-in to 1-out) for the remainder.
| Number of nodes | 2 |
|---|---|
| Number of txs | 60 |
| Avg. Confirmation Time (ms) | 69.5 |
| P99 | 70.5ms |
| P95 | 70.1ms |
| P50 | 69.8ms |
| Tx validation time p50 (ms) | 27.2 |
| End-to-end TPS | 844.16 tx/s |
| Backlog drain time (s) | 0.1 |
| Snapshots observed | 2 |
| Snapshots per second | 28.14 /s |
| Avg txs per snapshot | 30.0 |
| Peak node RSS (MB) | 144.6 |
| Number of Invalid txs | 0 |
| Fanout outputs | 3 |
Nodes=2, Mixed, wait for tx valid
Each client first grows its UTxO set (1-in to 2-out) for half of its tx budget, then contracts it back (2-in to 1-out) for the remainder.
| Number of nodes | 2 |
|---|---|
| Number of txs | 60 |
| Avg. Confirmation Time (ms) | 22.6 |
| P99 | 34.0ms |
| P95 | 29.0ms |
| P50 | 23.0ms |
| Tx validation time p50 (ms) | 7.7 |
| End-to-end TPS | 87.65 tx/s |
| Sustained TPS | 84.43 tx/s |
| Backlog drain time (s) | 0.0 |
| Snapshots observed | 60 |
| Snapshots per second | 87.65 /s |
| Avg txs per snapshot | 1.0 |
| Peak node RSS (MB) | 146.4 |
| Number of Invalid txs | 0 |
| Fanout outputs | 3 |
Nodes=3, Constant, fire and forget
| Number of nodes | 3 |
|---|---|
| Number of txs | 90 |
| Avg. Confirmation Time (ms) | 127.3 |
| P99 | 129.9ms |
| P95 | 129.7ms |
| P50 | 127.0ms |
| Tx validation time p50 (ms) | 48.9 |
| End-to-end TPS | 687.06 tx/s |
| Backlog drain time (s) | 0.1 |
| Snapshots observed | 2 |
| Snapshots per second | 15.27 /s |
| Avg txs per snapshot | 45.0 |
| Peak node RSS (MB) | 144.7 |
| Number of Invalid txs | 0 |
| Fanout outputs | 4 |
Nodes=3, Constant, wait for tx valid
| Number of nodes | 3 |
|---|---|
| Number of txs | 90 |
| Avg. Confirmation Time (ms) | 30.3 |
| P99 | 44.1ms |
| P95 | 41.2ms |
| P50 | 29.7ms |
| Tx validation time p50 (ms) | 7.1 |
| End-to-end TPS | 96.55 tx/s |
| Sustained TPS | 96.62 tx/s |
| Backlog drain time (s) | 0.0 |
| Snapshots observed | 61 |
| Snapshots per second | 65.44 /s |
| Avg txs per snapshot | 1.5 |
| Peak node RSS (MB) | 144.4 |
| Number of Invalid txs | 0 |
| Fanout outputs | 4 |
Nodes=3, Growing, fire and forget
| Number of nodes | 3 |
|---|---|
| Number of txs | 90 |
| Avg. Confirmation Time (ms) | 149.7 |
| P99 | 153.1ms |
| P95 | 152.9ms |
| P50 | 152.3ms |
| Tx validation time p50 (ms) | 44.0 |
| End-to-end TPS | 584.00 tx/s |
| Backlog drain time (s) | 0.1 |
| Snapshots observed | 2 |
| Snapshots per second | 12.98 /s |
| Avg txs per snapshot | 45.0 |
| Peak node RSS (MB) | 144.9 |
| Number of Invalid txs | 0 |
| Fanout outputs | 0 |
Nodes=3, Growing, wait for tx valid
| Number of nodes | 3 |
|---|---|
| Number of txs | 90 |
| Avg. Confirmation Time (ms) | 44.9 |
| P99 | 77.0ms |
| P95 | 63.9ms |
| P50 | 42.7ms |
| Tx validation time p50 (ms) | 12.7 |
| End-to-end TPS | 65.67 tx/s |
| Sustained TPS | 67.39 tx/s |
| Backlog drain time (s) | 0.0 |
| Snapshots observed | 65 |
| Snapshots per second | 47.43 /s |
| Avg txs per snapshot | 1.4 |
| Peak node RSS (MB) | 147.2 |
| Number of Invalid txs | 0 |
| Fanout outputs | 0 |
Nodes=3, Mixed, fire and forget
Each client first grows its UTxO set (1-in to 2-out) for half of its tx budget, then contracts it back (2-in to 1-out) for the remainder.
| Number of nodes | 3 |
|---|---|
| Number of txs | 90 |
| Avg. Confirmation Time (ms) | 135.5 |
| P99 | 138.9ms |
| P95 | 138.8ms |
| P50 | 136.3ms |
| Tx validation time p50 (ms) | 48.7 |
| End-to-end TPS | 647.20 tx/s |
| Backlog drain time (s) | 0.1 |
| Snapshots observed | 2 |
| Snapshots per second | 14.38 /s |
| Avg txs per snapshot | 45.0 |
| Peak node RSS (MB) | 145.2 |
| Number of Invalid txs | 0 |
| Fanout outputs | 4 |
Nodes=3, Mixed, wait for tx valid
Each client first grows its UTxO set (1-in to 2-out) for half of its tx budget, then contracts it back (2-in to 1-out) for the remainder.
| Number of nodes | 3 |
|---|---|
| Number of txs | 90 |
| Avg. Confirmation Time (ms) | 38.0 |
| P99 | 53.2ms |
| P95 | 51.2ms |
| P50 | 39.0ms |
| Tx validation time p50 (ms) | 10.4 |
| End-to-end TPS | 77.79 tx/s |
| Sustained TPS | 74.48 tx/s |
| Backlog drain time (s) | 0.0 |
| Snapshots observed | 61 |
| Snapshots per second | 52.72 /s |
| Avg txs per snapshot | 1.5 |
| Peak node RSS (MB) | 146.2 |
| Number of Invalid txs | 0 |
| Fanout outputs | 4 |
|
|
||
| ### 9. Persistence: SQLite observation index | ||
|
|
||
| - The service persists to an embedded SQLite database (mirroring |
There was a problem hiding this comment.
How much will the DB grow if we need to track hundreds of heads? Would disk space become problematic and when?
There was a problem hiding this comment.
Answer: not much. It is in the range of 1-10gb per year.
| - Explicit head-ID subscriptions are also supported (rejoining after restart, | ||
| observer mode). | ||
| - Filtering happens **server-side**, sized for thousands of heads. | ||
| - Every per-head observation carries a **monotonic sequence number**. On |
There was a problem hiding this comment.
Are these seq numbers monotonic across rollbacks, or can they be reused? So if the node processed seq 5, rollback to seq 3, then new observations arrive, do they get fresh numbers above 5?
There was a problem hiding this comment.
Yes, I would assume so - hydra-chain-observer should be aware of rollbacks and roll forwards since it is connected to cardano-node directly.
| resume**. Duplicates are possible in crash windows and the node | ||
| deduplicates by sequence number — the cursor rides along with the | ||
| `StateChanged` events it already persists. |
There was a problem hiding this comment.
Where does this dedup happen? before HeadLogic sees the observation?
There was a problem hiding this comment.
Yes - in the new hydra-chain-observer. HeadLogic stays intact and in case of a rollback we rewind client cursor so we can serve the same events again to get to a chain tip again.
|
|
||
| - The service persists to an embedded SQLite database (mirroring | ||
| `hydra-node`'s own event store): | ||
| - `observations(head_id, seq, chain_point, block_no, payload_cbor)` with a |
There was a problem hiding this comment.
When do we prune this table? It grows forever otherwise
There was a problem hiding this comment.
Right now never but this is not problematic since we only keep observations inside which are around 100kb per head lifetime.
| - Besides following the chain, the service also handles **transaction | ||
| submission** (submit, await confirmation) and **queries**: UTxO, protocol | ||
| parameters, era history, system start and tip. | ||
| - Rationale: the service caches slow-changing answers (microseconds from |
There was a problem hiding this comment.
How do we keep the cached era history fresh? We just hit exactly this in #2803
There was a problem hiding this comment.
I can imagine introducing cache with a timeout but in this first version we don't even need to do this.
Signed-off-by: Sasha Bogicevic <sasha.bogicevic@iohk.io>
| - `HeadLogic`, the persistence of `StateChanged` events ([ADR 24](/adr/24)) | ||
| and node-side rollback handling ([ADR 23](/adr/23)) are untouched. | ||
|
|
||
| ### 4. The service is a full L1 gateway |
There was a problem hiding this comment.
Maybe we don't do this because it's a little unrelated and potentially confusing; keeping the chain-observer as observing only seems useful, and we can think about refactoring our wallet stuff a little later; when we have a bit more ideas about how we want wallets to look more generally.
3 participants
Let's iterate on this ADR together as it will be used to guide further steps in separating hydra-chain-observer into a service shared by different hydra nodes.