-
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
Add a test suite for testing consecutive close/contest transactions #1385
Conversation
These might be too involved, so more targeted generators would be maybe good. At least a shrinker is needed.
This is still generating ConfirmedSnapshots in traces which start with only 'Close'?
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 2024-04-08 07:07:07.132510371 UTC Baseline Scenario
Baseline Scenario
|
Also adds cardano payment key fixtures.
This is using the Hydra.Chain.Direct.State.close as a first draft, but direct usage of Hydra.Chain.Direct.Tx.closeTx should be possible as well. Let's see what is better further down the road.
The fact that all snapshots will be arbitrarily generated and correctly signed, makes it natural to push that out into the perform stage and only keep the snapshot number in the model.
Hemmingway bridge for next time..
Surprisingly this seems to be also wrong without reverting our latest fix!
While both approaches would be fine (and we had it different in the past), this matches the implementation and specification.
TxSpec
, which hooks intoHydra.Chain.Direct.State
transaction creation (i.e.close
andcontest
) functions and ensures created transactions are valid and can be observed (byobserveHeadTx
)close
andcontest
transactionsUTxO
are usedActor
andSnapshotNumber
ofClose
andContest
actions.