zcash_client_backend: Introduce an "orchard" feature flag. by nuttycom · Pull Request #1080 · zcash/librustzcash

nuttycom · 2024-01-03T18:07:44Z

We plan to also introduce a similar flag to gate access to Sapling functionality. Since introduction of Orchard functionality is still nascent, it's the correct time to introduce this isolation, before there's more functionality that needs to be isolated in this fashion.

codecov · 2024-01-03T18:26:01Z

Codecov Report

Attention: 41 lines in your changes are missing coverage. Please review.

Comparison is base (4bd6520) 66.41% compared to head (967fd36) 66.48%.

Files	Patch %	Lines
zcash_client_backend/src/scanning.rs	55.73%	27 Missing ⚠️
zcash_primitives/src/transaction/builder.rs	88.63%	5 Missing ⚠️
zcash_client_backend/src/keys.rs	85.71%	4 Missing ⚠️
zcash_client_backend/src/data_api.rs	88.23%	2 Missing ⚠️
zcash_client_sqlite/src/wallet.rs	60.00%	2 Missing ⚠️
zcash_client_backend/src/data_api/wallet.rs	66.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    zcash/librustzcash#1080      +/-   ##
==========================================
+ Coverage   66.41%   66.48%   +0.07%     
==========================================
  Files         113      113              
  Lines       10821    10856      +35     
==========================================
+ Hits         7187     7218      +31     
- Misses       3634     3638       +4

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

We plan to also introduce a similar flag to gate access to Sapling functionality. Since introduction of Orchard functionality is still nascent, it's the correct time to introduce this isolation, before there's more functionality that needs to be isolated in this fashion.

…commitment and nullifier data.

str4d

Reviewed as of 857e44a.

zcash_client_backend/src/address.rs

zcash_client_backend/src/keys.rs

str4d · 2024-01-03T21:21:23Z

zcash_client_backend/src/keys.rs

+            #[cfg(feature = "orchard")]
+            let has_orchard = orchard.is_some();
+            #[cfg(not(feature = "orchard"))]
+            let has_orchard = true;


Nit: this is fine for now, but when sapling is given a feature flag, we will need to ensure that we can never produce a USK if both sapling and orchard are disabled (probably by gating the entire UnifiedSpendingKey type on #[cfg(any(feature = "orchard", feature = "sapling"))].

After having done this exercise, I think that we should go ahead with adding the sapling feature flag to zcash_client_backend in the near future; it's not that much work now that the pattern is established and it really does help tease out coupling and improve modularity.

Given transparent support is also under a feature flag, what will happen when no feature flag is specified? Do we expect that to build, or would the error be helpful in directing the consumer to specify at least one?

We can just have that cause a compilation error.

str4d · 2024-01-03T21:32:08Z

zcash_client_sqlite/Cargo.toml


+## Enables support for storing data related to the sending and receiving of 
+## Orchard funds.
+orchard = ["zcash_client_backend/orchard"]


Should orchard be default-enabled (both here and in zcash_client_backend)? I think that's likely what we want as the default here eventually (and for compatibility it will be the default for the eventual sapling feature flag), and then downstreams that don't want Orchard can use default-features = false (like is done to disable multicore). But maybe while developing it we leave it default-disabled? IDK.

Yes, ultimately, but I want it to be default-disabled until there are no more FIXME or unimplemented() sections.

str4d · 2024-01-03T21:35:25Z

zcash_client_sqlite/src/testing.rs

        }
    }
+
+    #[cfg(feature = "orchard")]


I forget: does the client have a way to tell lightwalletd to only send one or the other of Sapling and Orchard? Or will real CompactBlocks always contain both Sapling and Orchard components of transactions even if the local client only supports one of them? If the latter, we should probably have some way to test that case (but maybe not here, given that this is predicated on transaction parsing support for Orchard types).

Right now I think they'll always contain both.

zcash_client_backend/src/data_api.rs

str4d · 2024-01-04T18:10:53Z

zcash_client_backend/src/keys.rs

+        // We test the full roundtrip only with the `orchard` feature enabled, because we will
+        // not generate the `orchard` part of the encoding if the UFVK does not have an Orchard
+        // part.


Non-blocking: we should instead update these test vectors to cover the matrix of flags.

Created https://github.com/zcash/librustzcash/issues/1084

str4d · 2024-01-04T18:14:27Z

zcash_client_sqlite/src/wallet.rs

+        #[cfg(feature = "orchard")]
+        if _params


Per my comment above, if we're still going to have the database tables for Orchard in the schema, then for values that don't depend on orchard crate types and aren't wallet-specific (like the Orchard tree size for a given block), we probably don't want to feature flag this off.

The main reason for doing so would be if the presence of an Orchard tree size is used as some kind of indicator or switch for later logic. Do we need to use it as such?

I don't want to use the presence or absence of data to be used as a logic switch, for sure. However, as I stated above, I think that we should try to fully segregate protocol-specific functionality so that as much orchard stuff as possible is removed from the API when the orchard flag is disabled; a smaller API surface is going to be less error-prone.

str4d · 2024-01-04T18:24:25Z

zcash_primitives/src/transaction/builder.rs

+        sapling_anchor: Option<sapling::Anchor>,
+        orchard_anchor: Option<orchard::Anchor>,


(Asking so I can keep track of the design:) Why are the anchors now optional again? (And why the change in this PR - what about the orchard flag necessitates this?)

So, the anchors are optional so that we don't have to depend on the orchard crate in zcash_client_backend, since the feature flagging doesn't yet extend to zcash_primitives. We will likely want to do that work in zcash_primitives, but that's a bigger job that I didn't want to tackle yet. So making these optional is the compromise.

str4d · 2024-01-04T18:27:08Z

zcash_primitives/src/transaction/builder.rs

@@ -522,20 +528,22 @@ impl<'a, P: consensus::Parameters, U: sapling::builder::ProverProgress> Builder<
                transparent_inputs,
                self.transparent_builder.outputs(),
                sapling_spends,


Non-blocking: I think we need to alter this to call bundle_type.num_spends() after the changes in zcash/sapling-crypto#114. This should happen in a separate PR.

That is happening as part of #1060

Co-authored-by: str4d <thestr4d@gmail.com>

str4d

utACK 967fd36

daira · 2024-01-05T01:50:36Z

zcash_client_backend/src/address.rs

        let ua = UnifiedAddress::from_receivers(orchard, sapling, transparent).unwrap();

+        #[cfg(not(feature = "orchard"))]
+        let ua = UnifiedAddress::from_receivers(sapling, transparent).unwrap();


This could just be

let ua = UnifiedAddress::from_receivers( #[cfg(feature = "orchard")] orchard, sapling, transparent, ).unwrap();

(which will be simpler once we add the "sapling" feature).

daira

Post-hoc ACK

nuttycom force-pushed the wallet/orchard_feature_flag branch from ce44169 to fd14b00 Compare January 3, 2024 20:32

nuttycom changed the title ~~Introduce an "orchard-client" feature flag.~~ zcash_client_backend: Introduce an "orchard" feature flag. Jan 3, 2024

nuttycom force-pushed the wallet/orchard_feature_flag branch 3 times, most recently from 97f31e2 to c272c0c Compare January 3, 2024 20:49

nuttycom force-pushed the wallet/orchard_feature_flag branch from c272c0c to f18d082 Compare January 4, 2024 00:06

nuttycom mentioned this pull request Jan 4, 2024

Add Orchard support to fees & transaction proposals. #1060

Merged

zcash_client_backend: Use a polymorphic type for ScannedBlock note …

857e44a

…commitment and nullifier data.

nuttycom force-pushed the wallet/orchard_feature_flag branch from 5c155ce to 857e44a Compare January 4, 2024 18:19

str4d requested changes Jan 4, 2024

View reviewed changes

nuttycom mentioned this pull request Mar 31, 2026

Update UA encoding test vectors to cover the matrix of feature flags respected by zcash_client_backend zcash/zcash-test-vectors#118

Open

Apply suggestions from code review

967fd36

Co-authored-by: str4d <thestr4d@gmail.com>

nuttycom requested a review from str4d January 4, 2024 20:02

str4d approved these changes Jan 4, 2024

View reviewed changes

str4d merged commit b83877f into zcash:main Jan 4, 2024

nuttycom deleted the wallet/orchard_feature_flag branch January 4, 2024 21:01

daira reviewed Jan 5, 2024

View reviewed changes

		sapling_anchor: Option<sapling::Anchor>,
		orchard_anchor: Option<orchard::Anchor>,

Conversation

nuttycom commented Jan 3, 2024

Uh oh!

codecov bot commented Jan 3, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

str4d left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

str4d left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

daira left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

codecov bot commented Jan 3, 2024 •

edited

Loading