Ziggurat 3.0

Hey everybody, Mark here from Equilibrium . We’re happy to announce that we have submitted a proposal for Ziggurat 3.0, our most ambitious effort yet.

In previous grants we conducted single node network testing and that expanded into network-wide analysis. In this grant we will expand our crawler to gather more metrics and deeper insight about the state of the p2p network as a whole, even going as far as testing out a theoretical “suggesting best peers” method of strengthening the network. From there, we will expand the GUI to offer visualizations of the network topology and performance.

Finally, all of the work from this and the past two grants will culminate in a “Red team” event on testnet, where we will investigate all of our hypothetical attack vectors and see how it affects the network as a whole.

As always we are honored and humbled by the opportunity. See the proposal and more here


Hi @aphelionz very nice. Ziggurat is an example, to me, of a well-funded Zcash grant. The team has consistently updated documentation and pushed commits (I’ve followed silently until now) in the background with no real coverage from Zcash entities.

Good luck.

Heads up I think your proposal link needs the id to directly link to the post URL, instead of grid/overview page.


Thanks a lot @pkr! I’ll fix the gallery link.


Hello, @aphelionz Thank you for submitting your grant proposal! We will review it in the upcoming weeks and reach out if we have any questions.

In the meantime, if you have any questions for us, you can post them to this thread or DM us at @ZcashGrants.

Thank you.

1 Like

Our pleasure, @aiyadt. Thanks for the opportunity.

Looks great! Thank you so much for all the help you’ve given the Zebra team so far.

I would be interested in some more details for this part of the grant:

Using the crawler to provide nodes with lists of peers that would be most beneficial to the structure/goals of the network

I can imagine this might lead to some security issues, such as:

  1. A centralised crawler instance going down or being subverted, and providing peers that serve an attack chain or deny service
  2. The shared algorithm of all decentralised crawlers being gamed to provide peers that serve an attack chain or deny service
  3. The crawlers all providing the same peers, leading to those peers being overloaded

These issues already exist for the algorithms used by:

  • the ECC DNS seeder implementation (2/4 mainnet instances)
  • the ZF DNS seeder implementation (2/4 mainnet instances)
  • the zcashd peer crawler (most mainnet nodes)
  • zebra-network (a few mainnet nodes)

So it would be great to chat about what our peer and network goals are, and how we get a diverse range of implementations.


You’re very welcome, and thank you for everything on your end as well :slight_smile:

We discussed this briefly and the key is to keep things unpredictable enough so that there isn’t a viable attack vector. Some initial possibilities are:

  1. Introduce randomness or only react in the case of undesirable situations (the aforementioned islands or heavy node centrality)
  2. Use a “pac man ghost” strategy where we have multiple crawlers, each with their own task

Overall, yes, let’s talk about what the specific goals are and how we might tailor this work towards that. That will be the beacon that we follow. We can have a call or we can discuss here, whichever suits you.

I guess to start - is there a specific type of topology that you’re aiming for?

1 Like

Not particularly - there are a few different topologies that could harm particular network participants. But it’s hard to say anything specific without knowing what the current state of the network is, and how it changes over time.

So first I would ask:

  • What is the current network topology?
  • How stable is it?
  • Is the current topology acceptable, or do we need to make changes?
  • If we need to make changes, should we change nodes, DNS seeders, or something else?
1 Like

Makes total sense!

Would it make sense then to consider the peerlist suggestion milestone in the grant one of many potential remedies, based on the results of the more detailed (and passive) crawler analysis?

@teor friendly ping on the above question ^


I had assumed that most grants were flexible enough to change if the earlier milestones revealed new information.

Sure, we’re flexible on our end as well. Thanks again!

Hi @aphelionz and Zcash community! I’m on the DevSecOps team at ECC and I’ve compiled a few comments from our reviews/discussions.

The Ziggurat 3.0 proposal looks to be a comprehensive security solution.

Ziggurat/Equilibrium has been a trusted partner since before my time, and the team trusts them and is comfortable with their work. They provide expertise in cryptography and economics, along with the technical and blockchain expertise expected of a web3 security offering.

The project goes an additional step further with network analysis at the P2P layer instead of relying solely on RPC - anyone can fuzz an API endpoint, Ziggurat/Equilibrium has actual blockchain expertise. Also helpful for gathering detailed network metrics.

Focus on the network layer seems appropriate given there are no smart contracts or user uploadable code like e.g. Ethereum, Solana.

Network topography metrics could facilitate increased awareness of any intended or unintended centralization.

Proposed Solution - bullet point 5 “Using the crawler to provide nodes with lists of peers that would be most beneficial to the structure/goals of the network” potentially effective at identifying and removing malicious nodes.

Proposed redteaming exercise could confirm these mitigations.

Currently the majority of the work exists in two GitHub repositories:

The second link is broken

  1. https://github.com/runziggurat/zcash-gui

A privacy concern:

“Anonymized” topography data such as connection speeds, cloud status, and other stats that tools like nmap might allow.

This mainly concerns me from the standpoint of undermining Zcash privacy features. As long as this is not done in a way where this is possible, it should be ok.

Historical metrics in the GUI would indeed be useful, especially for on-call responders.

As would the Intelligent Peer Sharing Option, as long as it properly mitigates centrality.

Given their past experience with Zcash, overall blockchain/crypto body of work, and liaison with the developers, I believe we can trust their red teaming exercise to be appropriately thorough and tailored to our project. If enough testnet nodes can be coordinated, it could be quite a valuable simulation.

Unintended consequences are valid, and in-line with any other security offering from anyone else. While the concern about weaponization of scanners is valid, as with many other open source security tools, the benefits of leaving the code open sourced likely outweigh any downsides.

The “risks and mitigations” reflect the difficulty of the project. In summary, this is a HUGE undertaking which, if done correctly, would strengthen the security posture of the Zcash network.

Overall, the project is a substantial undertaking that has the potential to significantly increase Zcash security posture.


Thanks for the feedback @bbeale. I’m looking into making the runziggurat/zcash-gui repo public now, but if you want to just see the current GUI, you can see it here: Ziggurat Explorer