The potential of zero-knowledge proofs for private & decentralized energy markets
Over the last several years, we at Blocklab have worked on numerous Proof of Concepts (PoCs) for decentralized energy markets. Iterative development has taken us from a small, community-oriented, open energy database — the OEHU project — to an elaborate R&D collaboration with S&P Global Platts, centered around a decentralized, agent-operated smart grid¹. We are now at the stage where we are building functional, autonomous smart grids utilizing blockchain technology.
The next technology to be incorporated into our development arsenal is one based on proof systems and zero-knowledge, implementations of which are collected under the umbrella of ‘Zero-Knowledge Proofs’: zk-SNARKS (Zero-Knowledge Succinct Non-Interactive ARguments of Knowledge) and zk-STARKS (Zero-Knowledge Scalable Transparent ARguments of Knowledge). They are being utilized by various projects in the blockchain space such as Gnosis, AZTEC Protocol, and EY. All of these projects — although operating at different layers of the technology stack and providing different solutions — share one common use case: privacy preservation.
One thing before we dive in: the previously referenced projects utilize the Ethereum blockchain. Since Ethereum is currently the most commonly used blockchain solution, as well as the blockchain of choice for us at Blocklab, all references to implementations of zero-knowledge proof systems herein — unless otherwise stated — pertain to projects on Ethereum².
So what is a zero-knowledge proof? In short, it is exactly what it says it is: a cryptographic proof of something: instead having to provide evidence that a statement is true (e.g. ‘I am who I say I am, and here’s my passport to prove it’) all you share is the proof that this statement is true (i.e. ‘I am who I say I am, and here’s the proof of it’), which is generated by the zero-knowledge proof system itself. In other words, “Zero Knowledge Proofs enable a way to share validated data with a third party without actually sharing the data itself.”³
Zero-knowledge proof systems are recognised — even amongst cryptographers — as being a form of black magic. However, the high level mechanical explanation is at least conceptually quite simple, and goes something like this. Proof systems allow for the creation of a “cryptographic “auditor” to certify that a mathematical function like a search query over a database was indeed computed”⁴. In other words, they assess that a certain computation was carried out as requested, in an interaction between a Prover and a Verifier about the truth or falsity of some statement. There are two properties that any properly constructed proof system must have:
- Completeness: if the statement is true, and the verifier and prover are honest, the proof is accepted.
- Soundness: if the statement is false, a cheating prover cannot convince an honest verifier that it is true, except with some tiny probability.⁵
The ‘zero-knowledge’ aspect is simply a property of a proof system that allows this computation (and all the data that needs to be computed over) to remain private; the Verifier learns nothing about the data that the Prover used to construct the cryptographic proof they are using to verify (e.g.) their identity to the Verifier. These systems are therefore obviously of interest to privacy-conscious groups working with digital identity systems, database set queries, online transactions, and distributed computing.
zk-SNARKS and ZK-STARKS are instances of zero-knowledge proofs. zk-SNARKS are a particular form of zero-knowledge proof that — as the name suggests — are non-interactive. What this means that there is only one piece of data — the proof — that travels to the Verifier from the Prover, and no other sensitive information is shared between them. As well as the ‘zero-knowledge’ property (that if the statement is true, this is all that the Verifier learns from the proof), there are four further properties that zk-SNARKS need to have:
- Succinct: The size of the proof needs to be small enough to be verified in a few milliseconds.
- Non-Interactive: Only one set of information is sent to the verifier for verification, therefore there is no back and forth communication between the prover and verifier.
- ARgument: A computationally sound proof: soundness holds against a prover that leverages polynomial-time, i.e. bounded computation.
- of Knowledge: The proof cannot be constructed without access to the witness (the private input needed to prove the statement).⁶
So — finally — what does a blockchain-based solution that uses a zk-SNARK look like? A properly implemented identity solution involving the use of zk-SNARKS for identity attestation at a bank would go something like this:
One thing to note with this is the actual construction of the proof itself: this must be created by plugging Alice’s information into something that is presumed to be trusted. Whilst this is an obvious potential security flaw, this single-point of interaction between a third party and an individual’s data is far preferential to constantly repeating this information (and thus having copies being created) every time the validity of this information needs to be proven.⁷
A brief note before we continue: blockchain-based zk-STARKS are far less developed, and as of yet there are no projects on Ethereum that utilize them. As such, discussion of zk-STARKS will be kept brief. Primarily, they do not share the disadvantage of zk-SNARKS in that they rely on what is known as a ‘trusted setup’ — a ceremony where certain setup parameters rely on a source of randomness that serves as a potential single point of failure — , they scale far better than zk-SNARKS, and are also quantum resistant.⁸
How then does this affect our work at Blocklab? As previously stated, we are moving beyond the PoC benchmark this year, and are now working on projects for public use: building agent-based applications that will ‘live’ in people’s houses, track their energy use, and make use of a decentralized smart grid to trade and store energy among the other houses on the grid. So why is it so important that we utilize privacy-preserving technology for a smart energy grid?
The short answer is in the name: privacy. It is important for any technology that deals with personal information should have privacy baked-in by default, yet most blockchains — by design — are transparent in nature. The longer answer is, as always, more interesting. All of the previous projects were focused on utilizing the transparent nature of the Ethereum blockchain in order to create PoCs proving that a decentralized database solution was viable. However, we’re now scaling up, and have other design considerations to attend to. As we’re now deploying and testing with fleshed-out user-proxies, we’re in the position of not wanting all of the data moving around the different layers of these applications to be transparent.
Most immediately, we’re talking about transactions that could allow a malicious party to gain information about peoples’ energy usage, or transactions that directly relate to the amount of energy people are using, and their ethereum address (potentially deanonymizing an admittedly only pseudonymous system). Whilst this might seem innocuous, from an Information Security (InfoSec) perspective, a lot can be gleaned from this information. If one is able to see patterns in energy data, one might be able to make inferences that a house is left empty between times X and Y on weekdays, or that the occupants may be on holiday. This is obviously a security concern.
This is where the zk-SNARKS come in: we’re able to make everything private that we need to make private, and create a decentralized energy marketplace with self-sovereign identity and data management baked in. Users retain total ownership of their data (remember — only proofs of there (e.g.) being 10k in a bank account or having used X amount of energy this month are shared) and therefore avoid any possibility of personal data leaking.
What does this look like then, compared to an application built ‘as is’ atop the Ethereum network? Obviously the architecture will be different depending on what framework is being used, but on a general level, instead of transparent public logs of transactions (i.e. ‘what has happened’ according to the network consensus mechanism), we have public logs of verified computation which we trust to be true due to the cryptographic proof system that is being used. This additional security to the system is very lean with regards to the amount of data being used for proof attestation: it is merely a single byte in size.
To conclude, implementations of zero-knowledge proof systems such as zk-SNARKS hold an immense amount of potential for future Blocklab projects, with our decentralized energy grid first in line for the upgrade. Whilst this is still very much in the planning and research phase, the potential is truly exciting.
¹ This project is currently being field tested — stay tuned for updates.
² This is not to say that those projects not discussed here are in any way inferior; each zero-knowledge system has its merits, and given the complexity of these proof systems each implementation must be tailored to the Blockchain protocol that it uses. For non-Ethereum implementations of zero-knowledge proofs see this great open-source repository for information on projects such as Monero’s Bulletproofs, ZCash, and Grin.
⁴ https://medium.com/magicofc/interactive-proofs-and-zero-knowledge-b32f6c8d66c3
⁵ https://medium.com/coinmonks/zk-snarks-a-realistic-zero-knowledge-example-and-deep-dive-c5e6eaa7131c
⁶ ibid
⁷ https://medium.com/coinmonks/zk-snarks-a-realistic-zero-knowledge-example-and-deep-dive-c5e6eaa7131c
⁸ See Ben-Sasson, Bentov, Horesh, and Riabzev, Scalable, transparent, and post-quantum secure computational integrity (2018), https://eprint.iacr.org/2018/046.pdf
