Skip to content
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

Merged
merged 7 commits into from
Mar 16, 2020

Conversation

nfrisby
Copy link
Contributor

@nfrisby nfrisby commented Feb 3, 2020

Fixes #1297.

Follow-up: prop_general is accumulating several block/protocol specific arguments; they probably deserve their own record type/class soon.

@nfrisby nfrisby requested review from mrBliss and edsko February 3, 2020 21:02
@nfrisby nfrisby added mempool testing consensus issues related to ouroboros-consensus labels Feb 4, 2020
= DoNotExpire
| ExpireAtOnsetOf !SlotNo
deriving stock (Show, Eq, Ord, Generic)
deriving anyclass (Serialise, NFData, NoUnexpectedThunks)
Copy link
Contributor

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?

Copy link
Contributor Author

@nfrisby nfrisby Feb 4, 2020

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?)

mrBliss added a commit that referenced this pull request Feb 10, 2020
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.
mrBliss added a commit that referenced this pull request Feb 10, 2020
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.
mrBliss added a commit that referenced this pull request Feb 10, 2020
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.
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]>
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]>
@nfrisby nfrisby force-pushed the nfrisby/issue-1297-tx-ttl branch 3 times, most recently from ed7217f to 8c20fd4 Compare March 9, 2020 17:24
Copy link
Contributor

@mrBliss mrBliss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

reapplyTx = const updateSimpleUTxO
applyTx = reapplyTx
reapplyTx _ tx tl =
case hasExpired of
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

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 🙂

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed it into the ledger rules. I introduced the Ticked type used in a few modules; should it be renamed and/or located somewhere more general? I think of it (as commented) as a generalization of TickedLedgerState. @edsko @mrBliss

@nfrisby
Copy link
Contributor Author

nfrisby commented Mar 10, 2020

The latest CI failure was due to the unrelated #1779.

@nfrisby nfrisby force-pushed the nfrisby/issue-1297-tx-ttl branch 2 times, most recently from 0c59660 to df3c264 Compare March 10, 2020 19:17
@nfrisby
Copy link
Contributor Author

nfrisby commented Mar 10, 2020

I think this is ready for merge, unless you'd like to see changes to the following.

  • the way I pushed the logic further into the ledger rule code
  • the Ticked type I used to do so

If not, I think this is ready for bors.

Copy link
Contributor

@edsko edsko left a 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.

@nfrisby nfrisby force-pushed the nfrisby/issue-1297-tx-ttl branch from df3c264 to 2926f99 Compare March 11, 2020 15:39
@nfrisby
Copy link
Contributor Author

nfrisby commented Mar 11, 2020

@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 Ticked.

In order to relocate the check, I also simplified HasUtxo to HasTxs -- I need to access the actual Txs in order to check them for expiry. Is this too much of a concretization? I suppose I could add something about expiry to HasUtxo, but this simplification seems fine in the mock ledger code.

@nfrisby nfrisby requested a review from edsko March 11, 2020 16:37
@nfrisby nfrisby force-pushed the nfrisby/issue-1297-tx-ttl branch from 2926f99 to c2c0431 Compare March 12, 2020 17:15
@nfrisby
Copy link
Contributor Author

nfrisby commented Mar 12, 2020

I just now rebased onto origin/master.

@nfrisby nfrisby force-pushed the nfrisby/issue-1297-tx-ttl branch from c2c0431 to 1331935 Compare March 12, 2020 18:28
@nfrisby
Copy link
Contributor Author

nfrisby commented Mar 12, 2020

I just now rebased onto origin/bors/staging, to address the conflicts from the new PropGeneralArgs.

@nfrisby nfrisby force-pushed the nfrisby/issue-1297-tx-ttl branch from 1331935 to a0875cf Compare March 13, 2020 13:51
@nfrisby
Copy link
Contributor Author

nfrisby commented Mar 13, 2020

I rebased on origin/master.

@nfrisby nfrisby force-pushed the nfrisby/issue-1297-tx-ttl branch from a0875cf to e3767e2 Compare March 16, 2020 14:19
@nfrisby
Copy link
Contributor Author

nfrisby commented Mar 16, 2020

Update: I addressed the comments and rebased onto master.

@nfrisby
Copy link
Contributor Author

nfrisby commented Mar 16, 2020

bors r+

@iohk-bors
Copy link
Contributor

iohk-bors bot commented Mar 16, 2020

@iohk-bors iohk-bors bot merged commit 742c5a4 into master Mar 16, 2020
@iohk-bors iohk-bors bot deleted the nfrisby/issue-1297-tx-ttl branch March 16, 2020 16:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
consensus issues related to ouroboros-consensus mempool testing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Test that we use the right slot number for transaction validation throughout
3 participants