Skip to content

Commit f324e76

Browse files
authored
Analysis of block validation times (#471)
* Repeated and expanded `db-analyser` analysis * Updated logbook
1 parent 613deb7 commit f324e76

File tree

3 files changed

+1247
-0
lines changed

3 files changed

+1247
-0
lines changed

Logbook.md

Lines changed: 23 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,28 @@
11
# Leios logbook
22

3+
## 2025-07-24
4+
5+
### Revised analysis of block and transaction validation times
6+
7+
We completed the basic analysis of block and transaction validation times for Cardano `mainnet` since Epoch 350. Results differ significantly from the preliminary results because it was discovered that `db-analyser` output is not reliable when it is run on a machine that has other CPU load: the new analysis is based on a clean dataset that was run on an otherwise idle machine.
8+
9+
Findings:
10+
11+
1. The `db-analyser` tool can be used to measure the Cardno block-application time, either including or not including verifying transaction signatures and running Plutus scripts.
12+
2. Ideally, `db-analyser` could be modified to report CPU times for phase 1 and phase 2 validation on a per-transaction basis.
13+
3. The output of this tool is quite noisy and does not include enough of the explanatory variable for predicting CPU times for transactions or blocks.
14+
4. The missing explanatory variables (size of UTxO set, number of inputs, number of outputs, etc.) can be extracted from the ledger or `cardano-db-sync`.
15+
5. For transaction signature verification and Plutus script execution, the median times are . . .
16+
- 3.675 μs/tx
17+
- 1.946 μs/kB
18+
- Jointly via a linear model, 7.353 μs/tx plus 1.474 μs/kB.
19+
- Jointly via a linear model, 7.271 μs/tx plus 0.938 μs/kB plus 5.463 μs/Gstep, with a Lapace-distributed error having location 0 μs and scale 145 μs.
20+
6. The noise in the data and the uncertainty in predictions make the above values unsuitable for estimating individual transactions but suitable for bulk estimates of many blocks.
21+
7. A more sophisticated double general linear model could be used to generate artificial transaction workloads.
22+
8. The CPU-timing parameters in the default configuration for Leios simulations could be reduced based on this work.
23+
24+
See [the Jupyter notebook](analysis/timings/ReadMe.ipynb) for evidence and details.
25+
326
## 2025-07-21
427

528
### Generic analysis script for Leios simulator output

analysis/sims/kernels.nix

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -23,6 +23,7 @@
2323
R_utils
2424
stringr
2525
svglite
26+
VGAM
2627
];
2728
};
2829
}

0 commit comments

Comments
 (0)