-
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
Incremental commits off-chain #1541
Conversation
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 | 5096 | 5.61 | 2.21 | 0.44 |
2 | 5298 | 7.18 | 2.84 | 0.46 |
3 | 5498 | 8.37 | 3.30 | 0.48 |
5 | 5902 | 11.39 | 4.51 | 0.53 |
10 | 6906 | 18.02 | 7.12 | 0.65 |
57 | 16355 | 83.00 | 32.84 | 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.52 | 4.15 | 0.29 |
2 | 759 | 13.86 | 5.65 | 0.34 |
3 | 947 | 17.33 | 7.20 | 0.38 |
5 | 1314 | 24.65 | 10.44 | 0.48 |
10 | 2256 | 45.22 | 19.36 | 0.75 |
20 | 4119 | 95.99 | 40.76 | 1.40 |
CollectCom
transaction costs
Parties | UTxO (bytes) | Tx size | % max Mem | % max CPU | Min fee ₳ |
---|---|---|---|---|---|
1 | 57 | 560 | 21.46 | 8.41 | 0.41 |
2 | 114 | 671 | 32.17 | 12.77 | 0.53 |
3 | 170 | 782 | 44.16 | 17.72 | 0.67 |
4 | 227 | 893 | 62.79 | 25.25 | 0.88 |
5 | 282 | 1004 | 77.71 | 31.50 | 1.05 |
6 | 338 | 1116 | 93.56 | 38.24 | 1.23 |
Cost of Decrement Transaction
Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
---|---|---|---|---|
1 | 646 | 17.73 | 7.85 | 0.38 |
2 | 779 | 19.31 | 9.24 | 0.41 |
3 | 898 | 20.67 | 10.54 | 0.43 |
5 | 1254 | 24.89 | 13.71 | 0.51 |
10 | 2052 | 32.66 | 20.52 | 0.65 |
50 | 8080 | 98.06 | 76.82 | 1.85 |
Close
transaction costs
Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
---|---|---|---|---|
1 | 653 | 20.15 | 9.09 | 0.41 |
2 | 788 | 21.54 | 10.52 | 0.43 |
3 | 1034 | 23.92 | 12.68 | 0.48 |
5 | 1234 | 26.44 | 15.22 | 0.53 |
10 | 2004 | 34.35 | 23.04 | 0.68 |
49 | 7659 | 95.52 | 82.85 | 1.86 |
Contest
transaction costs
Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
---|---|---|---|---|
1 | 671 | 25.93 | 11.19 | 0.47 |
2 | 815 | 27.77 | 12.77 | 0.50 |
3 | 947 | 29.50 | 14.31 | 0.53 |
5 | 1428 | 34.69 | 18.80 | 0.63 |
10 | 2032 | 43.14 | 26.22 | 0.78 |
39 | 6464 | 98.62 | 75.05 | 1.77 |
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 | 4972 | 17.52 | 7.62 | 0.57 |
2 | 5157 | 29.28 | 12.91 | 0.71 |
3 | 5207 | 41.39 | 18.25 | 0.85 |
4 | 5331 | 57.16 | 25.26 | 1.03 |
5 | 5615 | 78.89 | 35.17 | 1.29 |
6 | 5650 | 97.11 | 43.26 | 1.50 |
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 ₳ |
---|---|---|---|---|---|---|
5 | 0 | 0 | 4935 | 7.71 | 3.26 | 0.45 |
5 | 1 | 57 | 4968 | 8.64 | 3.89 | 0.47 |
5 | 5 | 285 | 5104 | 13.76 | 6.99 | 0.54 |
5 | 10 | 569 | 5273 | 19.22 | 10.46 | 0.61 |
5 | 20 | 1140 | 5614 | 30.34 | 17.49 | 0.77 |
5 | 30 | 1709 | 5955 | 41.66 | 24.61 | 0.93 |
5 | 40 | 2277 | 6293 | 53.47 | 31.94 | 1.09 |
5 | 50 | 2846 | 6633 | 64.12 | 38.78 | 1.24 |
5 | 81 | 4605 | 7679 | 99.09 | 60.82 | 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 14:55:54.466747739 UTC
Baseline Scenario
Number of nodes | 1 |
---|---|
Number of txs | 3000 |
Avg. Confirmation Time (ms) | 4.946512714 |
P99 | 8.004050609999991ms |
P95 | 6.122482349999996ms |
P50 | 4.6671890000000005ms |
Number of Invalid txs | 0 |
Three local nodes
Number of nodes | 3 |
---|---|
Number of txs | 9000 |
Avg. Confirmation Time (ms) | 22.970043740 |
P99 | 115.73477167ms |
P95 | 29.303824249999998ms |
P50 | 20.578107ms |
Number of Invalid txs | 0 |
235acca
to
273fe91
Compare
53b33e9
to
8d8d3a3
Compare
@noonio When we continue work here, we should take a step back again given the new overall design of #199 with details from #1571. The overall off-chain story has not changed much, but is basically separated in two parts:
|
7ea2e9f
to
e63ca63
Compare
8c0728e
to
a39f11a
Compare
4501071
to
40fe8bc
Compare
This also enables re-enables observation properties of Deposit/Recover transitions. We note though, that these are not "real" head state transitions and the ctx / state return values are superficial.
This makes it easier to use in combination with observing a deposit.
Remove deposit and recover from the Head tx observation tests and have dedicated tests for deposit/recover.
Make sure to check if the deposit datum actually contains the deposit tx inputs. Remove the `utxo` from `DepositObservation` and propagate this change. Increment observation is broken now since it was depending on this utxo but we need to do it differently any way.
Added TxInType since we needed abstract type for use in head logic. Ideally I would not try to find utxo in the map but deal with txin/id only on increment/recover
If we have this type around it will serve us well for deleting observed deposits and also on recovers.
On increment the UTxO we are incrementing is not part of the head UTxO yet so we need more information in order to be able to observe the relevant transaction.
60e5e3b
to
efe7083
Compare
- Add documentation to explain the feature | ||
- Implement tests scenarios outlined in the [incremental-commit] (https://github.com/cardano-scaling/hydra/issues/199) issue | ||
- Remove Commit client input since it is unused | ||
- Revisit types related to observations/posting transactions and make sure the fields are named appropriatelly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️
❄️ This PR implements most of the off-chain changes we need for the incremental commits to work. Since there are many changes we decided to have a series of follow up PRs to finally conclude the wanted feature.
Included:
Relevant code to be able to do full end-to-end test for depositing (and recovering) a user UTxO into a running Head.
This means:
❄️ everything needed to accept user requests at the API level
❄️ build off-chain transactions (deposit, recover, increment)
❄️ observe new transactions (deposit, recover and increment)
❄️ changes in the
Snapshot
type and all other relevant types and functions to accommodate this new feature❄️ minimal needed changes in the on-chain code (validators just return True so once this is merged we will not be able to release until this gap is implemented)
Outstanding:
❄️ documentation - Write up some documentation to explain how incremental commits are working
❄️ Various tests described in the original issue and which are relevant to the off-chain code
❄️ Make the increment/recover use the observed UTxO instead of keeping those around
❄️ Remove
Commit
client input since it is not used❄️ Revisit the observation/transaction posting types and make sure the field names make sense
❄️ Determine what should be good enough deadline for a deposit transaction (should we make it configurable or rely on the contestation deadline)