Introducing POPR: A Rare-Object Registry on Ethereum

Special thanks to Nick Johnson of the Ethereum Foundation for early guidance and feedback.

Introduction

This post introduces an object provenance registry called POPR (Public Object Provenance Registry), on the Ethereum blockchain, as an extension of ENS (Ethereum Name Service). We will delve into how this system can be used to identify and certify rare items in the case of theft.

“Provenance” is defined as the ownership and transfer history of any valued object. In the past, the word has been associated with the art trade, where there has always been a need to distinguish between originals and copies, but now has broader applications tracking consumer products in industries as diverse as energy, physical property, food and precious metals.

As long as there is some generally agreed upon standard for identifying the object in question, then matters of ownership, certification and transfer can be handled cryptographically by the blockchain.

 

Architecture

ENS is a naming registry which is quickly becoming a core service provided by the Ethereum network, but is still in testing. Only “.eth” is available so far as a top level domain so as not to clash with the existing DNS. But given its interoperability with other smart contracts, it is already being used for a wide variety of use cases.

POPR organizes object certificates into “collections”, giving each object a handy URI of the form:

popr://museum.eth/shelf/object

This address is parsed into two separate components: the ENS node of the resolver (‘museum.eth’), and the POPR address (‘/root/shelf/object’), which is hashed using an algorithm called pathhash. Pathhash is an inversion of the ENS namehash algorithm designed for a path style domains organized from left to right, and is available as a Node.js module. Check it out.

The root directory of each POPR collection is identified by hashing the protocol identifier with the owner’s ENS node. For example:

var root = sha3(‘popr://’, namehash(‘museum.eth’)) // 0x123

It should be mentioned that the owner of the ENS domain automatically has cryptographic control over their collection unless this is deliberately transferred, to curators for example.

Once this root directory hash is produced, the pathhash can be derived in the following way:

pathhash(0, ‘root/shelf/object’, ‘/’);

Collections are unlimited in depth. One could have a collection with just a few objects and no directories:

popr://museum.eth/object

Or several:

popr://museum.eth/building/wing/collection/shelf/object

Just like a file system, any step along the way could contain either objects or directories.

Object ID

Different industries need to define their own yardstick for identity. Metrics to certify museum pieces will not be the same as, for example, the supply chain of coffee beans or natural gas. For demonstration purposes we will use the Object ID standard initiated by the J. Paul Getty Trust and launched in 1997. Object ID is nice because it’s already used widely- organizations like Interpol, UNESCO, and several museums, art trade organizations and insurance companies use it to identify objects in the case of theft. What is missing, and why something like POPR is needed, is a way to securely store and easily access these certificates by anyone, from anywhere.

The Object ID standard defines a checklist of parameters for certificates:

  • Type of object
  • Materials and techniques
  • Measurements
  • Distinguishing Features
  • Title
  • Subject
  • Date or Period
  • Maker

In addition to these, the object must be thoroughly photographed in as much detail as possible and any identifying features be recorded also.

This document (‘watermark’) will then be stored on IPFS, which is a distributed file system where files can’t be deleted (although may become inaccessible sometimes if not hosted properly). The address of this watermark document contains all the “Object ID” information which is then linked permanently to the POPR certificate on the blockchain.

POPR Certificates

Because computation on Ethereum is very expensive, we want to minimize the information that ends up being stored in the contract itself. Therefore each object certificate contains only three pieces of information: the address of the owner and two IPFS links. Like so:

struct certificate {
address owner;
bytes watermark;
bytes metadata;
}
mapping(bytes32 => certificate) registry;

The “watermark” document is linked at the point of creation and is completely immutable as long as the object exists in the registry. The other document, “metadata”, can be changed at any point and can contain more transient information like contact details the owner and various pieces of information of public interest.

Similar to ENS, there is one single “registry” mapping containing all the objects stored on POPR, linked by the object’s particular pathhash referred to earlier. 

Here is an example of a “watermark” document we made in the EY Experience Lab for our own Coffee Machine:

{
"watermark" : {
"type" : "Office Utility",
"popr_id": "popr://eyexperiencelab.eth/coffeth",
"title": "Coffeth",
"materials" : "plastic",
"pictures" : "ipfs.io/ipfs/QmdkLzDmLVp9XxrVXdu5WoKmVv7yFDeKE2ihJd3bXB7ZhW",
"model" : "Philip's HD8827",
"subject" : "Coffee, Ethereum",
"date" : "26/06/2017",
"receipt" : "0xabcxyz",
"identifiers": "0xabcxyz",
"description": "A hot beverage maker which is can take Ether and erc20 tokens as payment.",
“qr_code”: “0xabcxyz”
}
}

This file is then uploaded to IPFS via ipfs add watermark.json. The resulting address will then be inserted into the certificate by the owner using the certify() method in the registry contract.

The Contracts

Once we have decided what standard of identification we’re going to use (it can be any, since all that is dealt with off-chain), we will implement the contracts. Here is the central object registry, POPR.sol and POPRRoot.sol which is the base registrar where users can create collections, based on the first-in first-served model (FIFS) although this may change to something more appropriate in time.

The full process of creating a collection and certifying an object goes like this:

    1. Get an ENS domain. (More info)
    2. Use ENS namehash to initialize a collection in POPRRoot.sol by callingcreateCollection(ensnamehash).
    3. This creates a new empty “certificate” resulting location, which can be found, to reiterate, by using var root = sha3(‘popr://’, namehash(‘eyexperiencelab.eth’)).
    4. Create a new certificate in POPR.sol for Coffeth, making sure to use the same address that owns the original ENS node: mkdir(‘coffeth’, root, web3.eth.accounts[0]);
    5. Once again in POPR.sol, register the IPFS watermark with the pathhash of the directory created in step 4 and the IPFS link:certify(pathhash, ipfs_doc);
    6. Voila! At this stage you can set the metadata using setmetadata or transfer ownership using setowner. The watermark can no longer be changed.

 

Auditing & Provenance

On Ethereum there is a big difference between reads and writes. Writes (transactions) change the overall state of the network and cost gas. Reads on the other hand are free and instant via constant functions. If you have the POPR address of the object in question, you can retrieve the watermark, owner and metadata from POPR.sol using getowner(), getmetadata(), and getwatermark() supplying the pathhash as a parameter.

Every time an object changes ownership an event Transfer() is emitted by the registry. The Updated() event is emitted whenever the metadata is changed. All events are easily searchable, meaning it is possible to get back the history of every change of state, including changes in metadata (and if using IPFS, the old documents will still exist). This means it will be possible to trace back the full history of any object in the directory.

Development

Currently POPR needs to be tested so aspects of the current contracts will probably change. But I would like to create a full API to handle uploading and hosting IPFS docs, lookups, and interacting with ENS and POPR at the same time, as well as a front-end directory for the public. The range of tools for POPR is fairly extensive, possibly including plugins for organizations who want to display their POPR collection on their website.  If you are an organization interested in exploring the potential of POPR get in touch!

by Philip Saunders