Transaction verifier structure #1173
Conversation
88503c0 to
84d2abd
Compare
|
One issue that we should fix is the duplication in error types. The |
|
Hmm, it looks like the error type duplication is pre-existing to this PR: there's |
| //! Zebra's implementation of the Zcash consensus rules is oriented | ||
| //! around three telescoping notions of validity: | ||
| //! | ||
| //! 1. *Structural Validity*, or whether the format and structure of the | ||
| //! object are valid. For instance, Sprout-on-BCTV14 proofs are not | ||
| //! allowed in version 4 transactions, and a transaction with a spend | ||
| //! or output description must include a binding signature. | ||
| //! | ||
| //! 2. *Semantic Validity*, or whether the object could potentially be | ||
| //! valid, depending on the chain state. For instance, a transaction | ||
| //! that spends a UTXO must supply a valid unlock script; a shielded | ||
| //! transaction must have valid proofs, etc. | ||
| //! | ||
| //! 3. *Contextual Validity*, or whether a semantically valid | ||
| //! transaction is actually valid in the context of a particular | ||
| //! chain state. For instance, a transaction that spends a | ||
| //! UTXO is only valid if the UTXO remains unspent; a | ||
| //! shielded transaction spending some note must reveal a nullifier | ||
| //! not already in the nullifier set, etc. | ||
| //! | ||
| //! *Structural validity* is enforced by the definitions of data | ||
| //! structures in `zebra-chain`. *Semantic validity* is enforced by the | ||
| //! code in this crate. *Contextual validity* is enforced in | ||
| //! `zebra-state` when objects are committed to the chain state. |
Co-authored-by: Deirdre Connolly <deirdre@zfnd.org>
This squashes the previous sequence of commits to let us separate out the structural skeleton (which unblocks other work and is not consensus-critical) from the actual checks (which don't block other work and are consensus-critical). Co-authored-by: Deirdre Connolly <deirdre@zfnd.org>
- remove no longer accurate documentation about transaction verifier; - add description of the role of the crate.
This reduces the API surface to the minimum required for functionality, and cleans up module documentation. The stub mempool module is deleted entirely, since it will need to be redone later anyways.
50182ad to
dcd814d
Compare
I've created #1186 so that we can merge this for now and let the checks one get rebased, and will dedupe the |
Supersedes #1100, as described here: #1100 (comment)
Rather than force-pushing the rebased branch on top of that one, I created a new PR (this one) to allow comparison.
This PR:
transaction::Verifierwith enough structure to slot in the rest of the checks one-by-one;zebra-chainto support future checks;script::Verifier, which does plumbing to asynchronously connect the state withzebra-script;script,transaction, andblockverifiers.The extra checks added in #1100 are removed and will come in a follow-on PR. This way, this PR focuses on the structure and the later one on the consensus rules.