Undo addition of transaction to TxValid#1947
Conversation
Transaction cost differencesScript summary
|
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | - | - | - | - |
| 2 | - | - | - | - |
| 3 | - | - | - | - |
| 5 | - | - | - | - |
| 10 | - | - | - | - |
| 40 | - | - | - | - |
Commit transaction costs
| UTxO | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | - | - | - | - |
| 2 | - | - | - | - |
| 3 | - | - | - | - |
| 5 | - | - | - | - |
| 10 | - | - | - | - |
| 54 | - | - | - | - |
CollectCom transaction costs
| Parties | UTxO (bytes) | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|---|
| 1 | - | - | - | - | - |
| 2 | - | - | - | - | - |
| 3 | - | - | - | - | - |
| 4 | - | - | - | - | - |
| 5 | - | - | - | - | - |
| 6 | - | - | - | - | - |
| 7 | - | - | - | - | - |
| 8 | - | - | - | - | - |
Cost of Increment Transaction
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | - | +0.39 | +0.09 | - |
| 2 | - | - | - | - |
| 3 | - | - | - | - |
| 5 | - | - | ||
| 10 | - | - | - | - |
| 37 | - | - |
Cost of Decrement Transaction
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | - | - | - | - |
| 2 | - | - | - | - |
| 3 | - | - | - | - |
| 5 | - | - | - | - |
| 10 | - | - | - | - |
| 40 | - | - | - | - |
Close transaction costs
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | - | - | - | - |
| 2 | - | - | - | - |
| 3 | - | - | - | - |
| 5 | - | - | - | - |
| 10 | - | - | - | - |
| 34 | - | - | - | - |
Contest transaction costs
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | - | - | - | - |
| 2 | - | - | - | - |
| 3 | - | - | - | - |
| 5 | - | - | - | - |
| 10 | - | - | - | - |
| 27 | - | - | - | - |
FanOut transaction costs
| UTxO, Parties | UTxO (bytes) | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|---|
| (0, 10) | - | - | - | - | - |
| (1, 10) | - | - | - | - | - |
| (5, 10) | - | - | - | - | - |
| (10, 10) | - | - | - | - | - |
| (20, 10) | - | - | - | - | - |
| (37, 10) | - | - | - | - | - |
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 | 6093 | 11.02 | 3.43 | 0.53 |
| 2 | 6292 | 13.04 | 4.04 | 0.56 |
| 3 | 6496 | 16.08 | 5.00 | 0.60 |
| 5 | 6895 | 20.56 | 6.38 | 0.67 |
| 10 | 7904 | 31.40 | 9.68 | 0.82 |
| 40 | 13936 | 98.66 | 30.31 | 1.78 |
Commit transaction costs
This uses ada-only outputs for better comparability.
| UTxO | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | 561 | 2.44 | 1.16 | 0.20 |
| 2 | 742 | 3.38 | 1.73 | 0.22 |
| 3 | 920 | 4.36 | 2.33 | 0.24 |
| 5 | 1282 | 6.41 | 3.60 | 0.28 |
| 10 | 2174 | 12.13 | 7.25 | 0.40 |
| 54 | 10046 | 98.61 | 68.52 | 1.88 |
CollectCom transaction costs
| Parties | UTxO (bytes) | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|---|
| 1 | 57 | 529 | 25.64 | 7.39 | 0.43 |
| 2 | 114 | 636 | 35.89 | 10.22 | 0.54 |
| 3 | 170 | 747 | 44.78 | 12.77 | 0.64 |
| 4 | 226 | 862 | 53.33 | 15.18 | 0.73 |
| 5 | 284 | 969 | 62.11 | 17.67 | 0.82 |
| 6 | 340 | 1081 | 78.51 | 22.01 | 0.99 |
| 7 | 393 | 1192 | 82.40 | 23.38 | 1.04 |
| 8 | 451 | 1303 | 84.45 | 24.13 | 1.06 |
Cost of Increment Transaction
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | 1797 | 25.12 | 8.24 | 0.49 |
| 2 | 1920 | 26.73 | 9.40 | 0.52 |
| 3 | 2059 | 28.69 | 10.65 | 0.55 |
| 5 | 2440 | 33.69 | 13.69 | 0.63 |
| 10 | 3041 | 40.81 | 19.15 | 0.75 |
| 36 | 7021 | 92.87 | 53.37 | 1.59 |
Cost of Decrement Transaction
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | 593 | 23.95 | 7.60 | 0.42 |
| 2 | 733 | 25.62 | 8.73 | 0.45 |
| 3 | 926 | 28.53 | 10.19 | 0.50 |
| 5 | 1349 | 35.46 | 13.43 | 0.59 |
| 10 | 1840 | 39.15 | 17.77 | 0.68 |
| 39 | 6371 | 99.57 | 53.76 | 1.62 |
Close transaction costs
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | 700 | 29.11 | 9.20 | 0.48 |
| 2 | 816 | 30.98 | 10.43 | 0.51 |
| 3 | 914 | 34.70 | 12.15 | 0.56 |
| 5 | 1406 | 39.29 | 15.35 | 0.64 |
| 10 | 2048 | 51.27 | 22.28 | 0.82 |
| 33 | 5456 | 95.24 | 51.78 | 1.53 |
Contest transaction costs
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | 674 | 35.95 | 11.00 | 0.55 |
| 2 | 818 | 38.15 | 12.33 | 0.58 |
| 3 | 938 | 40.24 | 13.62 | 0.61 |
| 5 | 1342 | 46.03 | 16.90 | 0.70 |
| 10 | 2016 | 57.43 | 23.72 | 0.87 |
| 27 | 4633 | 99.16 | 48.30 | 1.50 |
Abort transaction costs
There is some variation due to the random mixture of initial and already committed outputs.
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | 5992 | 28.20 | 9.30 | 0.71 |
| 2 | 6051 | 36.35 | 11.93 | 0.80 |
| 3 | 6238 | 46.99 | 15.49 | 0.92 |
| 4 | 6398 | 57.17 | 18.88 | 1.03 |
| 5 | 6509 | 66.57 | 21.97 | 1.13 |
| 6 | 6681 | 74.36 | 24.63 | 1.22 |
| 7 | 6808 | 82.19 | 27.17 | 1.31 |
| 8 | 6957 | 93.03 | 30.69 | 1.43 |
FanOut transaction costs
Involves spending head output and burning head tokens. Uses ada-only UTXO for better comparability.
| Parties | UTxO | UTxO (bytes) | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|---|---|
| 10 | 0 | 0 | 6091 | 20.32 | 6.69 | 0.63 |
| 10 | 1 | 57 | 6126 | 23.17 | 7.76 | 0.66 |
| 10 | 10 | 570 | 6432 | 40.96 | 14.72 | 0.87 |
| 10 | 30 | 1708 | 7112 | 84.94 | 31.71 | 1.38 |
| 10 | 37 | 2103 | 7346 | 98.94 | 37.19 | 1.54 |
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 2025-04-16 09:50:10.404915575 UTC
Baseline Scenario
| Number of nodes | 1 |
|---|---|
| Number of txs | 300 |
| Avg. Confirmation Time (ms) | 4.306080486 |
| P99 | 11.342251039999994ms |
| P95 | 5.02068285ms |
| P50 | 4.093883999999999ms |
| Number of Invalid txs | 0 |
Memory data
| Time | Used | Free |
|---|---|---|
| 2025-04-16 09:48:54.259231218 UTC | 907M | 6560M |
| 2025-04-16 09:48:59.259029295 UTC | 1036M | 6324M |
| 2025-04-16 09:49:04.259177946 UTC | 1027M | 6333M |
| 2025-04-16 09:49:09.259095828 UTC | 1027M | 6332M |
| 2025-04-16 09:49:14.259082963 UTC | 1032M | 6327M |
| 2025-04-16 09:49:19.259076601 UTC | 1034M | 6325M |
Three local nodes
| Number of nodes | 3 |
|---|---|
| Number of txs | 900 |
| Avg. Confirmation Time (ms) | 27.851768705 |
| P99 | 43.04956899ms |
| P95 | 37.65818304999999ms |
| P50 | 26.661121ms |
| Number of Invalid txs | 0 |
Memory data
| Time | Used | Free |
|---|---|---|
| 2025-04-16 09:49:32.594411302 UTC | 961M | 6407M |
| 2025-04-16 09:49:37.594568321 UTC | 1199M | 6168M |
| 2025-04-16 09:49:42.595998284 UTC | 1261M | 6049M |
| 2025-04-16 09:49:47.59444379 UTC | 1269M | 5990M |
| 2025-04-16 09:49:52.594513362 UTC | 1270M | 5988M |
| 2025-04-16 09:49:57.594447671 UTC | 1272M | 5986M |
| 2025-04-16 09:50:02.594463031 UTC | 1274M | 5984M |
| 2025-04-16 09:50:07.594460055 UTC | 1276M | 5981M |
3395e3a to
e047657
Compare
The TxValid server output message does not need to include the transaction as it was correctly submitted and accepted by a node. The requester will not need it as they just sent it, and other clients may not rely on it anyways as the SnapshotConfirmed only provides finality.
As we do not filter TxValid, its more consistent to not filter TxInvalid. Also, it can work around usability issue where someone would miss their own transaction submission erros with a bad query.
The golden spec for this failed even though it could parse the original golden file with 'transaction' dropped'. > Encoding has changed in a minor way; still can read old encodings. See golden/ServerOutput/TxValid.faulty.reencoded.json. Using that faulty.reencoded.json makes the test suite happy, but also changes 'headId' and 'transactionId' (for this same seed).
The
TxValidserver output message does not need to include the transaction as it was correctly submitted and accepted by a node. The requester will not need it as they just sent it, and other clients may not rely on it anyways as theSnapshotConfirmedonly provides finality.