Validate txs in model #1309
Merged
Validate txs in model #1309
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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-02-19 17:46:41.038023204 UTC Baseline Scenario
Baseline Scenario
|
ch1bo
force-pushed
the
validate-txs-in-model
branch
12 times, most recently
from
4a05bcf to
e1ebdbe
Compare
v0d1ch
force-pushed
the
validate-txs-in-model
branch
from
5acbc45 to
170b35d
Compare
The 'evaluateTx' function used at the core of validating transactions in the MockChain can fail in two ways, once when translating the transaction and then each validator individually.
No idea why, but this seems to shrink less and not invalidating a precondition on one of the model tests.
We added a threadDelay in the performAbort and realised this fixed one of the issues we had, pinpointing the fact that there's some race conditions in the abort logic: It's perfectly possible that a party Aborts while other parties Commited and the Abort fails. We don't model this behaviour for now, but this could be done using "Negative" actions
v0d1ch
force-pushed
the
validate-txs-in-model
branch
from
170b35d to
f7c07b0
Compare
ch1bo
force-pushed
the
validate-txs-in-model
branch
from
bc32477 to
a3c8432
Compare
This will result in less spam on errors, at the cost of creating temp files on each model test failure run.
We need to ensure that the mock chain ledger is already updated with the blocks utxo before invoking the handlers as they might want to submit transactions using this utxo right away. This also uses throwSTM to actually throw an exception and not to error when showing the trace.
Thel MockChain behaves quite different than the real cardano chain interfaced through a cardano-node (see FIXME)
When we want to commit we need to take the utxo that was already pre-seeded for our party and not just some arbitrary value not known to our mock chain.
If two RollbackAndForward actions are generated next to each other then submitTx fails. Waiting for a small amount of time to pass so that the needed utxo is present fixes this problem. Ideally the fix would be: Correctly implemented rollbacks in the mock chain but perhaps this is enough for now.
This reverts commit f976751.
There could be situations with race conditions when multiple RollbackAndForward actions were generated by the model. By using the correct "view" onto the chain, the mock chain can evaluate transactions more consistently.
ch1bo
force-pushed
the
validate-txs-in-model
branch
2 times, most recently
from
1878a26 to
c28b4e5
Compare
Moved and DRYed usage of scriptLedger and introduced function 'collectTransactions' to emulate the dropping transaction behavior as it was already intended before (see comment). As we are checking transactions now on submission and fail there, this is not really needed, but it is more consistent to include only transactions in the mock chain "blocks" which were valid at time of evaluation.
ch1bo
force-pushed
the
validate-txs-in-model
branch
from
c28b4e5 to
b0a91e2
Compare
v0d1ch
approved these changes
Feb 20, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The 'evaluateTx' function used at the core of validating transactions in the MockChain can fail in two ways, once when translating the transaction and then each validator individually.
🔬 The MockChain now evaluates transactions on submission and only includes valid transactions in blocks.
🔬 This also fixes race conditions in MockChain when updating the
chainvariable versus invoking handlers.🔬 Fixes the model in various ways to pass now the transaction checking. Mostly it was requiring every party to observe consequences of an action before having them act.
💡 One situation was very interesting: The tests were finding an issue when a
committransaction was actually observed by the sending node, but another node sending anabortwas not yet valid, because they reimbursed value was not matching. i.e. the aborting node has not yet seen & processed the commit, but the chain included it already. This is actually something that can happen and a user would need to retry here. However we opted to just not model this and instead require every node to observe a commit before continuing.🔬 Improved shrinking on generated actions. This should already reduce error situation complexity, but more work can be done here.
🔬 Some fixes on the test scenarios / dynamic logic properties.
CHANGELOG updated or not needed
Documentation updated or not needed
Haddocks updated or not needed
No new TODOs introduced or explained herafter
XXXabout reworking theMockChainto be more like a real chain (would be too big to be in scope, but this is something we really should do)XXXof adding slot validation to the usedscriptLedger.