Multi-Gigabit Zcash
Network State Conference 2026 · 9 Oct 2026 · 5:14
Evan Forbes, an engineer at Valar Group working on the Zakura Zcash node, explains why private payments need bigger and faster blocks to feel as quick as card payments. He describes moving Zcash's block propagation from a robust but slow pull-based design to one that learns the fastest paths through a changing network, like a flock of birds, and looks at ways around proof of work's problem of simultaneous blocks, including a DAG approach and a technique adapted from proof of stake, at Network State Conference 2026.
Speakers
Topics
From Network State Conference 2026, hosted by Network School.
Transcript
Hello. So, I'm an engineer on Zcash. Zcash's development is very decentralized. So, the taxonomy can be a little bit confusing, but more specifically than Zcash, I work at Valor Group. More specifically than that, I work on Zakura, which is the really high performance Zcash client. And then more specifically than that, I make the blocks big and fast. So what we really want is these payment systems that work like Zcash. So they're permissionless, they're censorship resistance, and they
preserve privacy. And this is really difficult because there's so many different bottlenecks in different areas. So as other speakers have presented today, we have things like tachion and we have things like PIR which those things address different bottlenecks and then around like cryptography and privacy. Along with that we have bottlenecks around throughput so that everyone in the world can use Zcash at the same time. And then we have latency so that it's actually usable when you go to like pay a for any random item it's quite quick.
So this is like the the UX that we all uh sort of dream about and know and are used to and expect out of our payment systems. It has to be like this fast. One of the bottlenecks is block propagation. So this is how big the block can get. The bigger you can make it, the higher throughput it is. And Zcash previously didn't really need that high of throughput or that low of latency. However, it did need this robustness. So, there's typically these tradeoffs when we think about these block propagation protocols. Robustness is where data can enter the network at
any given point and the topology of the network can change arbitrarily. Networks get congested and they change in unpredictable ways. So Zcash has to be able to handle any arbitrary configuration there and this is quite difficult. So the the first thing that we optimized for was just robustness. We didn't really have to think about throughput or latency. And this is basically a if you're familiar with these protocols, it's a pullbased protocol. It's quite slow uh quite low throughput but uh works pretty pretty dang well. However, we can actually preserve that robust
quality of where the network can kind of look however it needs to look in that moment and we can learn on the fly of what's the highest throughput and lowest latency path for the data to take. So this is like um if you imagine like a school of fish or a swarm of like birds flying. This is uh more or less what the network looks like. We follow a few simple rules and from those rules even though we only have a local view we can we can find the highest throughput lowest latency path or at least close. So this is coming to a test
net near uh near you where we have this uh multi- gigabit uh throughput and much much faster blocks. Um we're able one of the fundamental problems with proof of work comes from its superpower. Proof of work is permissionless. It's censorship resistant and that means that anyone can produce a block. So as you produce a block uh it can happen that someone else produced a block at the same exact time and this is problematic because now you lose money effectively. It's it's like
uh some layers of complexity with mining pools. It's basically the fundamental problem of two people producing blocks at the same time. This is this is the bound on making things lower. So there's different approaches. You have this uh DAG approach where we simply let all blocks contribute to the chain or most blocks. And then there's a separate approach that we're working on now which is similar to autobond which is another thing from proof of stake that we're sort of adapting for proof of work and it's very similar in DAGs is in that we eliminate this problem. Both of these things allow us to make the blocks much much much faster and much much higher
throughput. That's it. Thank you.