The United Nations Commission on International Trade Law (UNICITRAL) have published a paper in 2017 on the Model Law on Electronic Transferable Records (MLETR) to enable legal use of electronic transferable records domestically and across borders.
The paper was significant in outlining how we can represent and accommodate instruments like title deeds, bills of lading, bills of exchange, promissory notes and warehouse receipts
Accordingly, such Electronic Transferable Records (ETRs) must fulfills the following criteria:
In this paper I outline how we can built an application leveraging on consensus mechanisms of blockchain to fulfill said requirements.
Implementing ETRs on the blockchain will require multiple key components to work together to meet the requirements set out by MLETR. The application can be broken down into 4 major components with the following roles:
In this paper, we discuss the roles, responsibilities, requirements and implementation brief of the major components starting with the blockchain layer.
A blockchain is an open, distributed ledger that records transactions between parties, in a verifiable and permanent manner. In all blockchain implementations, participants work together to validate and append new records according to the rules defined in the open-sourced blockchain software and the shared historical records.
Essentially this forms a global finite state machine where the current state on the blockchain can be derived from the entire history of state changing events and the content of the genesis block itself. The consensus mechanisms written in different blockchain client softwares ensure that it is hard for malicious actors to convince honest actors to rewrite historical transactions to change the current blockchain state. For that reason, transactions on blockchains are thought of as immutable.
There are two main types of blockchains, public and private blockchains.
Public blockchains like Bitcoin and Ethereum are networks where anyone can participate in reading the current state, writing a state transitioning transaction, or participate in the consensus mechanism by proposing and validating new blocks.
Private blockchains like Hyperledger Fabric or Quorum, on the other hand, have access control settings that restrict the type of actions different actors may perform on the blockchain.
Since blockchains are capable of providing immutable records of transactions and the current state, they can be used to provide a rail for keeping records for Electronic Transferable Records (ETRs). However, there are several considerations for selecting an usable blockchain.
Support for Smart Contract — The blockchain should be programmable to allow actors to define a valid set of state transitioning transactions and their pre-conditions. An example of such action is a transfer action where an entity may transfer its ownership of an ETR from itself to another entity if and only if the following conditions are met:
Programmable blockchain allows for users to define custom logic for state transitions using scripts known as smart contracts. Once a smart contract has been deployed, the contract code will never be changed and all participants on the network will be able to verify the code of the contract before interacting with it.
These smart contracts allow different entities to interact with it by sending state transiting transactions to modify and store application states through its functions. All the clients connected will be able to execute a set of ordered state changing transactions deterministically, and arrive at the same subsequent state, an important attribute to ensure that all the clients in the world agree on a single state related to ETRs.
ETR issuers, such as shipping lines, would be able to deploy smart contracts to maintain a single global record for the following purposes:
To promote interoperability between different solution providers and implementations of ETR softwares, a standard API should be defined for ETR transactions to allow ETR holders and recipients to transfer and receive ETRs as well as anyone to query the status of an ETR.
The Ethereum Improvement Proposal, ERC-721 provides a widely-used smart contract API used for non-fungible token (NFTs) or deeds. The interface is widely used by smart contracts on the Ethereum blockchain to represent digital assets from digital cats, to digital art pieces and even title deeds of virtual world. Other than being used for representing assets on the blockchain, the API also enables other entities to build applications such as marketplaces to allow participants to buy, sell and auction these tokens.
Aside from the API specifications, there are concrete implementations of the smart contracts, such as OpenZepplin, which are widely used and have been audited. This allows ETR issuers to deploy these audited smart contracts or extend them with custom logic should they require additional functions in the smart contract for ETR record keeping.
One can extend the API specified in the ERC-721 proposal to implement the ETR smart contract for tracking the status of the various ETRs issued by an ETR issuer.
In the non-fungible token standard, every unique asset is represented by a unique identifier, and stored in a data structure that maps the unique asset id to an owner value which is an Ethereum address.
One can imagine the data structure as a gigantic table with 2256 rows, with all values set to the 0 value.
To issue an ETR, the ETR issuer may call the mint function to issue an ETR with its unique identifier as the tokenId to an entity who owns a given wallet address. This action will assign the wallet address to replace the 0 value for the owner value on the corresponding row.
For instance, the ETR issuer may issue ETR 0xaaa…aaa to an entity in control of the wallet 0x111…111, which will result in a change in state to the figure above. At this point, anyone with the ETR document ID 0xaaa…aaa may query the smart contract for the owner of the ETR and be presented by the current owner of the ETR who is 0x111…111.
To transfer an ETR, the current ETR owner may call the transfer function to change the current value of the owner to the ETR receiver’s wallet address. This will replace the owner value of the ETR with the new value and anyone who queries the smart contract for the owner will now receive the new owner of the ETR.
Physical transferable records such as bill of ladings are documents with lots of data and with document schemas that varies from one issuer to another. As a result there is a need for a framework to not only digitize the document but also allow it to be safely represented on the blockchain with a single unique document ID.
Some of the considerations for the selection of framework for the data document:
The TradeTrust framework, created by the Singapore government, provides a reference implementation of a document framework suitable for use with a smart contract to track ownership of an ETR on the blockchain. The framework makes use of OpenAttestation which is used to power OpenCerts, Singapore’s largest digital education credential, for processing the document to assert document integrity and provenance.
The OpenAttestation framework provides utilities to “wrap” a JSON document up to produce a globally unique hash, compatible with Ethereum’s smart contract. In addition, it provides important verifiable metadata to allow recipients of the document to verify the issuer of the document via their DNS name.
Out of the box, the framework allows issuers of the document to define a “renderer” to render the content of the data on web and mobile to allow the document to be viewed by humans easily.
In addition, the framework allows the holder of the document to show a subset of the document data through its selective disclosure functions without requiring the issuer of the document to reissue the document with another hash.
Combined with the ERC721 smart contract, the framework is capable of supporting all ETR use cases.
With the overview of how ETR can be created and managed on the blockchain, we can examine how the requirements listed in MLETR can be achieved.
Considering that every individual ETR document can be represented by an unique ID which cannot collide with another document, the association of the ID to a single `owner` property in a smart contract ensures that there must only be one owner of the ETR at any point in time.
The data document, however, can be copied and shared with as many entities as the receivers of the ETR document would like. This is similar to physical TR where copies of the original TR can be made by all receivers of the TR to be forwarded to anyone whom they wish to share with. The main difference between that and an ETR created in above manner is that all the recipients of the ETR will be able to verify the authenticity, integrity and provenance of the ETR as well as query for the current owner of the ETR.
To facilitate the transition of a physical TR to ETR, the issuer must also provide a service to perform bidirectional swaps.
For a physical TR to be exchanged for an ETR, the recipient of the physical TR must surrender the physical TR to the issuer who will then proceed to destroy the physical TR and issue an ETR to the recipient. For an ETR to be exchanged for a physical TR, the owner of the ETR must surrender the ETR back to the issuer who will then proceed to issue a physical TR to the recipient.
In both swaps, we rely on the business process of the issuer to ensure that only one TR is in circulation to fulfil the singularity property. Issuers of TR are incentivised to ensure that to prevent having additional liabilities on themselves when two TRs are in circulation.
The implementation of the ETR smart contract will be implemented such that the listed owner of the ETR will have exclusive control over the ETR. This means that only when the owner of the ETR invokes the transfer function of the ETR will the record update the existing owner to the new recipient. The signature of the transfer transaction is being checked to assert the constraints.
Whenever an entity claims to be the owner of the ETR, the entity may use the private key corresponding to the wallet address listed as the owner of the ETR to sign on a message to prove that he is indeed the controller of the owner wallet. This will allow one to identify a person as the person in control of the ETR.
The integrity of the document can be verified through the unique document ID. Since the document ID is the hash of the content of the document, any attempt to modify the contents of the document will result in the document hash to change. Since the hash algorithm guarantees that there will not be a collision of hash for different inputs, the new hash will correspond to one that has not been issued by the issuer, therefore showing an invalid document.
The TradeTrust framework includes a working technical implementation of how ETRs can be represented, owned and transferred by different entities.
For a demonstration of how the technology works, you may watch the first episode of TradeTrust webinar series.
Subscribe to my mailing list if you like to learn more about how distributed ledger technology can be used for public goods.