Mempool: better revalidation and caching of the ledger state #1599
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
mrBliss
commented
Feb 6, 2020
intricate
reviewed
Feb 7, 2020
mrBliss
force-pushed
the
mrBliss/fix-1565
branch
from
ec4ac88 to
51a85fc
Compare
mrBliss
force-pushed
the
mrBliss/fix-1565
branch
from
51a85fc to
2a6f5c7
Compare
mrBliss
changed the title
mrBliss
force-pushed
the
mrBliss/fix-1565
branch
from
2a6f5c7 to
14f0906
Compare
mrBliss
force-pushed
the
mrBliss/fix-1565
branch
from
14f0906 to
146187f
Compare
This was referenced Feb 10, 2020
mrBliss
force-pushed
the
mrBliss/fix-1565
branch
3 times, most recently
from
93332d5 to
31fff9c
Compare
mrBliss
commented
Feb 10, 2020
mrBliss
force-pushed
the
mrBliss/fix-1565
branch
from
ff9d849 to
2f7b7a7
Compare
intricate
reviewed
Feb 10, 2020
mrBliss
force-pushed
the
mrBliss/fix-1565
branch
from
2f7b7a7 to
ff1ff9d
Compare
intricate
reviewed
Feb 10, 2020
| validationErrorImpossible $ | ||
| applyByronGenTx validationMode cfg tx st | ||
| where | ||
| validationMode = CC.ValidationMode CC.NoBlockValidation Utxo.NoTxValidation |
There was a problem hiding this comment.
Does this mean that we no longer need the NoTxValidation mode in cardano-ledger?
There was a problem hiding this comment.
Indeed not. @edsko and I have been looking for a ticket about this (that we could close), but we couldn't find it. Do you know which one that would be?
There was a problem hiding this comment.
I'm not sure that there has been a ticket in ledger that specifically speaks to removing NoTxValidation.
Using the `Mock.Utxo` instead of the overly simplistic `TestTx` we were using allows for more complicated dependencies between transactions. This better resembles the real transactions, at the cost of some complexity. Moreover, using the new transaction type reveals a bug that was not visible with the previous transaction type, i.e., #1565.
mrBliss
force-pushed
the
mrBliss/fix-1565
branch
from
ff1ff9d to
4ed6801
Compare
mrBliss
force-pushed
the
mrBliss/fix-1565
branch
from
4ed6801 to
2c9c10c
Compare
intricate
approved these changes
Feb 10, 2020
|
bors r+ |
iohk-bors bot
added a commit
that referenced
this pull request
Feb 10, 2020
1599: Mempool: better revalidation and caching of the ledger state r=mrBliss a=mrBliss Fixes #1565 and #1301. * Replace `Mempool.addTxs` with `Mempool.tryAddTxs`, which doesn't block. This function will be much easier to test. We provide an implementation of `Mempool.addTxs` in terms of `Mempool.tryAddTxs`. We simplify the implementations by relying on the background thread for synchronising the Mempool with an updated ledger state. * Cache the `TickedLedgerState` after applying all transactions in the Mempool to it (#1301). Previously, we had to reapply all transactions whenever we added a new transaction. The new approach is much faster. * As we're keeping the `TickedLedgerState` in memory, make sure it is thunk-free. * Correct revalidation in (#1564) after explicitly removing transactions from the Mempool, see `revalidateTxsFor`. * Cleanup of conversion functions in `TxSeq`. * O(1) `MempoolSize` calculation for a `TxSeq` using its fingertree measure. Also includes a rewrite of the Mempool tests using the `Mock.Utxo`. Using the `Mock.Utxo` instead of the overly simplistic `TestTx` we were using allows for more complicated dependencies between transactions. This better resembles the real transactions, at the cost of some complexity. With the former transaction type, we weren't even able to trigger #1565. Co-authored-by: Thomas Winant <[email protected]>
|
bors r- |
Canceled |
Fixes #1565 and #1301. * Replace `Mempool.addTxs` with `Mempool.tryAddTxs`, which doesn't block. This function will be much easier to test. We provide an implementation of `Mempool.addTxs` in terms of `Mempool.tryAddTxs`. We simplify the implementations by relying on the background thread for synchronising the Mempool with an updated ledger state. * Cache the `TickedLedgerState` after applying all transactions in the Mempool to it (#1301). Previously, we had to reapply all transactions whenever we added a new transaction. The new approach is much faster. * As we're keeping the `TickedLedgerState` in memory, make sure it is thunk-free. * Correct revalidation in (#1565) after explicitly removing transactions from the Mempool, see `revalidateTxsFor`. * Cleanup of conversion functions in `TxSeq`. * O(1) `MempoolSize` calculation for a `TxSeq` using its fingertree measure.
This was failing the tests with thunk checking enabled (`-fchecktvarinvariant`).
mrBliss
force-pushed
the
mrBliss/fix-1565
branch
from
2c9c10c to
064ce45
Compare
|
bors r+ |
iohk-bors bot
added a commit
that referenced
this pull request
Feb 10, 2020
1599: Mempool: better revalidation and caching of the ledger state r=mrBliss a=mrBliss Fixes #1565 and #1301. * Replace `Mempool.addTxs` with `Mempool.tryAddTxs`, which doesn't block. This function will be much easier to test. We provide an implementation of `Mempool.addTxs` in terms of `Mempool.tryAddTxs`. We simplify the implementations by relying on the background thread for synchronising the Mempool with an updated ledger state. * Cache the `TickedLedgerState` after applying all transactions in the Mempool to it (#1301). Previously, we had to reapply all transactions whenever we added a new transaction. The new approach is much faster. * As we're keeping the `TickedLedgerState` in memory, make sure it is thunk-free. * Correct revalidation in (#1564) after explicitly removing transactions from the Mempool, see `revalidateTxsFor`. * Cleanup of conversion functions in `TxSeq`. * O(1) `MempoolSize` calculation for a `TxSeq` using its fingertree measure. Also includes a rewrite of the Mempool tests using the `Mock.Utxo`. Using the `Mock.Utxo` instead of the overly simplistic `TestTx` we were using allows for more complicated dependencies between transactions. This better resembles the real transactions, at the cost of some complexity. With the former transaction type, we weren't even able to trigger #1565. Co-authored-by: Thomas Winant <[email protected]>
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.
Fixes #1565 and #1301.
Replace
Mempool.addTxswithMempool.tryAddTxs, which doesn't block. This function will be much easier to test. We provide an implementation ofMempool.addTxsin terms ofMempool.tryAddTxs. We simplify the implementations by relying on the background thread for synchronising the Mempool with an updated ledger state.Cache the
TickedLedgerStateafter applying all transactions in the Mempool to it (Mempool should cache "final ledger state" #1301). Previously, we had to reapply all transactions whenever we added a new transaction. The new approach is much faster.As we're keeping the
TickedLedgerStatein memory, make sure it is thunk-free.Correct revalidation in (Add optional expiry slot to Mock transactions #1564) after explicitly removing transactions from the Mempool, see
revalidateTxsFor.Cleanup of conversion functions in
TxSeq.O(1)
MempoolSizecalculation for aTxSequsing its fingertree measure.Also includes a rewrite of the Mempool tests using the
Mock.Utxo. Using theMock.Utxoinstead of the overly simplisticTestTxwe were using allows for more complicated dependencies between transactions. This better resembles the real transactions, at the cost of some complexity. With the former transaction type, we weren't even able to trigger #1565.