V5 transaction rfc

[oxarbitrage]

Summary

Please copy the RFC summary over here.

Propose a design for V5 transactions. Open for discussion.

More information

Feature Name: my_feature

Start Date: YYYY-MM-DD

Design PR: ZcashFoundation/zebra#0000

Zebra Issue: ZcashFoundation/zebra#1863

Document

Rendered.

Zebra Team Approval

Everyone on the Zebra team should review design RFCs:

• @dconnolly
• @oxarbitrage
• @teor2345

[teor2345]

Looks good for a first draft, I have a bunch of suggestions.

[oxarbitrage]

Link need to change after #1885 merges.

[teor2345]

I made a bunch of suggestions to complete the RFC, and also found a few bugs.

Let's get @dconnolly to check this, and then I think we're done.

[teor2345]

I'm good with this RFC, I just need some cryptography API design advice from @dconnolly.

[dconnolly]

So one thing we can do is instead of naming the structs or types as Sapling or V4/V5, we can namespace them in the module tree, so we could havezebra_chain::transaction::v5::ShieldedData We could represent ShieldedData as enum variants, alá Transaction::V4/V5, and it would use things like zebra_chain::orchard::Action.

I don't think we need OutputV4 and OutputV5, we can use the same sapling::Output type in both ShieldedData::V4 and ShieldedData::V5.

The Spends having the anchor moving around looks like yes we need a different one for v5. I wonder if we can have a sapling::Spend as an enum instead of a different type, similar to how we have Transaction as an enum with different variants, so we can have sapling::Spend::V4/V5.

@oxarbitrage @yaahc @teor2345 what do you think? Basically consolidates @oxarbitrage's design into enum variants vs separate types

[teor2345]

@oxarbitrage @yaahc @teor2345 what do you think? Basically consolidates @oxarbitrage's design into enum variants vs separate types

I think enum variants are a good design. We can replace the trait part of the old design with methods on the enum.

[teor2345]

This is fine with me

[oxarbitrage]

Looks great.

[teor2345]

Design alternative: distinguish shared and per spend anchors

[dconnolly]

Design alternative: distinguish shared and per spend anchors

Since ShieldedData basically maps to transaction fields as described in the spec, I don't mind keeping them as anchors in our data structure

[teor2345]

There are no blocking changes left, and we've all approved the RFC. Merging.