Blockchain can indeed fight counterfeits, #EUBlockathon2018
The European Union Intellectual Property Office convened an hackaton, EUBlockathon, which brought together international coding teams in the first ever anti-counterfeiting hack. The scope was to unlock the potential of blockchain and co-create an integrated solution to combat fake goods.
In Europe each year about 5% of goods are not genuine and their negative impact on the economy is in the hundred of billions.
To tackle this issue the EUIPO organized one of the biggest hackatons I’ve seen. The location was the beautiful Autoworld museum in Brussels and selected teams lived there an entire weekend to first learn from experts and then deliver a solution with prototype.
The key concept is that fakes are created because there is a market for them. Noone would create en masse something that cannot be sold (a part from startups, sometimes). So there are basicaly two ways to go after this:
- you can make cloning an object more difficult therefore economically more expensive, e.g. add a chip;
- you can try to incentivize/deincentivize the involved parties.
Both ways are reasonable depending on the goods, in our team, CryptoMice, we decided to go for the second option to better leverage our knowledge in protocols and game theory.
Every object will have a virtual twin, a copy of it saved in the blockchain. This copy will have the same serial number (taken from GS1) of the real object. The amazing property of the blockchain is that it is immutable and you can prove mathematically that something is unique, so even if it is possible to clone an object in the real world, it is impossible to clone the blockchain twin. To be precise, cloning an object on the blockchain is as hard as breaking discrete logarithm, if you can accomplish that, you probably have better things to do than sell fake watches.
The base protocol that we propose is as follows: you don’t accept a physical object from me if I can’t send to you also the virtual one. Say everyone adopts this protocol, then there is no more economic incentive to steal or make fake goods. When I steal some goods in this ideal world, I can’t find buyers. This is very nice because it resambles a Nash equilibrium, i.e. single-side deviation resistant.
In the real world we cannot be so naive, so we have introduced the concept of “chain of holdership” (hodlership for crypto aficionados out there), every time the virtual twin changes holder the past holders are recorded on the blockchain. When someone, say “Trucking company A”, steals the real good, the next person in the chain presses a warning button which makes that line of holders red. “Trucking company A” steals again for other goods and in time you will see a lot of red lines crossing over “Trucking company A”. Pushing the alert button means that the virtual twin has arrived, but the physical good is wrong or missing. The number of red lines crossing over an entity is a warning indicator that can be used by customs and logistics operators. In particular you can take decisions about a cargo “before” the cargo arrives by checking the chain of holders and requiring that the current owner can transfer to you the virtual twin. The incentive for someone to push the alert button is that, if he doesn’t, someone down the line will push it and red lines will being to pass also over him.
In a way we are using the virtual world as a prediction of the real one, so if something goes wrong there, there are good chances something is wrong also in the real world.
It was paramount to us to:
- have a plan pointing at a stable and desired scenario in the long run
- don’t tie the protocol to a technology because what is difficult today can be easy tomorrow
The point was: say that the protocol succeeds, are we creating a stable equilibrium? Yes, we can also describe from a mathematical point of view which kind equilibria it’s going to be. Moreover we wanted to rely on authorities and business entities to enforce the disincentives, giving KPI and tools to make decisions without tying them to a technology. This point is strange to grasp but it was an hackaton organized by the European Union, whose horizon of investment is in the decades (centuries?) so having a fast solution today may or may not be the right answer, whereas proving that we are envisioning a system which is incentive compatible is for sure mandatory.
The above base protocol can be extended for logistics, the idea is that you can expand form virtual object to virtual shipment. As of today the shipment ids are unrelated from the ids of the obejcts inside. So today it’s important (a.k.a. it’s a pain) to share DB data in different formats between parties, so that everyone knows what’s delcared inside a shipment.
As a protocol this problem is solved in a different way, all parties agree on a function that computes the shipment id from the ids of the objects inside. In this way there is no need to share DB data but anyone knowing the protocol can check directly on the shipment. Basically you can see a shipment as multi-sig wallet: to have holdership of the shipment you need to have holdership of each key of the objects inside of the shipment. Once again this is an ideal world solution because in the real world not everyone will adopt the protocol from day 1, so we have prepared a version which is more adequate for actual implementation.
We assume the objects will have the GS1 SGTIN serial numbers and we compute a Perdersen commitment of each of the serial numbers inside the shipment. In this scenario the commitment is a number computed with the serial number and a private number K. Everyone can read the commitment but only people knowing K can see what is the initial secret number.
The simplest commitment is in this form: c = g^x h^K, where x is the serial number to hide and K is a private number shared only between trusted parties (g and h chosen properly.. long story here).
The shipment id will be the concatenation of all the object ids inside, plus a list of commitments: the number of objects without serial id, the weight, expected carriers, other useful data and all the of known object ids. The point is that these numbers will be hidden in commitments that only parties with K can read.
If you don’t trust a particular logistic operators you don’t share K with them. If they want to inject objects into the shipment they should also add numbers to the shipment id but they can’t do it without knowing K. They can check that the shipment id is matching the ids of the objects inside, but they can’t change the shipment id. Commitments work because when you don’t know K there are infinte (x’,K’) points that satisfy the equation which computes c. It’s impossible to even guess x, your probability of being right is 1/infinity (alright, since we use computers one could say 1/2²⁵⁶ but still..).
Finally a computed shipment id is useful because it allows to sample check the shipment. You can sample some of the goods inside, get their ids and see if they match with the shipment id. The objective is to give tools to do better inspections because there are way too many containers to be analysed. We want to create fast sanity-checks that can be done everywhere and that spot the anomaly. When an anomaly is found then the whole shipment is checked.
It’s no hackaton without a prototype!
We used Ethereum ERC721 for a quick implementation of a unique token, because it already has functions to prove ownership of a token before transferring it, in fact the approve function of the smart contract allows the owner of a token to approve the transfer of the token to another address. We extended ERC721 with the concept of shipment, or “lot of objects”, and with the concept of past owners. The basic ERC721 stores the current state of token owners but not the past (to get the past you should start synching a node from zero and re-play the transactions, which looks unpractical).
On top of the smart contract we created a set of Node.js micro services, each one calling a single function of the smart contract. On top of this we developed an interface to see the creation of virtual twins, the aggregation into lots (a.k.a. shipments) and the approval and transfer of ownerhip of tokens.
The interesting part is that as a protocol we also want to be blockchain agnostic, the basic functions can also be obtained in Bitcoin! Every token is a transaction id, so when I have a token in my bitcoin wallet it means that I have an input I can spend which originated from the official wallet of the brand. In Bitcoin this protocol has to be enforced, it’s important that I spend that input transaction only when I am passing the token to the next owner. If that transaction input is split or spent anywhere else the virtual twin is destroyed. Nonetheless in Bitcoin the chain of holdership will be easier to check because you just need to parse the blockchain and follow the transactions upstream.
The hodlership protocol was initially thought for luxury brands because their consumers want to be really sure they’re buying a real object and can be willing to go a step further to assess the origin. Our first goal for the summer is to have a couple of meetings and validate feedbacks/willingness to begin a project with some fashion brands here in Milan.
Moreover we would like to follow up a discussion with GS1 because there is a lot of synergy with existing standards and it makes a lot of sense to try and find a common house for the hodlership protocol.
As a protocol it is vital to be open source, we are planning on releasing it on Github/Reddit and start to share our initial reference implementation.
First of all to CryptoMice team members!
- Fabian Niederkofler UX veteran, ex-waynaut co founder, we’ve already seen some, we’ll see some more.
- Luca Vaccaro hard core hacker, all night worker, thanks again for getting hard stuff done.
- Valerio Vaccaro, open source expert with a deep IoT understanding, our anchor into the physical world.
Thanks to every the teams that took part, most of the proposed solutions were definitely meaningful and we are looking forward to understand how to integrate them within the hodlership protocol.
Special mention to all the mentors, in particular to the ones spending a lot of time with us and being the first open source contributors!