Blockchain Registration part 3: Processing

Applying Trust Pathways to Blockchain Registration

Season’s Greetings! The second post in this series discussed how blockchain asset registration requires as part of its workflow an understanding of the trust issues related to asset ownership on the one hand, and an asset’s ability to be registered (its impeachability) on the other. These two components of an asset are part of the four steps that any registration workflow needs to follow:

In this post we’ll cover the last step, the act of registration itself. This is where blockchain technology really shines, and is usually the starting point for other discussions on the advantages that blockchain brings to the table. Blockchain provides transparency and immutability, which allows (once this step has been reached) every party to confirm a registration has occurred, and to audit the pathway that led up to an asset being registered.

Primal Authority Registration Redux (say that three times fast!)

One common thread throughout this workflow has been the need for one or more primal authorities, such as a registrar, to help standardize the registration process and to provide the initial registration data. On the blockchain, this role can in fact be strengthened from a trust point of view by virtue of the use of cryptography to verify identity. The registrar can, for example, encrypt registration data with their public key and send the data to an address owned by the registrant, once the previous steps (validation, ownership and (un)impeachability of the asset) have been affirmed (either by the registrant itself, or via an oracle).

The encryption protects the registrant (where such is required by e.g. data protection laws, such as the European Union’s General Data Protection Regulation (GDPR) and Payment Services Directive 2 (PSD2), and the US-EU Privacy Shield) and provides the operational implementation of the initial registration of the asset. With a standardized registration data format, a hash¹ can be generated to quickly verify that registration information is correct.

Finally, the registration payment system can, if desired, also be moved to the blockchain. A registration fee can be trivially collected by charging a native token or `colored coin’ transaction fee² for the initial registration, while further updates of e.g. registrant information may be free.

Decentralized Maintenance

Updating registration details, such as from a change in ownership profile information, or a change in the owner of the asset, takes place with further transactions inserted into the blockchain. The great advantage here is that this updating does not need to be performed by the primal authority! An asset owner also has `signing privileges’ on the blockchain, in the sense that they can update their asset registration information via a cryptographic hash. Suppose a registrant wishes to update their business address associated with a registered domain name.

The Good(?) Old Days

Pre-blockchain, the registrar would be contacted with the updated information, and an identity check would be performed to ensure that the update is valid (this would usually happen with a form that is signed by the registrant and returned to the registrar, or by a valid user updating online information directly with the registrar’s database via an online portal/web page). The update would be added to the central registration database and a confirmation sent to the registrant. The registrant would be able to confirm the registration only by contacting the registrar directly (as with a Department of Motor Vehicles) or perhaps by querying a public database, if one is available (such as the “Whois” database of domain names, for domain name registration).

Mr. SmartyContract

By contrast, with a blockchain using a smart contract, the registrant first uploads their new information to the blockchain. For example, the registrant could use first use their private key to encrypt their updated registration information, and then use a registrar/registry public key as a second encryption. This doubly-encrypted information is then sent directly to the blockchain address of the existing registration, as a transaction.

Upon receiving this information, the smart contract at that address would trigger, and

1. first, decrypt the information using the private key of the registrar, and then
2. decrypt the updated information using the public key of the registrant.

This “two-step” makes sure that only the registrar has the right to see the updated information (since the registrar’s private key is needed for decryption in the first place), while at the same time ensuring that only the legal registrant is allowed to provide information updates (since only the registrant’s public key can be used to decrypt the information, after it’s been decrypted by the registrar using their private key). After both steps have been performed successfully, the data payload is then used to update the information at the transaction address (or at the ‘final’ address referencing the actual registration details of the asset). If the registration data is to be kept confidential, such as health records, the registrar can again encrypt the data before it is placed on the blockchain–perhaps also allowing the registrant to have access via their own private key, using a ‘multi-signature’ hash.

Consensus Confirmation

When a transaction has been sent to the blockchain, it needs to be incorporated into a block that is actually written into blockchain’s ledger. The way this is done depends upon the kind of blockchain–for example, “open” blockchains such as Bitcoin and Ethereum rely upon a majority of participating network nodes agreeing that the block is valid (known as consensus). This agreement is built upon 1) accepting that the block has a valid format, conforming to the blockchain’s standards, and 2) accepting proposed valid blocks in a consistent fashion, without fearing that one or more nodes are manipulating transactions to their own benefit (or more benignly, without fearing data have been corrupted in transit). For “closed” blockchains, often special “validator” nodes exist whose job is to confirm blocks, or even individual transactions (which can significantly increase the transactions-processing speed of the network).³

Regardless of the consensus mechanism, once the transaction has been verified by the network in consensus, the new information is now available and is written into every copy of the blockchain ledger, providing an unprecedented level of data replication (and hence protection). A registrar or other primal authority can perform a check of the data by using their private key to decrypt the data payload the registrant has transferred, as mentioned above, but there is no need for the potentially costly step of owner verification because the smart contract located at the registration address has already ensured only they are allowed access.

External Trust

As always, though, there is scope for further verification of trust, if a registration standard or legal standard requires it. For example, if a registrant wishes to update their registration address, it may be required by law that the registry verify the address information. In this case some appeal to an external authority will be required–in other words, an oracle will need to be consulted with the question “Is this the individual’s current address?”, which would (similar to identity verification) reply with “Yes” or “No”. Depending upon the sensitivity of information being updated, then, the re-verification of information will always require consultation with an oracle to provide the required external data. We’ll delve into the trust issues specific to oracles, and how to use Game Theory to ensure that oracles are themselves part of the trust pathway, in a future post.

Moving Forward: Centralization Is Not All Bad

Blockchain’s use as a DLT is predicated on the assumption that the data which is placed on the blockchain is actually “true”, in that the data is what it is claimed to be. This cannot come from the blockchain’s underlying technology, although trust issues such as transparency and auditing are facilitated through blockchain’s provision of a public, immutable record. In spite of this, however, it is possible to secure trust pathways for data used in a registration process, by walking hand-in-hand with a primal authority or oracle to facilitate the level of trust required. At the end of the day, all parties benefit from avoiding the “garbage in, garbage out” problem of a fully decentralized, voluntary registration system, without compromising the principles that drive DLT adoption in the first place. Efficiency, rather than “anything goes”, becomes the standard-bearer for trustful service provision using blockchain technology.

Next year (!) we’ll look more closely at oracles and how they can be brought into the trust pathway paradigm, and also examine some of the game-theoretic foundations for smart contracts as they appear on the blockchain.

You can find part one and part two of this series on this site, and can read more about trust pathways, oracle trust and registration in the associated white paper: “Enabling Trust on the Blockchain”

 

Notes & References

1. A cryptographic hash is a fixed-length identifier of symbols representing an encrypted piece of text, that changes if any part of the text is changed. A hash `signature’ stored on the blockchain uniquely identifies the text that created it.
2. A native token is a cryptocurrency built into the underlying technology of the blockchain, such as bitcoin for the Bitcoin network and ether for Ethereum, while a colored coin is a derivative currency on the blockchain, using metadata to distinguish it from the native token (if one exists).
3. For a good overview of the differences between open and closed blockchains, focusing upon Ethereum, Hyperledger and R3/Corda, see Martin Valenta and Philipp Sandner, “Comparison of Ethereum, Hyperledger Fabric and Corda“, Medium.com 25 June 2017, accessed December 2017.