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

This makes sense to me and is helpful for our decision!

We can! And we’re waiting to hear back now from the various teams to make sure that Arti integration will be on their roadmap.

1 Like

I remember writing a few happy-eyeballs proposals for Tor.

Now there are more Tor relays and authorities on IPv6, happy eyeballs should be efficient enough for testing. (And much easier to implement than in the legacy Tor codebase.)

That would be great! Let’s wait on any grant decision, and then do the walkthroughs soon after.

We also just merged our “Async Rust in Zebra” documentation today:

The difference in priority between the select() function and select! { } macro was particularly surprising to us.

1 Like

Here are some other things I’ve been thinking about as I’ve looked over arti’s milestones:

There’s an experienced Rust developer review as part of the 1.0.0 release. By that time, your architecture and data design will be pretty fixed - can you get an experienced Rust dev to look at them before your APIs stabilise? (0.0.1 or 0.1.0)

The Zebra team has had a similar lock-in experience in some of our async Rust code. For example, we wish we had made our std::thread::Mutex<AddressBook> into a tower::Service much earlier. Because now we’ve built on top of the mutex abstraction, it’s going to take more work to make all its callers async. (And it’s exposed in the API of the zebra-network crate, but it really shouldn’t be. More refactor work!)

But in general, we’ve really benefited from having experienced Rust developers work on our designs, implementations, and code reviews. I’ve definitely learned a lot!

I also wonder if the security audit cost is potentially a bit low for a protocol as complex as Tor? (That said, there will obviously be legacy features that you will never implement in arti.)

And thinking about timeframes for that audit: it might be helpful for the arti security audit to be done around the time Zebra has its first audited client release. But we haven’t done detailed planning for our client work yet, so I don’t have any specific timeframes for Zebra. And I suspect zcashd's requirements will be the real driver here, because they’re in production already.

Hi again, @teor, and sorry for the delay. My schedule has been wild and I’ve been more distracted than useful.

Can you get an experienced Rust dev to look at them before your APIs stabilise? (0.0.1 or 0.1.0)

Yes; we’re hoping to actually start getting our API feedback as soon as we can, especially for developer-visible APIs.

Incidentally, as for Tower stuff, I’m hoping you or somebody will have time someday to introduce us to the why of Tower in a system like ours. I’m getting a sense what Tower does and what its APIs are for, but not a great sense of where Tower would logically fit into Arti. (Maybe there’s a part of Zebra I should look at, in order to get the key idea here?)

Zebra is designed as a series of microservices: A New Network Stack For Zcash – The Zcash Foundation

One of the benefits of Tower is that Services are composable with Layers. So it’s very easy to wrap a network service in a hedge, timeout, concurrency limit, or buffer. And if you’ve used Rust generics for your service types, the rest of your code doesn’t need to change at all.

Zebra uses about half the layers listed here: tower - Rust

And we also have our own tower-based batch verifiers for zero-knowledge proofs and signatures: Composable Futures-based Batch Verification – The Zcash Foundation

A similar design might be helpful for arti - you could have:

  • a directory microservice,
  • a guard-set microservice for guard connections (like tower-discover),
  • a microservice that handle circuits and cell decryption, and
  • an ed25519 batch verification service (like Zebra!)

A small update that might be of interest, as a proof-of-concept:

We’ve heard from a group of researchers who had the need to integrate anonymous communications into a contact tracing app that’s going to be used by several million users. The addition of anonymous communications would enable the privacy-preserving collection of usage statistics, key to assess the performance of the app. It would also enhance the security and privacy of new functionalities.

They decided to use the Tor network to safely route communications without deploying any new infrastructure. They decided to use Arti because—for their particular use case and threat model—the security features that Arti currently lacks are not necessary.

They’ve experimented with adding Arti support and they report:

  • Arti worked for them out-of-the-box on Android and iOS
  • They haven’t had trouble integrating it or making it work for them in practice.
  • There is a fairly good chance that the app version using Arti will be soon in production.

They don’t want to go public yet, since the feature is a work in progress, but they are happy to be contacted to answer questions about their use case and plans, and how further development of Arti would help their projects. But please ping me if you’d like me to put you in touch with them to discuss their experience.


@nickm_tor — great news! ZOMG is pleased to announce that “Arti: A pure rust Tor Implementation for Zcash and Beyond” has been approved to Milestone 1.1.0! :tada:

Funding to milestone 1.1.0 is approximately $670,000. With this grant, we’re going to begin offering some projects a choice between fixing the values of milestone payouts in ZEC or USD.
If you choose USD, you’ll receive exactly the USD values you proposed. If you choose ZEC, the ZEC amounts will be determined at today’s market prices, and you’ll receive those ZEC amounts for your milestones as they are met whether the market value of ZEC goes up or down. Given our understanding of Tor’s structure and needs, and given the size of the grant, we assume you prefer to fix the values of milestone payments in USD. If so, can you confirm this? Thanks!!

(Note for others following this discussion: we’re working on a separate post to explain why we came to this decision about ZEC vs USD milestones and what the caveats will be, and that will be posted soon! The short version is that we realized that in our current process ZOMG could potentially have become unable to meet its commitments, so we’re changing our process to address that.)

Please feel free to DM us @ZOMG so we can schedule a meeting to discuss next steps and answer any questions. We will also need to revise your existing grant proposal on the grant’s platform before we can proceed with approval there.

Congratulations!! We look forward to seeing Arti and the impact it can have on Zcash users network level privacy!


Also, we have reason to believe that this project may receive media coverage.

Our press release for any inquiries:


Congrats @nickm_tor and all people at Tor :grinning:

Happy to be a part of community who cares about the future of privacy for all :shield:

1 Like

Congrats for the Tor Team!

Heavy Tor user here, 5 years ago on the CaosComputerCamp I gave a workshop on making a crawler for Hidden Services, also generating some DataVizualizations… Was very lucky to meet some of you with Gabriella Coleman in the train back to Berlin… lots of intellectual generosity…

Long Live to Tor!