Open Source Monday: Zero-Knowledge Proofs

For the third installment of our “Open Source Monday” blog series, we provide a demonstration and example code of how Zero-Knowledge Proofs can be applied to clean energy applications.


Zero-Knowledge Proofs (ZKPs) will be very familiar to blockchain experts and cryptocurrency enthusiasts. As we described last week, there are also non-financial applications for ZKPs in the clean energy sector. 

Imagine that you are an electric vehicle charging station company. You collect data from charging stations that have a huge amount of individual information. You collect and centralize that data for billing and maintenance. Some of the data could even be considered personally identifiable information. That is, time, location, vehicle type, etc. could be pieced together to identify an individual even without having a specific name of a person. 

In summary, your data is valuable. Others ask for it. The local utility wants access to help plan grid upgrades. The local government wants to use it to plan public transportation. Community groups want access to learn the impact on the environment. Do you hand over your data to them? A better approach would be to enable them to ask questions of your data in an anonymized way without you physically transferring the data. Fewer copies means less risk.

As an energy planner (e.g., utility, government, community group) how do I know the data is real if I never see it? This is where ZKPs come in. ZKPs can prove that the data is as expected without having to reveal the actual data itself. 

The video below shows an example of some of the steps to accomplish this. 

What you’ll see is:

  1. Two different “customer” datasets are provided to form a single dataset. Continuing the analogy above, this is like the EV charging station company storing two different customers’ data in the company’s database.
  2. That data is off-chain. A central Oracle creates a non-interactive proof.
  3. The Oracle also converts the proof into an image.
    The data is an array and each value in the array
    is represented by a proof in the form of a grayscale pixel.
  4. A new ZKP verification ERC721 compatible smart contract is created and an NFT of the image is minted.
  5. Using Truffle, a smart contract can be called to execute the validation of data without revealing the identity of the individual.

For our implementation, we take advantage of some recent advances in ZKPs. In particular, many ZKPs rely on some interaction with a prover and a verifier. They ask each other a series of questions to validate the data. Here, we apply an approach inspired by zk-SNARKs. The “N” in SNARK is for Non-Interactive. The genius behind this approach is that all the proof can be provided in a single message to the verifier, eliminating the traditional back and forth. There is a LOT of math behind this which is out of scope for our example. You can learn more about the math and how it works thanks to Zcash. For simplicity in this example (see GitHub), we use a simple hash implementation rather than a full zk-SNARK.

One other addition that we made here is that since the proof is a simple message, we can codify it as an image. We can then mint the image as an NFT. The big advantage of this approach is that proofs are visible to everyone and searchable by anyone on a platform like OpenSea or Coinbase without revealing any individual data. This removes a transaction headache for the data owner. They don’t need a new system or special hosting, etc. to handle inquiries about their data. 

And, the last addition, is that we have an example Polygon smart contract that enables an individual to validate their own dataset. What the validation code enables is that the EV charging company and / or energy planners who incentivize data owners to validate data get greater assurance that the data is real. This is a great use case of data privacy enabled through crypto.

The basic principles here can be applied to many sectors where there is centralized off-chain data, strict data privacy needs, and a need to prove the data is valid. Next week, you’ll see an expansion of this proof to leverage more of the zk-SNARK stack.