Proposal: zec-go, An Independent Zcash Full Node Client in Go

Community Grants Applications
1

Hello Zcash Community,

We are excited to announce that our team at Chainscore Labs has submitted a grant proposal to the Zcash Community Grants (ZCG) program for the development of zec-go: a new, independent, clean-room full node client for Zcash, written entirely in the Go programming language.

You can read the full proposal and grant application here:

Why Zcash Needs Another Node

Client diversity is critical for the health, resilience, and decentralization of any blockchain network. As the Zcash ecosystem evolves and zcashd approaches deprecation, the network risks becoming heavily reliant on a single implementation (zebra). This centralization introduces systemic risk, as a consensus bug or vulnerability in one client could disrupt the entire network or cause a chain split.

Proposal: zec-go

zec-go is our solution to this problem: an independent, alternative full node client for Zcash built from scratch in Go. Our goal is to enhance network resilience and performance by providing a third, production-grade node implementation.

We chose Go to leverage its memory safety, powerful concurrency model (goroutines/channels), and broad developer ecosystem, which is ideal for building a high-performance and maintainable node.

What We Will Deliver

Our proposal covers a 12-month, 7-milestone plan to deliver a production-ready node capable of:

  • Connecting to the Zcash network and gossiping blocks/transactions with peers.
  • Performing a full Initial Block Download (IBD).
  • Validating the entire chain history from genesis, enforcing all consensus rules across every network upgrade (Sprout, Sapling, NU5, etc.).
  • Managing a full mempool for unconfirmed transactions.
  • Producing blocks for miners.
  • Passing the Ziggurat network conformance test suite to ensure robust compatibility.

About Us

Chainscore Labs, founded in 2021, is a Web3 research and development firm specializing in core, high-performance infrastructure for leading blockchain ecosystems. Our team possesses deep expertise in protocol-level engineering, applied cryptography, and decentralized systems. We have a proven track record of delivering production-grade infrastructure, with experience directly relevant to this proposal:

  1. Tessera (Polkadot/JAM Full Node Client)

We developed a clean-room, independent, alternative implementation of the Polkadot-JAM full node node client in Python. This demonstrates direct, hands-on experience in building a complex, high-performance full node from the ground up, parallel to the core requirements of zcash-go. It included:

  • Consensus & VM: RISC-V VM (PolkaVM) supporting 1M+ TPS
  • Storage: Erasure Coding based Data Storage (632MB/s)
  • QUIC-based P2P Networking with 1000+ Nodes
  • Performance: Achieved a 10ms block time, demonstrating an understanding of low-latency block processing.

Releases: GitHub - Chainscore/tessera-releases: Clean-room implementation of JAM Full Node Client in Python3.12
Codebase:

Documentation: https://tessera.chainscore.finance

  1. DotRing (ZK Crypto Library):

Our team developed DotRing, a library implementing the IETF, Pedersen and Ring Proof on 20+ Elliptic Curves including Bandersnatch, built from scratch without any third party dependencies. This project highlights our deep expertise in applied zero-knowledge cryptography, a domain central to Zcash. Supported by a grant from W3F.

Github Implementation: GitHub - Chainscore/dot-ring: ZK Suite of libraries for generating and verifying Pedersen and Ring Proofs
Specification: GitHub - davxy/ring-proof-spec: W3F Ring Proof Specification, GitHub - davxy/bandersnatch-vrf-spec: Specification for Bandersnatch VRFs

We welcome all feedback and questions from the Zcash community.

5 Likes
2

I like the idea of client diversity! How do you intend to ensure 1:1 compatibility with the Rust client (at least for the consensus protocol)? It’s not listed as a deliverable, but IMO the test tools/process to ensure client compatibility would be one of the bigger efforts required for this project to succeed.

And ideally those tools would be available for future client implementations as well

3

I honestly think it is impossible to write this in 1 year with 2 developers.

7 Likes
4

@conradoplg We’re a team of 3 engineers with prior experience building full node clients. To note- for the cryptography module we’ll be utilizing existing libraries via FFI in this phase. Based on our past experience, we’re confident that 12 months is sufficient for developing the full node, and we’ve also included a contingency budget in case additional time is required.

5

@phreaknik You’re right the test process is a massive effort. This is actually our capstone deliverable for Milestone 7. For the last two months of the project, we will be rigorously testing zec-go against the Ziggurat network conformance test suite. This test suite was built by ZCF specifically to find behavioral divergences and P2P incompatibilities between zcashd and zebra. Passing this suite is our primary metric for success and the main acceptance criteria for our final milestone. In addition to Ziggurat’s conformance tests, we will explore developing a fuzzer / fuzzing strategy to generate a random, high-speed stream of blocks and transactions to test the node’s validation logic and stability under pressure.

1 Like
6

More on importance of client diversity - https://youtu.be/MY8LFVqBOyA?si=9l-JJUjT_jMqdYds

7

Your GitHub has 7 followers, a handful of repositories with hardly any stars and you have no track record with the zcash community. I am sorry but this doesn’t give me confidence in your ability to write a full node for zcash.

3 Likes
8

While our GitHub metrics are modest, we’d ask you to evaluate our team’s specific, demonstrated experience. You can check our previously developed node client implementation, Tessera, for Polkadot/JAM, here - Getting Started | Tessera JAM. For which we have implemented the following from scratch:

  • Consensus & VM: RISC-V VM (PolkaVM) supporting 1M+ TPS

  • Storage: Erasure Coding based Data Storage (632MB/s)

  • QUIC-based P2P Networking with 1000+ Nodes

  • 10ms block time, demonstrating low-latency block processing

We also built ‘DotRing,’ a ZK cryptography library for Ring Proofs - GitHub - Chainscore/dot-ring: A Python library for generating and verifying advanced VRF-AD Proofs

Happy to give you access to the code, please DM. Some of our repos are private as they are under development and pending audit.

We believe this hands-on experience in complex protocol engineering and ZK crypto is directly relevant and demonstrates our capability. We’re here to contribute, we already have track record contributing to other leading ecosystem, and we hope our work will earn the community’s confidence.

9

I think the idea of more implementations of full nodes is very good.

However, in agreement with @conradoplg above, I fear the task is too large.

To follow this, is half a full node implementation useful? Would it be possible to break the task up into smaller tasks?

I don’t know this team but I think at some point this is work that should be done. I don’t know if now is the time, or if this is the group to do it, but if the task can be divided into smaller chunks, maybe that is worth considering? I would have to defer to the full node developers who have worked on (or very closely) with Zebra and Zcashd

2 Likes
10

Hi aaal, thank you for the feedback. You and @conradoplg are right to be concerned about the scope, it’s a massive undertaking.

That’s exactly why we’ve broken the full node development into 3 distinct phases:

  • Phase 1 (this proposal): Core Node Operations - Here we will focus on base layer of the node: P2P Networking, State, Block Import and Production, etc. The largest module would have been cryptography, our core strategy is use the existing, audited librustzcash for all proof verification (Groth16, Halo 2) and signature validation (RedDSA). This massively de-risks the project, isolates the work to Go protocol logic, and is what makes the 12-month timeline for this phase achievable. Additionally we have broken down the development into 7 milestones over several months as in the proposal.
  • Phase 2: Cryptography - Implementation of cryptographic primitives, Sprout, Sapling and Orchard stack from scratch in Go
  • Phase 3: Security Audit and Performance - This would involve a full external security audit, optimisations and performance benchmarking for a Mainnet release.

We believe this phased approach is the most responsible way to tackle a project of this magnitude and focuses on delivering a verifiable, useful, and consensus-compatible core client first.

11

About my reasoning: it took Zcash Foundation more than 3 years to develop Zebra (with just consensus parity but not RPC parity), and we also use librustzcash. Granted, some issues along the way could be avoided by your team - Zebra had to be designed from scratch, while your implementation could be inspired in Zebra; ZF planned to have a totally independent implementation but then switched to using librustzcash. On the other hand you will have to handle FFI which I understand is also a huge pain.

So 1 year simply sounds impossible.

Also some additional notes:

  • Ziggurat just tests the networking logic, not the consensus logic
  • “This centralization introduces systemic risk (…) cause a chain split.” It is in fact much more likely that a chain split could happen with two different implementation. This has always been our biggest fear with Zebra and zcashd.

I like the abstract idea of having two independent nodes (it was the original reasoning behind Zebra after all) but I just don’t think it’s worth the effort right now.

4 Likes
12

We are confident we will be able to develop Phase 1 in 12 months. Since the proposal is milestone-based, we are willing to take the risk even if it ends up exceeding 12–24 months

13

This is based on your own words. I cannot verify anything since you have no references and the source code is not made public.

14

Sure that’s fair. Here’s the referred code-base of our experience developing full node client and cryptographic libraries:

Tessera, full node client for Polkadot/JAM:

Dotring: ZK Suite of libraries implementing IETF VRF, Pedersen and Ring Proofs on 20+ ECs

3 Likes
15

Thank you for your submission. After consideration from ZCG and sufficient time for the community to provide feedback on the forum, the committee has decided to reject this proposal.

The committee appreciates your grant submission efforts and encourages you to continue as an active member of the Zcash community going forward!

16

Thank you, I appreciate the review; also @conradoplg @hanh @aaal for your time and feedback.

2 Likes