Update Transaction definition. #105
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dconnolly
reviewed
Nov 18, 2019
hdevalence
commented
Nov 18, 2019
dconnolly
reviewed
Nov 18, 2019
dconnolly
reviewed
Nov 18, 2019
daira
reviewed
Nov 19, 2019
daira
reviewed
Nov 19, 2019
daira
reviewed
Nov 19, 2019
dconnolly
reviewed
Nov 19, 2019
hdevalence
commented
Nov 20, 2019
|
The build job is having a hard time |
This could alternately use bytes::Bytes to save some allocations but I don't think this is important to get perfectly now. In the future, we will want to have all of the script handling code in the zebra-script crate, but we will need to have a container type for an encoded script in zebra-chain, because otherwise zebra-chain would depend on zebra-script and not the other way around.
These are only *transparent* inputs and outputs, so by putting Transparent in the name (instead of Transaction) it's more clear that a transaction's inputs or outputs can also be shielded.
This attempts to map the versioning and field presence rules into an ADT, so that structurally invalid transactions (e.g., a BCTV14 proof in a Sapling transaction) are unrepresentable.
Co-Authored-By: Daira Hopwood <daira@jacaranda.org>
This has a lot of duplication and should really use generics to abstract over Sprout-on-BCTV14 or Sprout-on-Groth16.
This also adds a trait to abstract over them.
|
Rewrote the description above. |
This was referenced Nov 28, 2019
dconnolly
reviewed
Nov 28, 2019
Closed
hdevalence
commented
Dec 5, 2019
This moves the TransactionHash changes along with the moved TransactionHash code.
skyl
added a commit
to skyl/zebra
that referenced
this pull request
Sep 25, 2024
Co-authored-by: Skylar Saveland <skylar.saveland@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Progress towards #13.
This creates a
Transactionenum over all transaction versions, with the goal of making (structurally) invalid Zcash transactions unrepresentable. Of course, it's still possible to make one which is semantically invalid, with e.g., invalid proofs, or contextually invalid, e.g., double-spending a note, but it should not be possible to construct aTransactionwhich does not have a valid encoding (e.g., a version 1 transaction with Sapling proofs in it, or some other structurally invalid combination. In addition to being a better design, this is also important for us, as we want to be able to construct transaction hashes by an infallibleFromimpl.To do this, the
Transactionstruct has one enum variant for each transaction encoding version, and the data is modeled (at times slightly differently from the description in the spec) so that each variant has only the appropriate fields.Previously this comment said it closes #13; it doesn't, and there is a bunch of work left to do, but that work could be split out into separate, further tickets:
Many of the types in the structures that make up a
Transactionneed to be refined to assign them semantic meaning. The complete list can be found by runningrg 'XXX refine' -A 2inzebra/zebra-chain/src. Fleshing out many of these types will require further work – for instance, theZcash-flavored Ed25519 pubkeyin the JoinSplit data requires Zcash-flavored Ed25519 #109. (This item is now Finish refining all primitive types brought in byTransactiondata. #123).The actual transaction encoding and decoding is not implemented, although there is a stub module in which it will live (
transaction/serialization.rs). ImplementingZcashSerializeandZcashDeserializeis a further chunk of work, but because all of the unrefined types are in place, it can be done independently of (1) by, e.g., parsing something as a[u8; 32]instead of some refinedPublicKeytype. (This item is now Implement transaction serialization. #124).The as-yet-unimplemented encoding and decoding is not tested. In addition to the transaction test vectors, we could define a
propteststrategy to generate random transaction data to check that the encodings round-trip. (This item is now Implement transaction serialization. #124).