-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use aiken for commit validator #1680
Conversation
bae8866
to
38e1743
Compare
7bafe31
to
296395c
Compare
9d5ca8d
to
27b506b
Compare
We intend to create one of the hydra-plutus scripts with aiken.
This separates the aiken build, which yields the plutus.json blueprint and the haskell build which provides access to the compiled validators.
Instead of using the plutus-tx "compiledScript", we use the loaded-from-blueprint aiken script in the init validator and when constructing/observing transactions in the hydra-node.
This is not yet working and it does not correctly detect changes to plutus.json
Plutus-tx seems to be encoding tuples as a Constr on-chain.
Also add TODO comments for things that are missing to be removed.
Seems like the aiken compiler uses plutus core version 1.1.0 syntax and we need to declare it as a PlutusV3 script.
We do not need the plutus-style envelope and this would not match with the PlutusV2 used there.
This will keep the first trace argument which we expect to see in our mutation tests.
27b506b
to
5dee79a
Compare
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 | 5097 | 5.81 | 2.30 | 0.44 |
2 | 5298 | 7.09 | 2.80 | 0.46 |
3 | 5502 | 8.56 | 3.39 | 0.49 |
5 | 5901 | 11.32 | 4.48 | 0.53 |
10 | 6906 | 18.02 | 7.12 | 0.65 |
57 | 16353 | 82.89 | 32.79 | 1.78 |
Commit
transaction costs
This uses ada-only outputs for better comparability.
UTxO | Tx size | % max Mem | % max CPU | Min fee ₳ |
---|---|---|---|---|
1 | 569 | 10.84 | 4.26 | 0.29 |
2 | 756 | 14.31 | 5.80 | 0.34 |
3 | 942 | 17.92 | 7.39 | 0.39 |
5 | 1316 | 25.56 | 10.73 | 0.49 |
10 | 2254 | 47.11 | 19.97 | 0.77 |
19 | 3951 | 94.71 | 39.81 | 1.38 |
CollectCom
transaction costs
Parties | UTxO (bytes) | Tx size | % max Mem | % max CPU | Min fee ₳ |
---|---|---|---|---|---|
1 | 57 | 560 | 19.87 | 7.59 | 0.39 |
2 | 114 | 671 | 28.85 | 10.97 | 0.49 |
3 | 170 | 786 | 37.67 | 14.32 | 0.59 |
4 | 227 | 893 | 41.33 | 15.76 | 0.64 |
5 | 281 | 1004 | 48.49 | 18.48 | 0.72 |
6 | 339 | 1120 | 61.07 | 23.20 | 0.86 |
7 | 394 | 1227 | 75.79 | 28.74 | 1.02 |
8 | 448 | 1338 | 82.50 | 31.32 | 1.10 |
9 | 504 | 1449 | 83.79 | 31.89 | 1.12 |
10 | 560 | 1560 | 92.85 | 35.30 | 1.22 |
Cost of Decrement Transaction
Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
---|---|---|---|---|
1 | 625 | 18.64 | 8.15 | 0.39 |
2 | 723 | 18.46 | 8.82 | 0.39 |
3 | 981 | 22.44 | 11.17 | 0.46 |
5 | 1121 | 22.68 | 12.79 | 0.48 |
10 | 2135 | 34.80 | 21.37 | 0.68 |
49 | 7919 | 97.72 | 75.96 | 1.84 |
Close
transaction costs
Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
---|---|---|---|---|
1 | 664 | 20.83 | 9.32 | 0.42 |
2 | 741 | 21.93 | 10.44 | 0.44 |
3 | 956 | 24.07 | 12.49 | 0.48 |
5 | 1349 | 27.79 | 16.08 | 0.55 |
10 | 2059 | 35.85 | 23.85 | 0.70 |
50 | 7850 | 97.75 | 84.99 | 1.90 |
Contest
transaction costs
Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
---|---|---|---|---|
1 | 680 | 26.77 | 11.46 | 0.48 |
2 | 860 | 28.98 | 13.38 | 0.52 |
3 | 1021 | 30.60 | 14.88 | 0.55 |
5 | 1277 | 34.23 | 18.03 | 0.61 |
10 | 2094 | 44.47 | 26.95 | 0.80 |
39 | 6483 | 99.14 | 75.26 | 1.78 |
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 | 4984 | 15.34 | 6.57 | 0.54 |
2 | 5049 | 21.29 | 9.07 | 0.61 |
3 | 5214 | 26.49 | 11.36 | 0.68 |
4 | 5251 | 29.50 | 12.48 | 0.71 |
5 | 5548 | 41.79 | 18.29 | 0.86 |
6 | 5591 | 46.04 | 19.90 | 0.91 |
7 | 5828 | 54.16 | 23.59 | 1.01 |
8 | 5921 | 64.24 | 27.96 | 1.13 |
9 | 6098 | 67.40 | 29.46 | 1.18 |
10 | 6202 | 78.14 | 34.10 | 1.30 |
11 | 6262 | 81.87 | 35.58 | 1.34 |
12 | 6465 | 91.45 | 39.92 | 1.46 |
13 | 6557 | 93.05 | 40.39 | 1.48 |
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 | 5090 | 9.79 | 4.09 | 0.48 |
10 | 1 | 57 | 5124 | 11.35 | 4.98 | 0.50 |
10 | 5 | 284 | 5258 | 15.63 | 7.71 | 0.56 |
10 | 10 | 569 | 5428 | 21.56 | 11.36 | 0.65 |
10 | 20 | 1137 | 5767 | 33.75 | 18.81 | 0.81 |
10 | 30 | 1707 | 6109 | 45.04 | 25.88 | 0.97 |
10 | 40 | 2275 | 6447 | 56.93 | 33.20 | 1.13 |
10 | 50 | 2849 | 6790 | 68.83 | 40.53 | 1.30 |
10 | 77 | 4384 | 7704 | 99.85 | 59.86 | 1.73 |
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 2024-10-04 18:08:54.574052356 UTC
Baseline Scenario
Number of nodes | 1 |
---|---|
Number of txs | 3000 |
Avg. Confirmation Time (ms) | 4.907318410 |
P99 | 11.039467829999907ms |
P95 | 6.361053499999997ms |
P50 | 4.2919015ms |
Number of Invalid txs | 0 |
Three local nodes
Number of nodes | 3 |
---|---|
Number of txs | 9000 |
Avg. Confirmation Time (ms) | 23.495834438 |
P99 | 114.87703296000002ms |
P95 | 30.58308695ms |
P50 | 20.973222ms |
Number of Invalid txs | 0 |
This does not require us to be in a git repository and hence makes the test more flexible and isolated.
The hydra-plutus library seems to be consistently rebuilt when the plutus.json gets changed.
This was failing with PPViewHashesDontMatch because the transaction was referencing the commit script which is does not always need, and the commit script being of different version than the other scripts spent.
5dee79a
to
f9e07ce
Compare
Test Results518 tests ±0 512 ✅ ±0 32m 38s ⏱️ + 9m 28s Results for commit 665cc17. ± Comparison against base commit d3db623. This pull request removes 1 and adds 1 tests. Note that renamed tests count towards both.
|
Addresses #1543 and tests whether IntersectMBO/cardano-api#632 results in `GET /snapshot/utxo` to contain `inlineDatumRaw`. Bonus: First step on consolidating `TxOut` and `UTxO` generators (deduplicating and moving them to a common module) TODO: Somehow get IntersectMBO/cardano-api@17eb46f into this branch. Most likely requiring #1680 (which updates to most recent `cardano-api` release `9.30`) and a `source-repository-package` onto some unreleased cardano-api. --- * [x] CHANGELOG updated or not needed * [x] Documentation updated or not needed * [x] Haddocks updated or not needed * [x] No new TODOs introduced or explained herafter
We want to update to a recent
cardano-api
version to get #1543 (which we contributed upstream). This update implied a bump onplutus-tx
(via the ledger) and resulted in growing script sizes. At that point we explored various ways to decrease the script size again to keep the single transaction publishing and--hydra-scripts-tx-id
config (or even expanding that).This mikado / dependency graph shows our option and the chosen path of this PR:
Concretely this PR contains:
Update to
cardano-api
version9.3
Rebased and updated to latest
aiken
the commit validator from this work: Aiken: commit validator #1072Support
PlutusV3
validators next to legacyPlutusV2
validators (the aiken one is V3)Consequences of switching to
aiken
: