Sean Bowe - Zcash Tachyon: Encrypted Money at Planetary Scale - TOKEN2049 Singapore 2025

Hello everyone. Uh my name is Sean Bo. I'm a cryptographic engineer working on the Zcash project. And um if you're not familiar with Zcash, uh Zcash is encrypted money, encrypted money. Um, we launched Ccash about 9 years ago as a fork of Bitcoin and we incorporated really really strong privacy guarantees and and properties in our uh transactions.

And um we did it through the use of zero knowledge proofs and ZK snarks. And um the researchers actually that uh were behind Zcash were the developers and the original kind of inventors of the science behind ZK Snarks and zero knowledge proofs. And we were the first team actually to to deploy Z uh zero knowledge proofs in production not just in uh blockchain world but in but in any product ever. And um after our launch we uh started improving the privacy and security of Zcash and uh we a lot of papers and elliptic curves and code and stuff like that came into the blockchain ecosystem and pretty much everyone in the blockchain space uses in one way or another the stuff we produce for Zcash. Um but most of the ecosystem most of the blockchain world uses uh zero knowledge proofs for scale and for performance which is fine but um we personally use it for privacy.

I mean we we need to use it for privacy um because we don't know how to build encrypted money without zero knowledge proofs. And so Tachon, the project that I'm working on is an effort for the next year or so to integrate the next evolution of uh cryptography in Zcash to uh scale the protocol. We need to eliminate all of the remaining cryptographic bottlenecks and scaling bottlenecks in the protocol through the use of uh a marriage of the scale and privacy properties of ZK Snarks and recursive proofs and some of this other cryptography we've been working on for years. um in order to make it so that everyone on the planet can use encrypted money in Zcash. So uh just a quick uh trip through most of the projects in the space most of the platforms have been executing on these three pillars of uh privacy uh usability and scale actually privacy more recently and the all three of them are very important I think but uh they all the order in which you do this actually affects how your product works and it affects how well you well your architecture and your your software and your protocol works.

Um so most of the projects in the space have been uh they've been trying to find product market fit right so they've been uh attracting funding users developers raising capital all that kind of stuff then they figure out where they should invest their effort into scale and uh adapting to usage of the protocol and then of course they realize kind of late especially the last year or so that they need to add privacy to their protocol and if they don't I mean this is like an existential like this is a requirement of distributed finance. Uh we really need privacy and pretty much uh everyone has has realized that and started making uh privacy plays lately. Um the problem is it's a little bit too late once your architecture is scaled and it has all these features and stuff. It's really hard to just bolt privacy on at the end. Um, and the reason for that, there's there's multiple reasons, but you as cryptographers, we know we can't just put privacy in on the top layer or bolt it on at the at the beginning.

It doesn't really work like that. We need we need it at the foundation of the protocol. We need it uh to be also not just as the foundation of the protocol, but pervasive. we can't just put it on top because all the layers below in the software architecture and the protocol uh can kind of compromise the layers above it just like with security issues as well. Um so in Zcash we actually have done it in a completely different order.

We we started with really really robust privacy. I'm going to talk about that in a second but really strong privacy. Then we spent many many years making it extremely usable. Uh and I should I will also show you that as well. I'm really excited about um our progress especially over the last year and finally with Tachon we're going to make it scale uh by removing some of the last remaining uh bottlenecks in the protocol.

So why do it this way? Like I said uh you don't want privacy to be an afterthought in your protocol design and so we need to integrate it uh early on. That way you know you don't do a bad job of privacy later, you don't do a bad job of usability later. uh you don't do a bad job of scale or it doesn't take you longer to make to make it scale. So just real quick when I say that uh Zcash has really strong privacy guarantees I'm saying that it has this property called ledger indistinguishability which uh cryptographers use to study the privacy uh properties of cryp uh cryptocurrency transactions.

And basically just like within encryption, it's a security notion that says, "Okay, we can't tell the difference between two shielded transactions." And um unlike in Bitcoin where you can see like the the key material and the um the transaction graph and all the values and everything, it's just looks like an opaque uh random bite string. And so we can't actually tell the difference between two children transactions in Zcash. This basically solves all of our problems when it comes to privacy because we don't have to just plug leaks everywhere. We already know from the beginning that it's uh that it's private.

Um it does have an impact on scale and makes it a lot more tricky to scale things. So we launched our original uh protocol in 2016 with Ledger indistinguishability. Um we brought ZK Snars in the world to do it. However, it was too expensive. Like you couldn't run this stuff on your mobile phones.

you had to run this on like a BV desktop server. So, a couple years later, after a bunch of uh new innovations, we were able to uh make the cryptography much more efficient and more secure and we launched an update to it, which um uh made it so that we could actually run it on mobile devices. And then we've done all sorts of different upgrades since then, but the the latest upgrade uh Orchard is what most people in Zcash use. it actually removed this the trusted setup from our protocol. Um, and you'll notice that we we've never really done a a privacy upgrade in Zcash that like improved the privacy because we haven't had to do that.

Uh, our protocol already used ledger indistinguishability from the very beginning and uh, ledger indistinguishability captures every single privacy problem on chain at least that we need to worry about. We can of course improve make it make it more quantum resistant. Uh and in some ways it already is but uh that's about it. So uh just real quick. So we we kind of have privacy nailed down usability.

Uh we have a fantastic wallet for using Zcash right now and it's built by cryptographers. It's built by um uh privacy experts and it incorporates all of our privacy conscious uh decisions for the design in the protocol and uh it's really easy to use, really stable. I love Zashi and it has all sorts of new features all the time. Um uh especially over the last couple weeks which have been getting a lot of attention that kind of looks like the Zcash price graph right now, but it's not. It's actually the amount of coins in the Zcash land that is uh living in this uh shielded pool that where all the encrypted money lives.

Uh we also have hardware wallet support and ledgers adding support soon as well. So that's helping a lot. So we're making a lot of progress on usability and and it's paying dividends. Um so the three issues with scale that we resolved with Tachion are uh the first thing is double spend prevention. The way that we prevent double spends in our protocol doesn't really scale.

Um the way that the uh people receive money in Zcash doesn't really scale either. We have to kind of scan every transaction that takes place on the chain and also the transactions are much larger because of the uh because the proofs are much larger and they take more time to verify than what you would expect from like a Bitcoin transaction. So uh starting with the stouble the double spend prevention. Um, so our protocol and pretty much every other protocol like ours uses this thing called a nullifier, which is like a revocation token. And whenever you spend some money, you re you reveal this nullifier and it's it's basically just random bites.

But um, and it can't you can't distinguish them between each other and they're just they they don't link with anything. But um, if you try to spend the same money twice, you will reveal the same nullifier twice. And so the way the network prevents you from double spending is it just remembers all the nullifiers that you you've seen before and then uh prohibits you from uh uh repeating them again. It treats repeats as as double spends. So um that's obviously a scaling challenge because every single node on the network, every validating node needs to store every nullifier that's ever been seen before forever.

I mean we can't go back and prune any of it because uh then somebody could double spin. Now, just to illustrate just how bad this is, um even if we were just having 100 transactions per second, it would result in about a gigabyte of state growth per day, which is for for state growth purely is actually really really high compared to a lot of other blockchains, including even like Salana. Um so the solution we've known for a long time involves recursive proof. So I won't go into too much detail, but essentially we prove we have the user prove that they haven't spent their money and then attach that proof to their transaction and submit that to the network. Only it's a little bit tricky.

Um it's required a lot of research. The uh and and the researchers behind Zcash have uh developed it over years and and came up with the first uh concrete implementations of it. And then I uh co-authored some work with some other um Halo or sorry with some other Zcash developers on something called Halo where we actually were able to make this practical. Um so right now in the protocol we uh submit our transaction to the network. The nullifier uh list is kept by all the validators.

It's it is linear in the number of transactions. Doesn't scale doesn't work. So we fix that. we uh download the history right to the wallet and then create a proof. Well, that works because the validators can prune the uh nullifiers uh so they only have to really maintain the most recent nullifiers.

But the problem is the users exposed to the bandwidth and computational expense of all of the uh other transactions that everyone else is doing on the network. So to solve that we can add an intermediary. This only somewhat helps the problem. So you have the intermediary ingest the uh the blockchain history and then construct the proofs for you after you send the transaction to the intermediary. Uh this works but then there's this huge latency cost between your transaction being uh produced and then accepted by the network and um and also the the intermediary has to operate over the entire history of the chain every time you do this.

So to solve that, we could try to send the nullifiers to the service in advance of when we want to create our transaction, get a proof back, and then when we're ready to um submit our transaction to the network, we could just attach it the the proof that we got back to our transaction and post it. The problem is there's a privacy leak. Uh it's a pretty bad one where the service actually gets to link all of our transactions together. Uh they get to see they get to distinguish her transactions. So that's not going to work.

The solution that we came up with is this thing called oblivious synchronization which is this general technique essentially to allow the remote service to uh prove for us that we haven't spent our money uh without seeing or seeing any information that we end up posting on chain in the transaction. So they can't distinguish our transactions. So we don't trust them at all. And um this it's a little more technical than than this but it's it's it's pretty much how it works. Um so you get you get pretty much everything that we want.

The validators don't have to store all the nullifiers. The users themselves aren't exposed to the bandwidth and computational constraints uh or or or cost that that scales with the number of other transactions or other users in the system. And we don't uh compromise on ledger indistinguishability. So the other two scaling issues that uh we also are addressing in Tachon I'll just go over real quickly. Um the blockchain scanning issue is one that we solved not with cryptography necessarily but with a change to our protocol design and our payment protocol.

Um transaction size and verification were able to use the same techniques of recursive proofs and proof carrying data that we used to solve the uh to to build the oblivious synchronization uh primitive for uh scale. We can use that for this as well. And in fact, it's not really a a like a a new idea. This is an old idea just applied to the same uh construction. And once you kind of go through it, you realize that the transactions end up being pretty small.

Like the marginal transaction size is around the size of the Bitcoin transaction around the same verification time as well, which is really good because it's a completely private uh transaction. Completely private. Um so, Tachon timeline. Um, we're going to mainnet this in the next year and I'm really excited about that because um, we're pretty much uniquely positioned to pull this off. We have the team that's been working with this kind of cryptography for years.

We've also been shipping upgrades like this to uh, our protocol for the last 10 years, these massive uh, uh, upgrades to the cryptography that are really complicated that require a lot of uh, effort and auditing and so on. So, we've been doing this for a long time and not very many of our other sort of competitors, I guess you could call them, uh are really able to use this sort of um architecture currently. This is kind of too new for them. So um yeah so the the goal of this is to remove all the uh bottlenecks in the protocol and I think that's what it's going to do and um essentially leaving us in the same position that the Ethereum Salana etc people are in where they're trying to scale and they're they're uh constrained mainly by uh bandwidth and uh latency issues. So uh yeah that's it pretty much.

Thank you. Um, I have a uh a set of blog posts where you can dive into the technical details if you'd like. So, thank you very much.