Arti: A pure-Rust Tor Implementation for Zcash and beyond

Community Grants
1

Hi there!

The original version of this post had a bunch of links, but these forums only allow me two. I’ve put the original version up at [the project wiki]](Zcash Grants post · Wiki · The Tor Project / Core / Arti · GitLab) in case you want to follow the links and find out more. I’m marking the linked words with italics.

TLDR:

  • The Tor Project has a project proposal that will solve a network-privacy challenge for Zcash by making Tor easy to embed, customize, and maintain.
  • To do so, the Tor Project will create an implementation of the Tor protocols in Rust (called “Arti”), moving away from its current implementation in C.
  • Making Tor easier to embed benefits the broader ecosystem of privacy tools, making an impact for users beyond the Tor Project and Zcash communities.

About Tor & network-level privacy benefits

I’m Nick Mathewson, one of the co-founders of Tor. We’ve been working on Tor for a long time now (since 2002!), and over the years it has become a widely used and widely analyzed tool for internet privacy.

Tor provides robust network-level privacy for a huge variety of protocols, hiding their traffic among millions of active Tor users. Thus, it fits as a “missing piece” of the Zcash privacy story – not only as a communications privacy layer for Zcash, but also for all the other communications tools that Zcash users employ.

Tor is available to use, well established, and well analyzed today, and works with most any protocol that works over TCP. Our network’s performance and scalability have been improving over time, and we layer with an ecosystem of tools to circumvent different censorship regimes around the world.

But the current Tor implementation bears the signs of its age. Tor is implemented in C, as a standalone network proxy. (This made sense back in 2002, when high-performance cross-platform languages were less common on the ground.) Because Tor is a stand-alone proxy, it’s cumbersome for third parties to embed: we have a “library mode,” but the library mode just runs the proxy in a separate set of threads. And because Tor is written in C, it’s difficult to have the same confidence in its memory-safety as would be possible with a higher-level memory-safe language. Moreover, because C is unsafe and error-prone, our development requires more time and energy than it should, which slows us down when delivering improvements to our users.

Introducing Arti

We’ve heard from a bunch of other projects that what they want from us is a lightweight, easy-to-tweak implementation of the Tor protocols, in a safe language that they can embed in other programs and use as a library. With that in mind, we’ve started on a Rust implementation of the Tor protocols that we’re calling “Arti.”

We’re designing Arti from the ground up for flexibility in embedding, straightforward maintenance, flexible deployment, and reasonably good performance. Even though it’s comparatively new, we hope and believe it’s the future of Tor: by using Rust, we get memory safety “for free,” and will eventually get compilation to WASM. Moreover, we get a codebase that others can maintain and adapt to fit with their projects, taking only the parts that they need to keep their binaries small for mobile or other restricted environments.

Arti works today: you can fetch the source and run it as a SOCKS proxy. The README file has instructions for using it with Tor Browser. (Treat it as experimental for now, and do not rely on it for security or privacy: I’ll explain why below.) The code is simpler and smaller than the C Tor implementation, and it already has a simple (unstable) API for embedding.

Arti, Zcash, and ZOMG

Arti has the potential to benefit Zcash in many ways, both in the short term and the long term. In the past, when Zcash has looked into using Tor as a privacy layer (see for example this thread), several issues came up.

  • First, Tor is difficult to embed. Arti solves that by being structured as a set of Rust crates from the ground up.
  • Second, Zcash would want fine-grained control over Tor’s behavior of a kind that’s difficult to achieve in today’s Tor. Arti solves this by using a modular design that makes it easy for other projects to replace pieces of the Tor implementation (such as circuit scheduling or path selection) as required.
  • Finally, sometimes our work in delivering Tor improvements is slowed because of our legacy code. Arti solves this by giving us a new, safer architecture for prototyping and deploying protocol improvements, and delivering them to users and developers. Basically, with a better foundation to build on, all of our solutions become easier to build.

We hope to engage not only with the ZOMG as a grant partner for Arti, but also with the broader Zcash community as partners in development: Arti would benefit from the Zcash community’s Rust expertise and experience; Zcash would benefit from having a major network privacy client designed and built with an eye to Zcash’s requirements from the beginning into account. We believe that by making sure that Arti is built to meet Zcash’s needs (as well as the needs of existing Tor users), we can
deliver a more flexible tool than we would otherwise, to better spread privacy to the world at large.

Phases of work

In terms of the structure of the work: We are structuring our progress for Arti on three main tracks: (1) API usefulness/stability, (2) protocol security, (3) and feature parity with the C implementation. I’ll discuss each track below.

API usefulness/stability

So far, Arti’s API is minimal but usable, but we’ll need to expose at least a minimal surface for other tools to use before we can call Arti a useful embedded solution… and we’ll need to design those APIs with a view towards the use cases that other tools have for the Tor protocols. It’s our understanding that our first-draft minimal API already meets some of Zebra’s needs, and we look forward to working with them, as well as the rest of the Zcash-in-rust world, to provide something they can use.

Some important high-level milestones for the API include:

  • A stable top-level API that we can commit to supporting in the future.
  • Support for introspection on the state of the Tor client, to detect censorship, bootstrapping issues, network status, and so on.
  • Support for explicit circuit creation and management, as needed for tools like Zebra to manage linkability.
  • Fine-grained control over path generation, circuit construction, stream isolation, and routing for applications that need them.
  • Support for building without unneeded modules in resource-contrained environments.
  • Support for multiple Rust async execution environments, TLS backends, and so on.

We’re grouping many of our goals here under milestone A2 in gitlab, but we expect to find more work here as we progress and work with application developers.

Protocol security

Although Arti conforms to the Tor protocol specification, the C Tor implementation has lots of security features that Arti does not. Before we can recommend Arti for general use, we’ll have to add these features to Arti so that it provides network privacy at least as good as the C Tor implementation.

Some of these features are absolutely essential to privacy, including:

  • Guard nodes to resist predecessor attacks.
  • Application stream isolation to avoid cross-domain linkability.

Other security features are valuable but not critical, including:

  • Adaptive circuit-build-timeout inference and path bias detection, to avoid certain kinds of active insider attacks.
  • Preemptive circuit construction, connection padding, and circuit padding, to resist certain kinds of timing attacks.

We’re grouping this kind of work under milestone “B” in gitlab , but we do expect to find more work here as we progress.

Feature parity with the C Tor implementation

Right now Arti is a simple SOCKS proxy, and a simple way to make anonymous connections. The C implementation has numerous other features that clients use and rely on, which we think are necessary before we could stop maintaining the C version of Tor entirely. Some are generally useful, whereas others are more applicable for specific niches.

The most important missing features are:

  • Onion services for responder anonymity.
  • Pluggable transports for censorship circumvention
  • Performance and fairness features, to make sure that Arti behaves well when handling hundreds or thousands of simultaneous client streams.

We’re grouping all this work under milestone “C” in gitlab, but as above, we expect to find more work here as we progress.

Timeline

We think we can get everything above done in about 2 years, using 3 developers’ worth of time. This work can be broken into multiple phases, depending on funding.

  • Minimal safe, usable prototype: 3-6 months
  • Incremental releases improving stability & security, to production-ready status: 6 months-1 year
  • Feature partity with C: 1 year

Total development time: ~2 years, 3 full-time developers.

In closing

Thanks for reading so far! Based on other conversations and forum threads, we think our work on Arti is of interest to the Zcash community. We’d like to hear from the community about this idea before we propose a grant to ZOMG, so that we can integrate your feedback. Thanks again: we’re looking forward to your ideas!

(This seems like a good time to say that the Tor Project is a 501(c)3 not-for-profit charitable corporation, incorporated since 2006. We don’t have shares, or answer to shareholders. We are committed to free software, and we don’t do patents. We also believe in transparency, and we post our annual financial filings online once they’ve been audited. Our mission is to develop and promote privacy software, and we believe in it strongly.)

25 Likes
2

Nick, thank you so much for writing this up!

Just to note it here, I encouraged Tor to apply because I think strong built-in solutions to network layer privacy are necessary for making the privacy properties of Zcash crystal clear to the average user.

If we can say that the chain is encrypted and the network layer is as secure as Tor, that’s a huge win, because Tor is fairly well known as a product among people who are privacy conscious.

And conversely, until we have a solution like Tor, it will be really hard to communicate Zcash’s privacy properties to a typical user. Surveillance companies like Chainalysis will be able to track Zcash users by sitting on the network layer—especially for government clients working with exchanges. There will be a rash of “Zcash transactions de-anonymized!” articles in the tech press, or specific stories about specific users being tracked at the network layer. That will confuse prospective Zcash users and hurt the Zcash brand.

Mixnets are an exciting solution to this problem that could theoretically be even more secure than Tor— especially against governments like the US and China—but according to Zcash Foundation research the fact that Tor works today, is well-tested, and already offers a huge anonymity set of millions of users makes it the best near-term solution. (And as Nick points out, Tor is useful as a censorship circumvention tool as well, and could eventually make Zcash work out-of-the-box in countries that outright block Zcash—or all cryptocurrencies—at the ISP level.)

My questions are:

0. In funding this, how do we make sure this work lands in widely used Zcash tooling as soon as it’s ready?

Tor is awesome, and Tor as an easy-to-integrate Rust library is awesome, but ZOMG’s mandate is to fund work directly related to Zcash, so we want to see a clear path here to getting this work integrated in the Zcash tools that people use everyday. Are there commitments from these teams to use your work on Arti as long as certain deliverables are met? Or are there people we can fund, either in your team or outside contractors (ZOMG’s mandate doesn’t let us fund ECC or ZF) who can do the last mile work necessary to bring this to Zcash? And are the teams working on these tools eager to include Tor by default if Arti makes that easy?

I think in order of impact, these tools are the Zecwallet SDK (used by the leading wallet app Zecwallet), the ECC light wallet SDK (used by Nighthawk and Unstoppable), zcashd, and Zebra.

1. What is the smallest piece of work that can land in some widely-used Zcash tooling?

It sounds like the basics of connecting to the Tor network will be ready before things like onion services, which are necessary to receive connections within the Tor network. What’s the piece of this that would deliver the most value to users that we can deliver the fastest? Given that right now most Zcash users enjoy little or no network layer privacy, does that lower the bar at all in a way that could simplify this first deliverable? That is, is there something you can deliver that might not offer all of the protections of an existing Tor client but that can run by default and offer more protection than, say, connecting to a Zcash lightwallet server directly over HTTPS?

2. What are the alternative approaches?

If you were a us, would you fund work integrating existing Tor into various apps and SDKs? It does seem like including built-in Tor support in zcashd, zebra, and the two lightwallet SDKs is not going to happen right now with the existing Tor client, since it complicates the build process. So this work on Arti seems valuable to Zcash either way. But I’m wondering what the cost/benefit is to funding apps like Zecwallet and Nighthawk to integrate existing Tor right now vs. investing in Arti and integrating it into the basic tools.

3. Would this work get a security audit?

It might make sense to budget for this, both for audits of the work on Arti and the integration of Arti in whatever Zcash tools we target.

4. How does this relate to work on Walking Onions?

My understanding is that Zcash Foundation funded Tor’s work on Walking Onions to figure out how to make connecting to the Tor network much faster, especially on mobile, and that Tor completed the grant and figured it out, but that implementation was left for a future grant. Is that right? Should ZOMG fund implementation of Walking Onions now? Do you plan to implement it in the existing Tor client? Or are you postponing building big new features like this because Arti makes new feature work easier?

5. Will Arti become a part of Tor browser? Will Tor’s censorship circumvention transports support Arti?

It would be bad if we did this integration and work on Arti languishes, or if a lot of the transports people use to connect to the network in censorship-heavy regions don’t support it. At what point will Arti replace the existing Tor client in Tor browser? At what point will the most important censorship circumvention pieces of Tor be as easy to integrate in Zcash tooling as Arti?

I’m also really interested in what @earthrise, @ckomlo, @gmale, @bradmiller, and @alchemydc think about these questions!!

7 Likes
3

:100: in support of this proposal, let’s get this baked in zebrad @dconnolly @str4d

Speaking for @NighthawkApps we are testing open source implementations from Unstoppable Wallet to see if it fits well in within the mobile architecture. But yes, if Arti can tie within the librustzcash and make its way to the SDKs, it would make life easier for wallet developers.

9 Likes
4

Thanks for the great questions, @holmesworcester!

For some of these questions, I’m competent to answer on my own; for others, I’d want feedback from the relevant development teams.

0. In funding this, how do we make sure this work lands in widely used Zcash tooling as soon as it’s ready?

I think that on our end, the best we can do is make sure that we are in contact with the teams developing the Zcash tooling to make sure Arti meets their needs, and to make sure that our roadmaps prioritize reaching that point ASAP.

There isn’t currently a commitment to include Tor in these tools, as far as I know, but I’d love to discuss with them what their needs are and what Arti would need to do to meet those needs. (See question 1 below.) I think that assessing such interest and scoping would be a great idea before moving on to a formal proposal.

As for funding others to do the integration work: I don’t think we at Tor are the best people to handle that kind of integration ourselves, but we could definitely advise on important gotchas and potential security gotchas in doing it.

1. What is the smallest piece of work that can land in some widely-used Zcash tooling?

I do like the idea of aiming initially for “better than nothing” security.

My answer here will be incomplete, and I’d love feedback from the people hacking on the tools you mention to know what those needs are. (Hi, developers! If you want to chat here we can, but you can also find my contact info in lots of other ways.)

I’ve heard informally from one Zebra developer that the necessary features for a production level rollout for them would include (at minimum but not maximum) guard nodes, stream isolation, and a stable API.

I agree that the above features are necessary for any kind of security, and I also think that one or two other features (such as circuit-build-timeout inference) may be necessary for acceptable performance or security. We’ll want to do an audit on those to try to identify a minimal set.

In practice, we’ve found that some aspects of the user experience also require that the application can expose information about bootstrapping status to the rest of the world. Without that kind of visibility, there’s no way that the application can say “Tor seems to be censored here, want to retry without it”? So I expect that UX engineers on these projects will also have feedback for us that we’ll need to resolve.

2. What are the alternative approaches?

Our long-term hope is that we will make Arti so good that there is no more need for the C tor client at all, and we can eventually cease new feature development on it. Our ability to meet this hope depends on our resources, but my team is pretty convinced that Rust Is Our Future.

I would only recommend integrating the current Tor C client as an intermediary measure: the work to do so is probably not something you’d want to maintain longterm if Arti becomes an option for you. So for developers considering that, the cost/benefit question becomes: Is is the benefit of having Tor integration now worth the cost of writing and maintaining integration code that you will likely want to throw away after Arti is done?

3. Would this work get a security audit?

That is an excellent idea, and I support it strongly.

4. How does this relate to work on Walking Onions?

You’re right that Walking Onions has been funded to get it into a full-fledged design, but not yet for implementation. I still think it’s a good design, and I believe we should build it.

If possible, I would like to never implement that design in C: it’s got significant complexity and is much more suited to a higher level language, like Rust. When we build Walking Onions, it will be a Rust crate.

However, we anticipate that the Tor relay implementation will still be C for at least the next few years. That means that when we implement Walking Onions, we’ll need to design our Rust crate with a decent FFI so that it can be exposed to the C implementation for now.

Whether we do client-side integration of this time will depend on the relative timeframes for funding Arti and Walking Onions. In the case that Arti were to get no funding, but Walking Onions were to get lots, we’d have to integrate it into the C client. But if Arti can get funded enough to replace the C client on a near-term timeframe, then a C client integration for Walking Onions might not be necessary.

5. Will Arti become a part of Tor browser? Will Tor’s censorship circumvention transports support Arti?

Our plan is yes on both counts. If everything works out, then we want Arti to eventually replace C tor in all cases.

I can’t speak to the Tor Browser’s timeframe here, but they do intend to use Arti when it’s ready. They’re exited to have a Tor implementation that can be built as a library, embedded in a VPN module, or even translated to WASM. I expect that their requirements for integrating Arti would depend at the very least getting the anticensorship features you mention. Those features would come as part of “milestone C (client feature parity).”

(To existing Tor users reading this: no need to worry. We believe in safe deprecations, and we’re not going to kill the C Tor client off without a solid migration plan.)

Okay, I think that’s all. Sorry in advance if I missed any of your questions; I hope you won’t mind pointing them out to me if I did.

5 Likes
5

Thanks @aiyadt, it’s really helpful to know that you think this would be helpful for Nighthawk. If you at any point have updates from your tests on Tor integration it would be great to know more!

This seems like the central thing to work out. @nickm_tor — are you in touch with all the people you need to be, to figure this part out? Can we help?

Also, while it would be great to get feedback from more people here, I don’t think figuring out these details is necessarily a blocker to submitting a formal proposal.

As long as we have some general assurance from ECC or ZF that they’ll work with you on this and integrate Tor in some way as soon as Arti meets their requirements, I think that’s enough to begin work, since it’s a long road.

3 Likes
6

This seems like the central thing to work out. @nickm_tor — are you in touch with all the people you need to be, to figure this part out? Can we help?

I don’t think we necessarily are: we know a few programmers working in different parts of the Zcash world, but I’m not sure that they’re all the right ones.

If you could could introduce me and @alsmith (our grants+fundraising person) to the right folks, that would be a great start for us.

2 Likes
7

This sounds like a very interesting proposal to me and I’d be keen to see it get funding.

To be able to say that we’re funding Tor with the goal of providing enhanced network level security to applications in the Zcash ecosystem is exciting to me, both from the functionality it will provide and for the message it sends.

It would be good to see a commitment from the various
Zcash developers / development teams that they would be prepared to work with Tor on this. That would be enough for now in my opinion, the finer details can be worked out later.

And thanks for the proactive work Holmes, we’re only a few months in and we’re starting to see some high quality teams / proposals coming in.

6 Likes
8

Hi, I’m Teor, one of the Zebra engineers at the Zcash Foundation.

Before I joined the Foundation in 2020, I was working for The Tor Project as a Tor developer. And before that, I worked as a researcher developing privacy-preserving statistics and doing network traffic analysis on Tor. I also have some experience working on apps that integrate with Tor.

I’m one of the Foundation engineers who will be working on Zebra Tor integration. I’ll also make sure we keep our tech lead @dconnolly and our engineering manager @pili in the loop - along with the other Zebra engineers, and our network privacy researcher @chelseakomlo.

The Zebra team plans to release the first version of zebra-client with Tor support, so users can send new transactions anonymously.

Here’s what we’ve done already:

Arti would remove the SOCKS boilerplate from our current connection implementation, reducing it to a few simple API calls. That would make our Tor integration much easier to review and maintain. Other apps/tools should have a similar experience.

We’d love to work with the Tor team to make this happen. (I have worked with them before, and I would do it again.)

To add network privacy for new transactions in zebra-client, we need:

  • Outbound Tor connections
  • A way to connect to a new exit for each connection, so we get different nodes using the same DNS seeder hostnames
  • Guards to resist path analysis (particularly important for frequent Zcash users)
  • Decent performance / reliability / error handling when something goes wrong

Most apps/tools that send new transactions over Tor should have similar requirements.

For transaction and block lookups, there are two different options:

  • full node: download the entire ~25 GB chain over Tor
  • light clients: download specific transactions over Tor

Full Node

In Zebra, we’re not planning to download the entire chain over Tor, because that puts a lot of load on the network, and doesn’t provide much extra anonymity. Since you’re downloading the entire chain, network-level observers can tell you’re using Zcash, but they don’t know which transactions you’re actually interested in. (In the future, when Tor scales to the point where 20+ GB per user isn’t a big issue, we’d gladly use it for all our network traffic.)

Light Client

Light clients are different - they only fetch some transactions. So for a light client, Tor breaks the link between your IP address (and therefore your account / location / household), and the specific transactions you’re interested in. There’s still some trust placed in the server, because it knows someone is interested in those transactions, at the time they’re being downloaded. Reducing that trust requires light wallet protocol changes (or a full download of the relevant transaction data).

Light wallets would also need to be able to isolate connections for each transaction/key/user.

What are some other benefits of this grant?

Zebra uses the Rust build system. If we can integrate Tor as a Rust library, that makes it a whole lot easier to have Tor-by-default, or at the very least, Tor as an easily activated feature. If we have to build Tor as an external C binary, some packagers won’t include it, and others will turn it off by default.

And as Nick said, a Rust Tor implementation also has wider benefits to the ongoing health of Tor, including security, and scaling the Tor network.

If Zebra integrates Tor, it will be running on the same device, so we’ll want it to be as secure as possible.

If Zcash wants to serve hundreds of thousands of users, with privacy all the way down, we’ll need Tor to scale well. Anonymity is a property of the size of the entire network, so we’ll have better privacy if we have a large crowd to hide in.

9 Likes
9

Hi, @teor! It’s always good to hear from you. I’m about to go to bed, but before I do I wanted to mention one point.

Full disclosure: @chelseakomlo is on the Tor Project board of directors. (I wouldn’t want anybody to think we weren’t being upfront about that.)

3 Likes
10

Indeed, thanks @nickm_tor for this disclosure and @teor for the writeup. I don’t think I should weigh in on this funding request as I am on Tor’s board. However, I fully support increasing opportunities for network privacy in the near-term, for both Zcash users and more broadly.

6 Likes
11

This is pretty persuasive to me that Tor as a Rust library is helpful.

It seems like as long as we’re including Tor as a binary it will be an option that users and developers sort of have to tinker with a bit and enable as an extra.

And I don’t think we should see network layer privacy as a nice-to-have or an extra. It’s part of delivering on the promise of privacy made by the Zcash brand so it should be baked in.

@teor do you expect that ZF would prioritize integrating Tor in this way, once this work once it’s ready?

4 Likes
12

It looks like teor is your best contact at ZF. At ECC I think it’s @gmale, who works on the Zcash mobile apps, or @alchemydc perhaps?

Also, how is Arti likely to work on mobile, relative to existing approaches for integrating Tor on mobile?

Is there any existing proof of concept of it running on iOS or in WASM? I talked briefly with ECC folks and I think this is a big deal for them.

2 Likes
13

Agree that having a tor-by-default in all zcash related projects would send a clear message that we are all in this for privacy

I am in general supportive of this proposal idea and would like to see zcash community become the active contributor to credible privacy projects. Something that I am sure we can be very good at.

Unrelated to my support to this idea, I would however caution the teams that will integrate Tor to pay attention on the end-user UX. In many parts of the world, internet connection is still unreliable. So, we need to make sure that disabling Tor should be easy. Of course, ideally we want a better internet for everyone.

2 Likes
14

For the next few months, the Zebra team will be focused on Canopy/NU5 validation, to prepare for NU5 activation in May/August 2021.

After NU5, we’re keen to start work on zebra-client. Network anonymity is really important for user-generated transactions. So Tor support will be a high priority for zebra-client.

So it looks like our rough timelines match up, but I’d have to check once the NU5 specs are finalised.

Even if they don’t quite match up, we’re keen for Tor support, we have some draft Tor integration code, and we can make time for high-priority upcoming work.

When I was at Tor, we did a bunch of work to make Tor better on mobile. We refactored Tor’s C code to be more modular, and we fixed some mobile-specific bugs and resource usage issues.

I also have some experience helping developers integrate tor on iOS, which does not allow apps to launch additional processes. The current solution is Tor.framework, which embeds Tor as a thread within the app.

It works, but it’s not ideal. Tor was designed as a process, not a library. Last time I checked, there were still some usability, reliability, and efficiency issues. Mobiles are resource constrained, so battery life, processor usage, and sleep/wake time are really important. We made progress on all these issues, but it’s hard to make fundamental changes to a large legacy C codebase.

A Rust implementation with a fresh API should be smaller, easier to integrate, more secure, and easier to audit. Particularly if we get mobile requirements in upfront - and test on mobile early in the process.

Overall, Android has similar resource constraints to iOS. But compared to iOS, it’s a bit easier to integrate Tor on Android, because Android is based on Linux.

I’m not as familiar with the current pain points with Tor on Android. @nickm_tor could put you in touch with the current Tor Browser for Android team. Or I could put you in touch with The Guardian Project, who did the original Tor integration on Android.

3 Likes
15

I plan on responding to this in more detail sometime next week, but I wanted to +1 this:

I have tried several times in the past to bundle Tor support into zcashd. I never managed to get the libtor library interface to work; distributing the tor daemon alongside zcashd and managing it separately was not something we could reliably ensure worked across all target environments and packaging situations; embedding the binary directly and doing some kind of extract-on-launch thing was pain I did not wish to inflict upon myself. (By comparison, I was trivially able to bundle I2P support several years ago via libi2pd.)

With any functionality we add to zcashd, we need to consider both the engineering cost to implement it, and the ongoing maintenance burden it places on us to support the feature and ensure it doesn’t break. A library-based Tor, and particularly one in Rust designed to be operated as a library, would be a positive for both these factors.

One other potential blocker that needs mentioning: zcashd supports “listen on an onion service” functionality, but the Bitcoin P2P network layer that Zcash currently uses does not support addresses larger than can fit in a subset of the IPv6 space (this is why I2P support was never landed, which requires 256-bit addresses). Tor’s 80-bit v2 onion services do fit, but these are being deprecated this year, so we need to upgrade the P2P network protocol to support Tor’s v3 onion services. Upstream Bitcoin Core have already made the necessary changes, and it’s on our radar for backporting (as part of a large ongoing backport to improve zcashd’s networking code), but as a result it’s unlikely we will have the engineering bandwidth to integrate Arti prior to completing this work.

8 Likes
16

FWIW, this has been our experience integrating Tor in Zbay, too.

My guess is that the further a team gets into trying to integrate Tor on multiple platforms, the more desirable Tor-as-Rust-library will become.

5 Likes
17

For clarification: Is running as an onion service a requirement for zcashd? If so, we can build it as part of our work, but it wasn’t part of our original time estimates. Then again, there are probably elements contained on our original time estimates that wouldn’t be needed.

1 Like
18

This is a good starting point, and I’m happy to make any contacts necessary.

One additional point to consider is that some users would rather have a shared Tor proxy that multiple applications can use. For these users on mobile, the trend seems to be towards forcing proxies to run as network extensions, in limited-execution environments. That’s another area where a fresh architecture can shine, since we’ll want to disable as much code as possible for such extensions. There are also good Rust user-space TCP stacks for this use case, that make it easier to build Tor-as-VPN using Arti.

1 Like
19

It is not a requirement (we support running zcashd without Tor, with Tor outgoing-only, and with Tor listening), but if we are going to bundle a Tor implementation then it would make sense for it to replace all cases where we use Tor (we definitely won’t use both internal and external Tor simultaneously). We could potentially ship “internal Tor has reduced functionality, use external Tor if you want everything”, but that seems like it would just be confusing for users.

20

There isn’t a poc here yet, but running on iOS is a requirement for us too, so we will be solving it. (I’m not an iOS developer myself, and I think my iOS contacts have gone home for the weekend, so I’ll need to get back to you on that.

As for WASM – it’s doable, but it will require a bit of porting. Right now we support the tokio and async-std runtimes, so adding another futures-compatible runtime shouldn’t be that hard. I expect that we’ll have some tweaking to do on our dependencies, to work around anything that currently relies on a feature (like the filesystem, or the ability to link c libraries) that we can’t get in a wasm environment. There aren’t too many of those at the moment. (Arti uses sqlite for a cache, and libzstd for decompression, but those are modular and can be swapped out.)

I wasn’t planning on doing the WASM port until the architecture was a bit more settled – would that be a requirement here?

This is indeed quite important! It’s also one of the reasons that I think we can do a better job on Arti when working together with applications developers. The temporary APIs that I’ve been designing work fine for my needs, but I think it will take at least one iteration of feedback to ensure that those APIs let applications expose the functionality that users actually need for a reasonable experience.

3 Likes