ZKV’s Polkadot/Kusama Baseline Report

On Friday Aug 21st 2020, in the midst of an extreme Berlin heat wave, we convened the first meeting of the ZKValidator Polkadot Working Group. We had at the table a combination of implementers, researchers and community representatives from Parity Technologies and Web3 Foundation. Participants included:

• Fredrik Harrysson, CTO — Parity Technologies
• Robert Habermeier, Co-Founder — Polkadot
• Alistair Stewart, Researcher, Protocol design — Web3 Foundation
• Jeff Burdges, Researcher, Applied cryptography — Web3 Foundation
• Fabian Gompf, VP — Parity Technologies
• Raul Romanutti, Kusama Community — Parity Technologies
• Will Pankiewicz, Master of Validators — Parity Technologies
• Anna Rose — ZKValidator
• Will Harborne — ZKValidator
• Thore Hildebrand — ZKValidator

We also did a short interview afterwards with Lucas Vogelsang, co-founder of Centrifuge — a Substrate-based chain that plans to incorporate zero knowledge proofs — to get a sense for how external teams might interact with the networks.

Before the workshop, we had collected feedback from the group through a form with questions related to the networks’ architectures, decision-making mechanisms, governance and ecosystem. We used this to guide to our workshop.

Our goals with the Baseline Reports are:

• to map the existing zero knowledge proof (zkp) and privacy tech in the networks we work on,
• to explore how decision-making & governance works,
• to determine who we should include in our privacy-focused working group going forward,
• to determine how the ZKValidator could add value.

As a quick summary of what we found, the following is a tl;dr of how the ZKValidator (ZKV) will aim to add value to Polkadot/Kusama:

• Privacy community building: Identify relevant teams that can build zk related substrate pallets.
• Organising workshops: Curate follow up workshops and events to further develop some of the cases for zkps
• Governance: Run for Kusama (and eventually Polkadot) council, and advocate for making privacy technology a priority.
• Funding: Support teams in getting grants or other funding, taking on the role of privacy curator.

Full workshop summary and details can be found in the report below.

— — — — — — — — — -

Workshop Report

Note: We discuss Polkadot and Kusama somewhat interchangeably throughout this summary. While we recognise that they are each unique ecosystems, they also will have many of the same features and equivalent tech as well as a strong overlap in the communities.

Polkadot/Kusama architecture:

As with our previous Cosmos workshop, we began by mapping out the Polkadot architecture. The aim was to understand at which level of the technology stack zkps and privacy tech could be included and where they would be the most effective.

Relay Chain:

At the core of Polkadot is the Relay Chain, where validators generate the system security and consensus. The Relay Chain logic is developed primarily by the Web3Foundation research team and the Parity engineers. While there are some ideas of how to use zkps here, so far these remain in the realm of research.

ZKV’s role: Track the zkp research being done by the research team Web3Foundation and communicate this to the wider community.

Parachains:

Parachains are individual blockchains that borrow the Relay Chain’s security while holding specific properties and functionalities of their own. Examples of likely parachain projects include Edgeware, Acala, & Centrifuge.

According to the group, there are two types of parachains likely to emerge:

1. Parachains that have submitted a deposit in the parachain auction. This requires access to DOTs. These DOTs may come from the team, their backers or crowdfunded from their community.
2. Public Good parachains where a slot is allocated to the project initiators without them being required to put up DOTs for it. These Public Good parachains are those that would add additional useful functionality but may not have their own token or other financial incentives. These would be decided upon through a democratic vote of token holders.

Examples of Public Good parachains that could be deemed strategically important by the community include:

• Critical infrastructure projects that do not have their own internal economy/token/distribution, for example DEXs or stablecoins.
• Bridges that do not have their own internal economy/token/distribution, such as a Ethereum-Polkadot bridge or Bitcoin-Polkadot bridge.
• Components currently in the Relay Chain e.g. governance

ZKV’s role: Support ZK related projects to secure parachain spots and co-develop proposals for Public Good parachains related to privacy.

Substrate:

Substrate is the framework that Parity has created to make it easy for teams to build and launch new parachains. However, teams can also use Substrate to build standalone blockchains. The framework consists of various modules/libraries that are referred to as “pallets”. There are a handful of pallets which may be useful for privacy. However, so far zero knowledge proof libraries or tools have not been a priority.

The initial sets of pallets were primarily developed by Parity employees, although ecosystem teams and independent developers are increasingly contributing to this work.

We learned that it is possible to take existing crypto libraries and wrap these into pallets. Grants are available for this, and ideally this will eventually also be funded through the on-chain treasury.

Three challenges of developing privacy-related pallets in substrate were highlighted:

1. Lack of UTXO balance pallets in Substrate, since Polkadot is primarily accounts based. A UTXO model is used in many private zkp transaction schemes such as Zcash. That said, it is possible to create interfaces between the UTXO and account-based models.
2. Few capable developers: Developers must have a combination of both strong math/cryptography & Rust skills as well as a deep understanding of Substrate. This means that talent is in short supply.
3. Lack of general-purpose privacy pallets: While some privacy teams are building narrow-focused pallets for their particular use-cases, these are not necessarily usable by other possible use-cases. So there would need to be a push to prioritize general-purpose privacy pallets. And given that most of the work happens within Parity, this push would likely need to also come from inside the organization at present.

ZKV’s role: identifying teams and independent developers that can build zkp pallets, support them in securing funding, and help to shape the types of pallets that gain priority. Curate bounties for specific pallets. Work to champion and advocate for privacy within Parity and the pool of substrate developers.

Parathreads:

Described as “Pay-as-you-go parachains”, parathreads are another environment in Polkadot where we could see the application of zkSNARKs and zkRollups. Parathreads are parachains that are temporarily participating (on a block by block basis) in Polkadot security without needing to lease a dedicated parachain slot. It could be possible to have the state transition of a parathread as a zero knowledge proof, or put another way, a parathreads can function as a zkRollup. A parachain could also function this way, but may be too expensive. This is a preliminary idea and would need to be fleshed out with the Web3Foundation research team. Also, the tools to write the necessary circuits for such a construction don’t yet exist.

ZKV’s role: follow-up with the research team and connect with zkRollup experts to determine how these zkrollup environments could be developed within parathreads or parachains.

Polkadot privacy community:

One of the workshop goals was to understand what groups make up the Polkadot/Kusama privacy community. As described by Fredrik Harrysson in subsequent conversations, “the community in polkadot that is interested in privacy is small, and the ZK Community is even smaller!” However, we believe this is a good moment to start growing it!

The majority of privacy-focused teams building in Polkadot are using TEEs (Trusted Execution Environments), a privacy architecture that relies on secure hardware. Whilst pragmatic, this solution has a risk of hardware backdoors built-in, which are hard to audit for. These teams included SubstraTEE, Advanca, & Crust Network. Other privacy-focused teams include: Zondax working with Hardware Security Modules (similar to TEE), and Zeropool working on a dark DEX

We were able to identify several projects working with zkps already:

1. Centrifuge: Pallets created by Centrifuge can be used to build a zero-knowledge verifier that verifies proofs generated for privacy of documents on-chain.

2. Phala: Primarily a TEE project, but they are now recommending adding zkps to further reduce attack surfaces.

3. Incognito: They have proposed to build a bridge between the Incognito layer and Kusama. Eventually they also plan to roll this out to Polkadot.

4. Matter Labs: Received a recent Web3Foundation grant to work on Zinc/RedShift ZK programming framework for Substrate.

There were some additional projects mentioned in the meeting that remain in stealth, but should be announced soon.

ZKV & Governance:

One thing that is unique about Polkadot compared with other existing PoS networks is the separation between the validation process and the governance mechanisms. In some PoS systems such as Cosmos, the validator also represents the token holders who back them. In the case of Polkadot/Kusama, this connection doesn’t exist. The DOT/KSM validator does not hold the votes of those that have staked with them. Still, given the mandate that the ZKV has presented, i.e. to promote and advocate for privacy-related technologies, it makes absolute sense to put ourselves forward for council and engage in the distribution of community funds.

The Council:The council is an elected body of on-chain accounts intended to represent the passive stakeholders of Polkadot or Kusama.

ZKV’s role: Running for council on both Kusama and Polkadot. We have already secured a seat on the Kusama council (see our announcement) and will be working in that environment to refine our platform and activity. We will then put ourselves forward for a role on the Polkadot council as well.

Curator: The role of curator would manage the allocation of funds in the form of bounties for a specific purpose funded by the Kusama treasury. The role doesn’t yet exist and is still in an experimental phase, but there is a plan to roll this out on Kusama shortly.

ZKV’s role: Once this is launched, we will put ourselves forward to be the acting privacy curators.

Referendums: There are also ecosystem-wide votes, known as referendums, regarding certain topics, such as the addition of a Public Good parachain, or the denomination vote. Generally, we saw that to really be involved, one must join the conversations on the Polkadot and Kusama Directions channels on Element (formerly Riot).

ZKV’s role: Participate in the Directions conversations. Here is a list of the current channels we are watching:

• Polkadot Validator Lounge
• Kusama Validator Lounge
• Polkadot Direction Channel
• Kusama Direction Channel

Conclusion: ZKV’s role in the ecosystem

As mentioned in the introduction, our goal with this workshop was to better understand this ecosystem, find where privacy-related activities are already happening and determine ways that ZKV can already deliver value to the community.

Here are the actions we believe we could take today in order to do this:

Privacy community building:

• Keep track of existing privacy-focused teams in the ecosystem and bring them together in group chats and online calls,
• Identify external teams that can build general-purpose zkp-related substrate pallets and bring them into the community,
• Gather information around privacy activity and communicate this to the larger community through our blog or additional forums.

Organising events:

• Workshops: Run follow up workshops to further develop some of the cases for zkps, such as using parachains or parathreads as zkrollup environments.
• Network-wide trusted setup: We are also exploring if we could produce something like a network-wide “Powers of Tau”-style trusted setup ceremony that could help secure future privacy projects.

Governance:

• Run for council on both Kusama and Polkadot.
• Participate in polkassembly conversations and champion particular causes related to privacy.
• Work to submit proposals with or on behalf of the privacy teams we work with.

Funding:

• Identify possible grant & funding channels for privacy-related projects and support in applications for funding.
• Apply to be funded directly from the treasury for our own privacy-related network activity.
• Become a curator and create bounties for others. This could take the form of privacy-related bounties or mini-grants.

We want to thank all participants of the inaugural ZKV Polkadot Working Group. Polkadot and Kusama are complex systems with rapidly expanding ecosystems. It is not easy to keep up with technical and governance progress, and we appreciate these participants taking the time to help us dive into the ecosystem and give us guidance for how the ZKV can be most effective!

For more information about us, check out the ZKV website and if you are a privacy team building on Polkadot/Kusama that we did not mention, please email us at hello@zkvalidator.com!

Lastly, if you want to support what we do, please do nominate the ZKValidator on Polkadot and Kusama — look for our validators in the Polkadot UI. Further instructions can be found on our website: https://zkvalidator.com/polkadot/