Zcash New Node Zakura Launches: Privacy Payments Capable of 50,000 TPS, Targeting Visa and Mastercard
TechFlow Selected TechFlow Selected
Zcash New Node Zakura Launches: Privacy Payments Capable of 50,000 TPS, Targeting Visa and Mastercard
Privacy and performance are no longer mutually exclusive.
Navigating Web3 tides with focused insightsAuthor: Coindesk
Compiled by: TechFlow
TechFlow Editor's Note: Zcash can currently process only about 1 privacy transaction per second. The new node Zakura aims to reach 50,000 TPS—the processing scale of Visa and Mastercard—while maintaining complete privacy. This is an important signal for everyone concerned with payment privacy and blockchain scaling: privacy and performance are no longer an either-or choice.
Those rebuilding Zcash have a dream: to reach the level of global payment giants Visa and Mastercard, processing tens of thousands of payments per second, while maintaining full verifiability and strong privacy guarantees.
The first piece of this plan is Zakura, a new full node software that released version 1.0.0 on Wednesday. It is maintained by Sean Bowe, a founding member of Zcash zero-knowledge cryptography, and Dev Ojha, co-founder of Osmosis and current head of Valar Group. Both teams are funded by private ZEC donations, not companies or foundations.
"Our dream is to support global payments. Mastercard and Visa process over 50,000 transactions per second; this is our baseline. According to Zcash's existing cryptographic scheme, this transaction volume requires nodes to process over 500 MB of throughput per second," a blog post wrote. "The existing technology stack cannot reach this goal. The cryptographic technology our team is developing can close most of the gap."
Full nodes are programs that save a complete copy of the blockchain, here referring to the Zcash ledger, and independently check whether each transaction complies with network rules. Zakura is a forked version of the Zcash Foundation node software Zebra—that is, it was rebuilt starting from the Foundation's official code.
Consensus rules are the shared rulebook executed by each node, deciding which blocks and transactions the entire network accepts as valid. If a node applies different rules, it will fork and stop following the same chain as other nodes.
Pruning, Snapshots, and Compatibility
Zakura can also prune, meaning it deletes old blockchain data that nodes no longer need, significantly cutting disk usage. This compresses the chain to a small enough size that the team released ready-made copies, approximately 11 GB after stripping old data, which new nodes can download directly without pulling the full history block by block from other nodes.
This allows nodes to go from zero to running in less than two minutes, which the team calls "680 times faster."
Compatibility mode further replicates the interface of the original client zcashd, which will end its lifecycle on July 18, so wallets and exchange integrations built for it can continue to work as usual.
Throughput Goals and the Role of Tachyon
The reason for building all this is an arithmetic problem.
Mastercard and Visa process over 50,000 transactions per second, a number the team calls "a baseline, not a goal." Zcash's current cryptographic scheme requires nodes to receive and verify over 500 MB of data per second to keep up, because every privacy transaction carries a proof, and proofs are large in size.
This is roughly equivalent to continuously receiving the data of a full DVD every 10 seconds; currently, no Zcash software can come close to this level. But the key lies in understanding why each bottleneck exists.
Bowe's Tachyon project is solving this problem through recursive proofs, where one proof can verify the validity of thousands of other proofs, significantly reducing the amount of data that must be checked at the consensus layer.
Under the Tachyon scheme, nodes verify a single proof instead of thousands; the team claims this will reduce consensus data demand from 100 MB per second to 500 MB, which they believe is technically achievable through careful engineering.
Wallet Bottlenecks and Valar's PIR Solution
Wallets face different problems. Because Zcash hides the recipient of transactions, wallets cannot ask servers which transactions belong to them without exposing themselves. They must pull everything and test one by one, which is why wallet software can only reach about 1 transaction per second at most.
To eliminate this bottleneck, Valar Group is researching private information retrieval technology, allowing wallets to retrieve their own data from servers without letting the server know which entries were requested.
Fast Block Propagation
Fast block propagation means broadcasting newly mined blocks in the blockchain network as quickly as possible. Zakura is the software layer responsible for this task.
It must transmit new blocks between nodes quickly enough to enable massive proof and wallet traffic. It is equipped with an experimental system designed to deliver each block to every node within half a second, currently disabled by default.
Recent tests of these ideas will arrive in late July. Ironwood, officially named NU6.3, will activate at mainnet block 3,428,143, approximately July 28 at 8 AM ET, and Zakura has supported it since release.
Bowe stated on July 10 that all major organizations committed to activating at this height, one week later than originally planned, because exchanges and wallet providers requested preparation time.
The Origin of Ironwood
Ironwood exists because of a vulnerability that almost destroyed Zcash in June. The so-called shielded pool is the privacy side of the network, where amounts and participants are hidden, with zero-knowledge proofs serving as evidence of mathematical operations.
On May 29, Shielded Labs researcher Taylor Hornby discovered that the proof circuit of Orchard (the latest shielded pool) contained a soundness vulnerability, allowing attackers to mint fake ZEC on-chain without a trace. This vulnerability had existed since Orchard activated in May 2022.
Developers disabled Orchard through an emergency response completed on June 2, and then restored it with a corrected circuit via the NU6.2 hard fork at block 3,364,600 on June 3.
The patch could not resolve the four-year period during which the vulnerability was open. Zero-knowledge proofs reveal no information other than the fact that verification passed, so there is no record on-chain of the content of any Orchard transaction transfers, and no one can prove that fake ZEC was never created.
Ironwood was built to solve this problem. The so-called "turnstile" at the pool boundary limits what can leave and enter, leveraging the fact that the amount of ZEC entering and exiting the shielded pool is public, even though transactions within the pool are private. Closing Orchard to prevent new deposits, the turnstile becomes the only exit, trapping any fake coins inside.
Simply put, honest balances can migrate out over time, while fake coins may be prevented from fully exiting and entering the circulating supply. This setup traps any attempt at excessive supply at the boundary, restoring the reliability of the token supply.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
CoinDesk
