-
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
Add optional expiry slot to Mock transactions #1564
Conversation
= DoNotExpire | ||
| ExpireAtOnsetOf !SlotNo | ||
deriving stock (Show, Eq, Ord, Generic) | ||
deriving anyclass (Serialise, NFData, NoUnexpectedThunks) |
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.
Why is NFData
(and that orphan) needed?
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.
Tx
derives it, and Expiry
occurs in Tx
. I didn't question why Tx
derives it. (For the Tx
pattern synonym, I suppose. Which uses force
in order to have actual strictness of the [TxOut]
argument, I guess?)
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.
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.
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.
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]>
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]>
ed7217f
to
8c20fd4
Compare
ouroboros-consensus/ouroboros-consensus-mock/test/Test/ThreadNet/TxGen/Mock.hs
Outdated
Show resolved
Hide resolved
8c20fd4
to
99b2c2b
Compare
99b2c2b
to
e06dc41
Compare
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.
LGTM
ouroboros-consensus/ouroboros-consensus-mock/test/Test/ThreadNet/BFT.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus/ouroboros-consensus-mock/test/Test/ThreadNet/TxGen/Mock.hs
Outdated
Show resolved
Hide resolved
reapplyTx = const updateSimpleUTxO | ||
applyTx = reapplyTx | ||
reapplyTx _ tx tl = | ||
case hasExpired 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.
I see CI is failing with a test related to tx/block validation. I believe you also have to take transaction expiration into account when validating blocks (applyLedgerBlock
). You can move the expiration logic to some common place.
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.
It shouldn't live in applyTx
or applyLedgerBlock
, but rather in the ledger rules.
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.
See Lemma 3 in #1765 🙂
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 latest CI failure was due to the unrelated #1779. |
0c59660
to
df3c264
Compare
I think this is ready for merge, unless you'd like to see changes to the following.
If not, I think this is ready for |
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 must admit I am not a fan of the Ticked
data type. Ticking a ledger state is something quite specific: apply ledger rules that advance the ledger state by time (update delegation state, swap out stake distribution, etc.). I don't know what a "ticket transaction" is, and I also don't really understand why we need a new concept. Perhaps we should discuss.
df3c264
to
2926f99
Compare
@edsko and I had a call. He pointed out a slightly higher-level location in which to check for expiry. Moving it there let me remove In order to relocate the check, I also simplified |
2926f99
to
c2c0431
Compare
I just now rebased onto |
c2c0431
to
1331935
Compare
I just now rebased onto |
1331935
to
a0875cf
Compare
I rebased on |
ouroboros-consensus/ouroboros-consensus-mock/test/Test/ThreadNet/BFT.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus/ouroboros-consensus-mock/src/Ouroboros/Consensus/Mock/Ledger/UTxO.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus/ouroboros-consensus-mock/src/Ouroboros/Consensus/Mock/Ledger/State.hs
Outdated
Show resolved
Hide resolved
a0875cf
to
e3767e2
Compare
Update: I addressed the comments and rebased onto master. |
bors r+ |
Fixes #1297.
Follow-up:
prop_general
is accumulating several block/protocol specific arguments; they probably deserve their own record type/class soon.