Restore arti support and create a tutorial

[oxarbitrage]

In the past the Zebra node had the capability of running behind the tor network, it was an effort made by @teor2345 . We never actually made any tests or wrote anything about how to use it and what were their capabilities. Some time after we had to disable the support because of dependency issues (https://github.com/ZcashFoundation/zebra/issues/5492).

This is a list of tasks where the plan is to re enable the support and go a step beyond what we had by detailing what it is possible when zebra runs with arti support:

• [x] #5492

[oxarbitrage]

This idea ended up being a dependency nightmare.

I started by enabling the tor support by reversing the changes that were done to zebra-network Cargo.toml in https://github.com/ZcashFoundation/zebra/pull/5481

Initially started by using the current last version of the 2 crates:

• arti-client: v0.14.0
• tor-rtcompat: v0.10.0

This arti crates use the last versions of base64ct crate while in zebra we are depend on zcash_primitives, that depends on a version of bip0039 that depends on pbkdf2 that depends on password-hash to finally end up depending in an old version of base64ct. A similar issue also happens with zcash_proofs.

While upgrading zcash_primitives and zcash_proofs is maybe doable, there are other places where we are going to need to make changes, specifically into zcash_script crate.

Another option could be forking all the dependencies, however forking and maintaining such of a dependency chain will be problematic for us.

I tried different versions of arti and rtcompat however the dependency differences remain in the newest versions where in older versions other problems arise. There is no much sense in supporting a very old arti version even if that works.

Another approach i tried was to fork arti and downgrade base64ct. This almost worked, however there are some arti crates that depends on another crate which ends up depending in a higher than we can afford in zebra for the base64ct dependency. So that was another dead end.

Finally, @arya2 tried some options with the patch Cargo config option but it was another dead end.

So, considering the significant amount of work we are going to need to make this happen in the current conditions and the timeframe we have to complete the project (1 sprint) we had to abandon this idea for now.

I am pinging @str4d and @nuttycom they can maybe take a look in the future and let us know if there is some plan to make dependency upgrades that make this project a bit easier for us.

[emersonian]

It looks like bumping bip0039 to v0.12 in zcash_primitives now fixes the build. Here's a branch that builds with arti enabled, I haven't tested it yet.

Pulling this off involves upgrading bip0039 in zcash_primitives then releasing new patch versions of each crate that depends on it.

[mpguerra]

thanks for checking this out @emersonian! We're not prioritising this work right now and it seems like it would need coordination with the zcash_primitives maintainers. We'd be happy to review pull requests though :)

[str4d]

As I documented for the second time in two months in https://github.com/zcash/librustzcash/pull/1377#pullrequestreview-2028701549, bumping to bip0039 0.12 prevents zcash_primitives from being used in zcashd, which is a non-starter prior to the end of zcashd deprecation.

If we merged the bump in zcash_primitives and attempted to depend on bip0039 0.10 directly in zcashd, we'd run into the same problem as in this issue. So I want to understand what the issue here actually is. @oxarbitrage what is the compilation problem that results from having two versions of base64ct in the dependency tree?

[oxarbitrage]

I don't remember exactly but i found an error on my notes that might be helpful:

All possible versions conflict with previously selected packages.
  previously selected package `base64ct v1.0.1`
    ... which satisfies dependency `base64ct = ">=1, <1.1.0"` of package `password-hash v0.3.2`
    ... which satisfies dependency `password-hash = "^0.3"` of package `pbkdf2 v0.10.0`
    ... which satisfies dependency `pbkdf2 = "^0.10"` of package `bip0039 v0.10.1`
    ... which satisfies dependency `bip0039 = "^0.10"` of package `zcash_primitives v0.13.0-rc.1`
    ... which satisfies dependency `zcash_primitives = "^0.13.0-rc.1"` of package `zebra-chain v1.0.0-beta.35 (/home/alfredo/zebra/issue5492/zebra/zebra-chain)`
    ... which satisfies path dependency `zebra-chain` (locked to 1.0.0-beta.35) of package `zebrad v1.6.0 (/home/alfredo/zebra/issue5492/zebra/zebrad)`
failed to select a version for `base64ct` which could resolve this conflict

I might try to re enable arti again to get more information.

[daira]

This arti crates use the last versions of base64ct crate while in zebra we are depend on zcash_primitives, that depends on a version of bip0039 that depends on pbkdf2 that depends on password-hash to finally end up depending in an old version of base64ct. A similar issue also happens with zcash_proofs.

I'm a bit confused because it should be fine to have duplicate versions of base64ct. Duplicates aren't ideal but cargo and Rust usually deal with them just fine. What crate was cargo trying to resolve when it gave that error (I think you may have snipped out that part of the error message)?

[oxarbitrage]

I'm a bit confused because it should be fine to have duplicate versions of base64ct. Duplicates aren't ideal but cargo and Rust usually deal with them just fine. What crate was cargo trying to resolve when it gave that error (I think you may have snipped out that part of the error message)?

I don't have the full log with me anymore, i will retry and let you know.

[str4d]

... which satisfies dependency `base64ct = ">=1, <1.1.0"` of package `password-hash v0.3.2`

That's the problem. My guess is that somewhere in the arti-client dependency tree is a dependency on base64ct 1.X with X > 0.

https://github.com/RustCrypto/traits/pull/757 (released in password-hash v0.3.1) pinned base64ct < 1.1.0 to avoid an MSRV bump. I understand why the RustCrypto devs take that approach (because otherwise a plain cargo update breaks), but I personally disagree with it because it prevents an otherwise-valid dependency combination from working (that one does need to manually craft to work around the aforementioned breakage).

[mpguerra]

We should be able to revisit this once https://github.com/zcash/librustzcash/pull/1391 merges

[mpguerra]

The solution to issue might be very relevant also: https://github.com/zcash/librustzcash/issues/1416