Zero trust, always verify [1]

Trust - a simple word but yet such a complicated concept. To determine if someone or something can be trusted, the process tends to involve some evaluation based on a combination of human traits: knowledge, judgement, ethics, morals, to name a few. I cannot do it justice to even try to explain the concept of trust (it took a PhD to formalise trust [2]!). If it is a computer system that is doing the evaluation, then not only does it need to be given the information but also the rules on how that decision should be made. What if the information required by the rules is not all available? The system’s behaviour will be determined by the designer/programmer of the system. A trivial example: a system presents an interface for a user to enter their username and password -> the user inputs some text as the username and some text as the password -> the entered username and/or password does not match with what the system expects -> the system rejects access request.

There are many scenarios where someone or a system wants to be trusted (e.g. to gain access) but cannot reveal all the information required, for example due to privacy concerns. Having the ability to prove to other parties that you can be trusted, without telling them any of the secret information needed for the evaluation process, would be very useful. Imagine if you receive a call from an unknown number, the person on the line claims that they have important information about your bank account, but they need to verify that you are who they want to speak to first. Neither of the parties involved in this scenario can blindly trust the other. However, if the identities can be verified using cryptographic evidence, i.e. you give the caller some cryptographic data and they would be able to tell if you are telling the truth or not, and vice versa, then no confidential information is shared in this conversation.

On the other hand, having the ability to verify if the information they are getting is accurate and can be trusted is also very powerful. Companies have strong incentives to hide or even lie about certain information disclosed to the public [3,4,5], so if the information is important then it is crucial that the information can be verified. Traditional systems very much depend on manual processes to do the verification, e.g. the UK voting sytem. The voting in the UK only happens once in a while, the same manual process cannot work if it is applied to a system that has a much lower turnaround time requirement.

The above can be applied to carbon emissions reporting. Firstly, carbon emissions data are very important for tackling climate change. Carbon emissions is a measure of greenhouse gas released into the atmosphere (expressed in terms of carbon dioxide equivalent, CO_2e), as a result from burning fossil fuels for generating power, heating, cooling, manufacturing goods and foods, and transportation [6]. Without data we cannot know the state, and without knowing the state we cannot track changes or progress. Secondly, carbon emissions accounting often involves supply chains. It is challenging to get accurate data from company to company for the same reasons mentioned earlier. There are emerging standards for exchanging emissions data between companies. For instance, WBCSD [7] is leading the effort and has produced a set of standards for emissions data exchange [8]. However, the data exchange methodology does not currently involve cryptographic verification. So to achieve trusthworthy carbon emissions reporting, we need a way to verify the claims without revealing any business sensitive data at the same time.

This “zero trust, always verify, private data protected” goal can be achieved by applying zero-knowledge proofs.

USE CASE 1

My first paper on this topic was accepted at the LOCO 2024 workshop [9], which introduces the concept of applying zero-knowledge proofs (ZKPs) to achieve verifiable carbon emissions claims without compromising business sensitive data in a cloud computing scenario. The ZKP is constructed as follows:

USE CASE 2 (an extension to use case 1)

Considering the cloud computing scenario above, we can imagine that data centre operators buy both carbon emitting energy and clean energy from their suppliers. This means that the electricity consumed at the data centre has different carbon intensity factors, depending on the type of generation source. We can also imagine that the pricing could be set differently based on power consumption, and customers could choose to pay more to be carbon-free for their services. Whilst it is not possible to directly measure the amount of carbon-free energy being used by individual customers, we can apply the same Greenhouse Gas Protocol’s “Completeness Principle”. The principle states that the total amount of energy consumed by all the customers add up to the total amount of energy contributed to the carbon emissions at the data centre (internal use can be counted as non-paying customers). For example, if the data centre bought 50% carbon emitting energy and 50% renewable, and if one customer, consuming 1% of the total power consumption, has signed up for 100% carbon-free energy, then there should be 50% carbon emitting energy and 49% renewable for the rest of the customers.

The chain (much simplified with details omitted) looks something like this:

Let X kWh be power generated from carbon-emitting source, and Y kWh be power generated from carbon-free source. a1, a2, a3 and a4 are carbon emissions for each customer, calculated using carbon intensity for the carbon-emitting source, and b1, b2, b3 and b4 are carbon emissions calculated using carbon intensity for the carbon-free source. We want to prove that a1 + a2 + a3 + a4 = X kWh and b1 + b2 + b3 + b4 = Y kWh, and that a1 + a2 + a3 + a4 + b1 + b2 + b3 + b4 = X + Y kWh, without knowing any of the input numbers. This is only an illustration to explain the use case, in real life there could be over a million customers! Therefore a human auditor cannot practically solve this. However, a human auditor could play the role of verifier and make use of the ZKP system.

The ZKP for this scenario can be constructed based on the following:

The prototypes for these two use cases are a work in progress, currently I am testing out different techniques and frameworks that can achieve the same ZKPs but have different properties. Once I have completed the proof of concept on these two use cases, I could apply a similar technique on other commodities such as coffee beans. I will continue to share this research journey in the next blog(s)!

[1] Russian proverb “Trust but verify”, https://en.wikipedia.org/wiki/Trust,_but_verify
[2] S. P. Marsh. 1994. Formalizing Trust as a Computational Concept. Ph.D. Dissertation. University of Stirling.
[3] Volkswagen emissions scandal: https://www.epa.gov/vw/learn-about-volkswagen-violations
[4] Ikea logging protected forests: https://earth.org/ikea-implicated-in-logging-protected-siberian-forests/
[5] What is greenwashing: https://www.un.org/en/climatechange/science/climate-issues/greenwashing
[6] Causes of Climate Change, the United Nations, https://www.un.org/en/climatechange/science/causes-effects-climate-change
[7] The World Business Council for Sustainable Development, WBCSD https://www.wbcsd.org/
[8] Partnership for Carbon Transparency, PACT: https://www.carbon-transparency.org/
[9] Man, J., Jaffer, S., Ferris, P., Kleppmann, M. and Madhavapeddy, A., Emission Impossible: privacy-preserving carbon emissions claims.
[10] EU CSRD: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022L2464