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

Automatically verify transactions in blocks when the same transaction is already in the mempool #5674

Closed
Tracked by #5234 ...
teor2345 opened this issue Nov 21, 2022 · 2 comments · Fixed by #8951
Closed
Tracked by #5234 ...
Assignees
Labels
A-rpc Area: Remote Procedure Call interfaces I-slow Problems with performance or responsiveness

Comments

@teor2345
Copy link
Contributor

teor2345 commented Nov 21, 2022

Motivation

Miners need RPCs and verification to be fast, to improve profits.

When Zebra has already verified a transaction in the mempool, we know it will be valid in a block. (The mempool checks are stricter than the block transaction checks.)

So we can save time by automatically approving any block transaction verify requests that match a transaction already in the mempool.

Security

We will need to test that the mempool checks are stricter than the block transaction checks. Otherwise, we could approve invalid blocks.

@teor2345 teor2345 added I-slow Problems with performance or responsiveness P-Optional ✨ A-rpc Area: Remote Procedure Call interfaces labels Nov 21, 2022
@mpguerra mpguerra moved this to ✅ Done in Zebra Jan 24, 2023
@mpguerra mpguerra added this to Zebra Jan 24, 2023
@mpguerra mpguerra moved this from ✅ Done to 🆕 New in Zebra Jan 24, 2023
@teor2345 teor2345 changed the title Automatically verify transactions that are already in the mempool Automatically verify transactions in blocks when the same transaction is already in the mempool Apr 4, 2023
@daira
Copy link
Contributor

daira commented Aug 19, 2024

This only applies to non-contextual checks, right? Otherwise you have the following condition:

  • UTXO $u$ is not spent as of the current tip, and so a transaction $tx$ that spends $u$ can be accepted.
  • A block $B$ is mined that spends $u$ in a different transaction $tx'$, that the zebra node never accepted to the mempool.
  • Now $tx$ cannot be mined.

The same can happen for nullifiers, and for any other contextual check (e.g. mempool transactions can expire, etc.) It's fine as long as mining $B$ kicks $tx$ out of the mempool and there is no possible race condition.

@daira
Copy link
Contributor

daira commented Aug 19, 2024

Ah, it sounds as though that was considered in #5376 (comment) .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-rpc Area: Remote Procedure Call interfaces I-slow Problems with performance or responsiveness
Projects
Status: Done
4 participants