-
Notifications
You must be signed in to change notification settings - Fork 113
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
fix(consensus): Avoid a concurrency bug when verifying transactions in blocks that are already present in the mempool #9118
Conversation
Is this the issue that was reported in Sentry? |
Yep, the issue was that dependencies of transactions in the mempool aren't cleared until they've been committed to the best chain, but there could be multiple blocks being validated in parallel while the mempool is enabled, so the tx verifier needs to wait for those UTXOs as it would if the transaction hadn't already been verified for the mempool. |
Sentry Issue: ZEBRAD-T |
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.
Do I understand it right that the tx dependencies must always originate from the mempool but can be moved to the state by the time we try to check if a tx can depend on them? In that case, should we update these docs: https://github.com/zcashfoundation/zebra/blob/2293cda36dfc74fe0200ff0682f4d2dc75e29881/zebra-node-services/src/mempool/transaction_dependencies.rs#L10-L19?
Should we also update this documentation: https://github.com/zcashfoundation/zebra/blob/2293cda36dfc74fe0200ff0682f4d2dc75e29881/zebra-state/src/request.rs#L691?
…where instead of returning an error when a transaction in a candidate block has already been verified in the mempool
…requests time out
2293cda
to
97a1c40
Compare
Yep, tx dependencies are added when validating mempool txs with spends that are missing in the state but available in the mempool, and they're removed when transactions are mined onto the best chain, or if the mempool is reset. I've added a note to hint that the transaction verifier will need to wait for UTXOs to arrive in the state as well. I think it could still be much clearer if you have any suggestions. |
Motivation
This PR fixes a bug in
find_verified_unmined_tx()
where aTransparentInputNotFound
is returned if a transaction's dependencies are missing from the block containing it. The mempool removes any transaction ids mined onto the best chain from its transaction dependencies, but it's possible for a transaction to depend on outputs that aren't in the same block or in the state, but elsewhere in the verification pipeline waiting to be contextually validated.Solution
Wait for the UTXOs to arrive in the state instead of returning an error when a transaction's dependencies in the mempool are unavailable in the block.
Related changes:
TransparentInputNotFound
errors from tx verifier instead ofInternalDowncastErrors
whenAwaitUtxo
requests timeout, andtry_find_verified_unmined_tx
tofind_verified_unmined_tx
Tests
Updates the
skips_verification_of_block_transactions_in_mempool
test to check that the tx verifier falls back on waiting for UTXOs to arrive in the state service if a transaction's dependencies are missing from its block.PR Author's Checklist
PR Reviewer's Checklist