Blockchain Registration part 1: Asset Validation

Applying Trust Pathways to Blockchain Registration

Our first series of posts on blockchain technology and trust concentrated on identifying trust pathways. These pathways are necessary conditions to create any contracting relationship that uses a decentralized ledger technology (DLT) such as blockchain as a foundation. The next step is to apply pathway identification to an actual implementation problem on blockchain: registration.

A public ownership registry is a publicly available record that associates an asset–perhaps a cryptocurrency, or a tangible asset ‘off-blockchain’ such as real estate–with an owner.¹ Implementation of blockchain or blockchain-assisted registries is already in the concept and prototype stages for a variety of assets,² and is already in production for Internet `.bit’ domain names³ and academic diplomas.⁴

Decomposing the Registration Process

A typical registration process must include the following steps (at the very least–more complicated registration processes, such as land registration for development, will have several sub-stages or other additional requirements):

Primal Authorities and Oracles

When this process/workflow is applied to blockchain registration, it turns out that an initial, trusted third party with primal authority over asset registration (such as a domain name registry,⁶ when the asset is an Internet domain name) may be necessary.

In and of itself this does not break down the decentralized trust pathways that need to exist in a blockchain registration process. For example, an authority may be needed to set up the initial registration data when migrating to blockchain registration from existing off-blockchain technologies. Say a Department of Motor Vehicles (or equivalent entity) decides to use blockchain technology to register ownership of automobiles. The Department will become the primal authority in order to transfer the initial data of existing owners to the blockchain.

After the initial data commitment, though, it will usually be necessary to update the blockchain with new information. These data are required to trigger contractual conditions, such as “pay out an insurance claim in the event of fire”, or to verify identity prior to registration by using a third party trusted source (such as a government agency). Such external sources of data are called ‘oracles’ in the blockchain literature.⁷

We’ll address how to preserve trust pathways with primal or external authorities (such as oracles) in a future post, and concentrate for now on delving into the details of the each of the registration steps above, and how they can be applied to the blockchain in a trustworthy manner.
 

Asset Validation: It’s Only There When You Look At It

It’s pretty obvious that in order to register an asset, it needs to exist in the first place! But how can a registry, such as a DLT like blockchain, independently validate the existence of something that is claimed to exist when it is being registered? Sometimes, asset existence and ownership identity verification take place at the same time–using the car registration example above, a DMV would itself warrant that the car being registered on the blockchain exists, when an owner submits their driver’s license as a method of ownership identification. In this case, asset existence and owner identification can be “bundled” into a single step, and can be treated as part of the ownership verification step, to be covered in a future post.

Registration Requires Proof

Assuming that asset existence is separate from owner identification means that existence needs to be independently confirmed, through e.g. 1) physical evidence of a tangible asset, like photographs, earlier registration documents, or public records, or 2) possession of an digital asset, like a cryptocurrency or a piece of software. If the asset is unique, like a rare coin or painting, some measure of trust needs to be present to determine that the asset isn’t counterfeit. This is also important if it’s a digital asset being registered, since in that case multiple copies could be generated (via copying or cracking).

All Assets Need Standards

There’s another source of uncertainty beyond just establishing the existence of some asset–it has to be that the asset is actually what it says it is! In other words, the asset has to meet a specification that restricts what can be registered. To continue the example above, if the asset to be registered is a car, it has to fall within the parameters as defined by an “automobile class” before the asset is accepted as valid. Again, this seems pretty obvious for our everyday experience of what a car is–we wouldn’t, for example, expect someone to register a bicycle as a car with the DMV.

But mistakes can (and do) occur, and so a standard is needed to make sure that such errors are minimized. Moreover, what we call a car today isn’t necessarily the be-all and end-all for what a car will be called tomorrow. How about flying cars? Self-driving cars? Standardization has to be specific enough to exclude assets that will never meet the criteria (bicycles appearing as cars) while being flexible enough to include future assets (flying cars).

Blockchain-Encoded Assets Can Be Validated

There’s not much blockchain can do about proving an asset exists off-blockchain–this will still need a source of trust, whether that source is provided by a third party’s photographs, public records, affirmation/warranty etc. But if the asset is itself encoded on the blockchain–such as a cryptocurrency like bitcoin, or a domain name address for domain registration–then blockchain prevents double-spending and counterfeiting by design. This is because the asset defines its existence as a transaction in a block (e.g. as ‘that which resides at a bitcoin address’). To validate its existence, just query the address.

Blockchain Solves the Standardization Problem

Blockchain technology is built to solve the standardization problem for asset registration. This is very easy for assets that are defined on-blockchain, such as bitcoin in the Bitcoin network. Here the standardization details, or class, is built into the structure of the exchange–defining a contract to transfer one bitcoin between parties leverages the definition of ‘that which resides at a bitcoin address’.

If the class isn’t built into the transaction definition then its specification will need to be encoded into the blockchain as a ‘specification contract’. This would be an immutable reference to the defining class, accessible by smart contracts wishing to register an asset of that class. For a tangible asset, such as a car, the defining characteristics of a car (e.g. a photograph, vehicle identification number, etc.) provided to show existence would also match the class specification, so that validation of both existence and specification could take place.

Specification: Decentralized or Centralized?

We can think of a specification contract as being created in one of two ways. First, a consensus between users could be achieved in the specification contract, perhaps by making the contract itself open-source and hence modifiable by anyone. This would preserve the validation and verification trust pathways (as explored in a previous post). In addition, the implementation of the specification contract would be decentralized and simply reside at an address in the blockchain.

A consensus set of standards works well when a new set of standards is being developed. But when an asset has an existing standard then a primal authority becomes necessary. For example, consider blockchain registration of a digital asset with a primal authority, such as a domain name. The domain name registry might be legally required to maintain the set of standards required for a domain name. The registry would then have the responsibility to draw up the specification contract, and would be the sole authority allowed to update the contract.

So even in this simple example, there is scope for a primal authority actively working within a blockchain registration environment, and the trust pathway needs to be extended to this standardization use case before blockchain can be effectively used to register assets (tangible or digital).
 

Moving Forward

In the following post we’ll continue looking at the blockchain registration steps, covering the ownership and impeachability of an asset.

Read more in the white paper: “Oracle Trust Design and Blockchain Registry Provision”

 

References

1. This is a ‘permissionless’ or open blockchain, in which anyone can perform registration. An alternative is a ‘permissioned’ or closed blockchain, in which participants are invited and trust is secured via whitelisting/blacklisting. Here we focus upon open blockchains, although many of the same trust issues remain important even in closed blockchains.
2. In Belgium, “Toelichting proof of concepts in Vlaanderen“, retrieved November 2017; in the U.K., “HM Land Registry signals the start of its transformation“, press release 18 July 2017; in Sweden, “Blockchain and Future House Purchases“, retrieved November 2017.
3. See e.g. Namecoin.com.
4. See “Digital Diploma debuts at MIT“, MIT News 17 October 2017.
5. The fee may be transferred to the blockchain transaction validators (e.g. ‘miners’ in the Bitcoin parlance, for open blockchains using Proof-of-Work), to a primal authority, to an oracle providing external data, or some combination of these.
6. The term registry is used both to generally describe a database where registrations are stored, and to describe the specific entity which acts as the top-level domain name (.com, .eu, etc.) manager when the context is domain name registration.
7. See for example Oraclize, which provides a single oracle interface, and ChainLink, which is a decentralized network of oracles.