We strongly believe that people should be in control of their data, sharing only what’s necessary and nothing more. That’s why we’re investing a lot of time in zero-knowledge proofs – something we believe will get us closer to that goal.
An interesting area to apply this technology to is the supply chain space. People increasingly want to know where their food comes from, if it has been grown in an eco-friendly way, and if it comes from countries they trust.
In this blog post I’ll look at how we built a zero-knowledge proof system and apply that to a real world example of coffee bean farming.
We set out to build a generic zero-knowledge proof of location system where:
a consumer can configure a list of authorized areas; and
a producer can prove that he is in one of the configured authorized areas without revealing where exactly.
The beauty of such a system is that it shares exactly what’s necessary, but nothing more. The location of the producer remains secret but the consumer knows that it satisfies his conditions.
Zero-knowledge proofs are a hot topic, and there is a lot of very good research that has been done over the last decade. Part of this research is focused on simplifying how we build ZKP circuits from “normal” code, bridging the gap between research and engineering.
For this project we forked the excellent Pequin project. Pequin allows us to write code in a subset of the C language and compile that to a ZKP circuit. Don’t hesitate to have a look at the commits if you’re interested in the technical details.
Once we had a ZKP circuit that allowed us to generate and verify proofs of location, we created an Indigo Agent that leveraged it.
Our agent uses proofs of location to trace coffee bean farming. The producers are coffee bean farmers who can be anywhere in the world. The consumers are merchants that buy coffee beans from farmers and sell them to the end customers.
To simplify the demo, instead of using real GPS coordinates for the locations we simply use (x,y) coordinates in a 2-dimensional plane.
Let’s see it in action. Imagine we have a merchant named Cafés Bastien that wants to buy coffee from farmers from three different areas. The merchant adds the three authorized areas in the Indigo Agent.
Indigo Agent UI: notice the three areas in the state
Cafés Bastien publicly provides a prover kit (for our demo it’s simply a docker image) that any farmer can use.
Let’s imagine that the second area (x=3, y=7, radius=4) represents a region in Guatemala. Alice is a farmer in that region, located at coordinates (5, 10).
Alice uses the prover kit to generate a proof of location with her GPS coordinates and submits it to the Indigo Agent with her delivery of coffee beans. The Indigo Agent accepts the delivery because the proof is valid.
Indigo Agent UI: notice the hex-encoded proof field.
Mallory is a farmer from a country where environmental protection is poor and unethical practices are common. Cafés Bastien wants to reject such deliveries. When Mallory produces a proof of location from her coordinates that are outside of the authorized areas, the Indigo Agent will reject it.
Indigo Agent UI: an error is returned for invalid proofs.
We encourage you to play with them and send us some feedback!
Zero-knowledge proofs are a very strong cryptographic tool. The maths behind them are powerful and complex, and there are many intelligent people putting a lot of effort into making it secure. But still, we should ask ourselves: how secure is this proof of location?
It’s currently as secure as a next-generation highly secure vault, but we’ve forgotten to close the front door. Once we have the farmer’s GPS coordinates we build a highly secure proof from it, but nothing prevents the farmer from using fake GPS coordinates.
We need a secure hardware module that would provide us with GPS coordinates that can’t be tampered with. It would be a start, but nothing would prevent farmers from taking this hardware device to an authorized area (different from their farming area) just to produce the proof.
We need to couple such a device with other signals from various sources. The following list provides some ideas on what such sources could be.
A time-stamping authority.
Weather data from a sensor, which could be cross-checked with trusted weather services.
An accelerometer with regular checkpoints.
Any kind of real-world data that makes sense for a specific use-case.
The trust that you have in a system increases as the number of distinct proof sources you have access to increases. We believe that a secure system shouldn’t be built around a single proof but rather rely on as many proof sources as necessary to be convinced beyond reasonable doubt.
This is why we built Trace, a traceability service that can be used to store all the important signals that a process generates, from which you can create strong, trustworthy proofs beyond reasonable doubt.