-
Notifications
You must be signed in to change notification settings - Fork 88
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
Calculate min utxo value #1176
Calculate min utxo value #1176
Conversation
Transactions CostsSizes and execution budgets for Hydra protocol transactions. Note that unlisted parameters are currently using
Script summary
Cost of Init Transaction
Cost of Commit TransactionThis is using ada-only outputs for better comparability.
Cost of CollectCom Transaction
Cost of Close Transaction
Cost of Contest Transaction
Cost of Abort TransactionSome variation because of random mixture of still initial and already committed outputs.
Cost of FanOut TransactionInvolves spending head output and burning head tokens. Uses ada-only UTxO for better comparability.
End-To-End Benchmark ResultsThis page is intended to collect the latest end-to-end benchmarks results produced by Hydra's Continuous Integration system from the latest Please take those results with a grain of salt as they are currently produced from very limited cloud VMs and not controlled hardware. Instead of focusing on the absolute results, the emphasis should be on relative results, eg. how the timings for a scenario evolve as the code changes. Generated at 2023-11-23 10:15:39.912574073 UTC 3-nodes ScenarioA rather typical setup, with 3 nodes forming a Hydra head.
Baseline ScenarioThis scenario represents a minimal case and as such is a good baseline against which to assess the overhead introduced by more complex setups. There is a single hydra-node d with a single client submitting single input and single output transactions with a constant UTxO set of 1.
|
forAll arbitrary $ \txOut -> do | ||
let txOutWithoutADA = txOut & coinTxOutL .~ mempty | ||
let newTx = tx & bodyTxL . outputsTxBodyL <>~ StrictSeq.singleton txOutWithoutADA | ||
case coverFee_ Fixture.pparams Fixture.systemStart Fixture.epochInfo lookupUTxO walletUTxO newTx of |
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.
With the Fixture.
prefix, this looks cluttered, perhaps a good time to group those parameters together?
lockedValue == initialValue + committedValue | ||
-- NOTE: Ada in initialValue is usually lower than in the locked ADA due | ||
-- to higher deposit needed for commit output than for initial output | ||
lockedValue `geq` (initialValue + committedValue) |
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.
I did not see a change to the Commit
mutations exposing this, am I missing something?
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.
The healthy case will fail with == now.
Avoiding the hard-coded value reduces the locked funds to a minimum and makes transaction creation functions more flexible.
Using the cardano-ledger-api we can easily modify the transaction outputs to hold enough ADA to satisfy ledger rules.
This is needed as the locked ada might be lower on the spending side than on the producing side due to min utxo value deposits.
This is crucial for most of the hydra protocol transactions as we actively capture value in the outputs!
Co-authored-by: Arnaud Bailly <[email protected]> Co-authored-by: Sasha Bogicevic <[email protected]>
26f3485
to
1b7e1f6
Compare
Test Results369 tests +1 364 ✔️ +1 21m 40s ⏱️ -19s Results for commit 1b7e1f6. ± Comparison against base commit d411872. This pull request removes 1 and adds 2 tests. Note that renamed tests count towards both.
|
Alternative to Bump hardcoded deposit of script outputs to 2.2 #1175
BREAKING changes initial script as it was checking for equality, but we have now non-constant ADA between spending and producing side of the
commitTx
, even if we commit nothing.Updated the specification with to match this interpretation (unclear if$\supset$ or $>=$ is better used there?)
Some modifications to the healthy commit mutation case to simulate this situation.