Intro
ZK-tech (Zero Knowledge tech, zk-SNARKs and other related tech) allows us to do many things when it comes to privacy and scalability in decentralized, open networks. There’s a lot of overlap in terms of what Vac is trying to do with Waku, regarding privacy and scalability, with ZK tech that is actively being built.
Since our initial journey into them almost two years ago (https://vac.dev/feasibility-semaphore-rate-limiting-zksnarks) things have improved a lot. Tooling has improved, performance, knowledge, the number of people working on it, the constructs that exists and are being worked on.
Just like there was an explosion of p2p protocols and networks in the early 2000s, and cryptoeconomic incentive design became a thing with Bitcoin, Ethereum et al a decade or so later, there’s a new kid on the block that complement these: ZK-tech. Starting with crossing the chasm from academia to running in production with Zcash 5 years ago, it has now spread across other ecosystems, such as the Ethereum one. It is a new, orthogonal technology which unlocks new types of protocols and applications.
Here’s a list of all the type of things the applied ZKP team at EF is working on: EF-Supported Teams: Research & Development Update | Ethereum Foundation Blog
Of course, they are not alone in pushing this in the Ethereum ecosystem, and there are many other projects working on this. As far as starting points go, https://zeroknowledge.fm/ is a great podcast to learn more. Sanaz and I were on this to talk about RLN for spam protection earlier this year: Episode 186: ZKPs for Spam Protection & Decentralized Messaging with Status - ZK Podcast
Basically, the field is exploding and we have the chance to help build and use these new amazing tools.
RLN for spam protection
RLN is a privacy-preserving spam protection mechanism. We have adapted it for use in open p2p networks with Waku RLN Relay.
This has been a long ongoing effort, but this is largely because the construct is quite new, the design has evolved, and the work spreads across many domains. There are a lot of blockers, and they’ve been slowly getting resolved.
Sanaz has been doing an amazing job here, and we are very close to a point where we can start to test it. For more, see:
- Write-up: https://vac.dev/rln-relay
- Spec: 17/WAKU2-RLN-RELAY | Vac RFC
- Draft paper: https://github.com/vacp2p/research/blob/master/rln-research/Waku_RLN_Relay.pdf
This has been a close collaboration with independent ZK researchers as well as the applied ZK team at EF. Kudos to Barry, WJ, Onur, Kobi.
Waku as a service network
We can look at Waku as being an open service network. We have adaptive nodes (30/ADAPTIVE-NODES | Vac RFC) that provide services to other nodes, such as storing, filtering, or pushing messages to the relay network.
Previously, in addition to RLN for private spam protection, we have also been exploring SWAP (18/WAKU2-SWAP | Vac RFC) as a way to do accounting and settlement between nodes. However, SWAP has a few issues (in addition to us not yet having a hire to attack it seriously beyond basic PoC stage):
- It was initially designed for bandwidth and pairwise interaction, i.e. where both nodes contribute to each other.
For us, while this is still possible, it is likely not to be the dominant use case. It is more likely some nodes will primarily be providing a service such as storing messages, and another node consuming them. This means some of the aspects of SWAP might be needlessly complex.
- It doesn’t help us find good node providers.
While SWAP is game theoretically sound for long term cooperation (i.e. repeated games), it doesn’t help us find useful nodes in the system.
This doesn’t mean it doesn’t have a use, just that it might not be enough, and in some scenarios it might be overkill. One nice thing it does is that it allows a user to get started without any crypto, provided they have a service to provide to the network.
Towards a ZK-centric design
Private spam protection,
Private node reputation,
Private settlement.
If we have this, we have the building blocks for a private, incentivized p2p network. Of course, we still need things like discovery, store synchronization, accounting, etc.
We have looked at private spam protection already.
With private node reputation mechanisms like Unirep, we can have a private, non-repudiable and economic reputation mechanism. This means we can find nodes that provide a good service to the network. This simplifies the settlement aspect from a trust/reputation point of view. Obviously this is a very high level view but it is a promising direction to explore. See Research private reputation mechanism for finding good service nodes for resource-restricted devices · Issue #89 · vacp2p/research · GitHub for more.
Private settlement means we can cut the economic public link between a node providing and receiving a service, something that is desirable from a privacy point of view. This is possible using Semaphore and having fixed denominated reward in terms of secret commitment.
Next steps and conclusion
As for next steps, nothing major is going to change. We’ll keep working on RLN and test it, get a paper out for it and see what is needed to take it to the next level.
I’ll also personally start looking into the private reputation mechanism (Research private reputation mechanism for finding good service nodes for resource-restricted devices · Issue #89 · vacp2p/research · GitHub) to understand it better.
This is quite a high level overview, and a lot of details have to be filled in and researched further, but hopefully it gives some idea of a more coherent design, one that uses ZK-tech to enable a protocol design that embodies Status principles (https://our.status.im/our-principles/).
It also allows us to put more wood behind fewer arrows, and personally I think it is quite an exciting direction and an opportunity for us to be involved in pushing this forward from an applied research point of view, and making use of this technology in the real world.