A Blockchain Solution for Data Provenance Using Hyperledger Fabric

A blockchain is an immutable, decentralized ledger that can record transactions between multiple parties within a network in a verifiable and permanent way. Government departments working in silos experience integration nightmares resulting in delayed information, unsatisfied customers, data loss, theft, tampering, etc. Kickstarting a new era of collaboration, blockchain-based solutions have the potential to make government processes more efficient and improve the delivery of public services, while simultaneously increasing trust in the public sector. This article will discuss how a typical government organization can leverage blockchain to establish the provenance of land transactions, resulting in a change in land usage or a split or merge of land parcels.

Blockchain technology comes in different flavors – public (used in cryptocurrencies, such as Bitcoin) and private (permissioned). While both public and private blockchains are decentralized, peer-to-peer, distributed, and immutable ledgers, public blockchains have a more rigorous consensus process and are, therefore, more computing-resource intensive compared to the latter.

Here are some of the business benefits of blockchain:

• Blockchain acts as a secure and trusted intermediary in managing transactions involving assets, potentially lowering transaction costs.
• Data provenance or the ability to trace back into history by maintaining a chronological sequence of events.
• Users are empowered by the transparency in transactions and high data quality due to the high reliability and immutability properties of Blockchain.
• Smart contracts that can be built into blockchain technology are self-enforcing rules that automatically execute on pre-defined events or conditions, saving users the hassle of resorting to legal measures.

Let's consider an example where citizens or residents trade land properties involving transactions such as buying, selling, or inheriting a plot of land, etc. These transactions might result in a plot of land being split into one or more plots or several plots merged into a single plot or a change in land use, leading to a new site plan being issued for the resulting land parcel. The process may involve several agencies, such as the land department, real estate agents, legal, survey, planning, GIS department, etc. Each of these agencies may have their own sub-process requiring access to certain parts of the complete information concerning this transaction.

An example business process for issuing planning permit for land transactions described earlier is illustrated in figure-1 below. Notice that after the permit is prepared, the next step is to update the parcel history or the provenance – tracing the chronological lineage of property assets along with their owners and other particulars. Maintaining the lineage of a land parcel is an audit requirement demanding a high degree of accuracy and integrity. Any change in the parcel state needs to be captured in its chronological sequence and should be tampered proof. Due to the involvement of multiple parties and the property of immutability inherent in the blockchain, it is a perfect solution for the current requirement. Information accumulated over the entire process is stored on a blockchain and access to specific data granted appropriately. In order to keep it simple, the implementation that follows only deals with a section of the overall process that concerns with issuing a planning permit.

Figure-1: Business Process for issuing Planning Permit

Let's build our blockchain solution and deploy it on the Hyperledger Fabric. Hyperledger Fabric is a blockchain framework implementation for private and permissioned business networks, hosted by The Linux Foundation. It leverages container technology to host smart contracts called “chaincode” and delivers enterprise-ready network security, scalability, and confidentiality.

We’ll also use another component of the Hyperledger project — the Hyperledger Composer, which is a set of collaboration tools for building blockchain business networks that make it simple and fast for business owners and developers to create smart contracts and blockchain applications to solve business problems.

The Hyperledger Composer application consists of four component types:

• Model – Defines domain and other elements described below along with their relationships used in the application
• Script – Implements all the transaction logic executing on the blockchain
• Query – Specifies queries in order to retrieve assets from the blockchain
• Access Control – Defines access permissions relating to the above components

The Model component above is further composed of:

• Assets – where all the business domain elements are defined
• Participants – defines all the user types within the application
• Events – defines any events that are emitted to external systems as transaction codes are executed
• Transactions – transaction objects that are passed to the implemented transaction logic

Let’s examine code excerpts from each of the files that are listed below.

Model (siteplan.cto)

namespace org.abc.siteplan

enum LandUse {
  o COMMERCIAL
  o RESIDENTIAL
  o INDUSTRIAL
  o FARM
} 

enum LandType {
  o PRIVATE
  o RENTED
} 

enum RequestType {
  o MERGE
  o SPLIT
  o NEW
} 

concept Address {
  o String country
  o String city
  o String street optional
  o String poBox optional
}

concept NewParcelData {
  o String parcelId
  o String plotNum
  o String locCoord
  o Double plotArea
  o LandUse landUse optional
  o LandType landType optional
  o Boolean active optional
  o String sitePlanDigest optional
  --> Owner owner
}

/**
 * Participant: Parcel Owner
 */
participant Owner identified by ownerId {
  o String ownerId
  o String oname
  o Address address optional
}

/**
 * Asset: Parcel
 */
asset Parcel identified by parcelId {
  o String parcelId
  o String plotNum
  o String locCoord
  o Double plotArea
  o LandUse landUse optional
  o LandType landType optional
  o Boolean active optional
  o String sitePlanDigest optional
  --> Owner owner
  --> Parcel[] predParcel optional
}

/**
 * Abstract Parcel Transaction
 */
abstract transaction ParcelTx {
}

/**
 * Merge Parcels Transaction
 */
transaction MergeParcelTx extends ParcelTx {
  o NewParcelData toParcel
  --> Parcel[] fromParcels
}

/**
 * Split Parcel Transaction
 */
transaction SplitParcelTx extends ParcelTx {
  o NewParcelData[] toParcels
  --> Parcel fromParcel
}

The model file is self-explanatory except for the symbol ‘o,’ representing an object, and ‘-->,’ representing a reference to an object. Note the defined namespace.

The script below defines two transactions, one to merge and the other to split parcels. Both transactions create and persist child parcel(s) as well as establish the lineage to parent parcels within the blockchain.

Script (logic.js)

/**
* Merge Parcel Transaction
* @param {org.abc.siteplan.MergeParcelTx} parcelTx
* @transaction
*/
async function mergeLandParcel(parcelTx) {

  const namespace = 'org.abc.siteplan';
  // Get the Parcel asset registry.
  let parcelRegistry = await getAssetRegistry(namespace + '.Parcel')

  // Get the factory for creating new asset instances.
  let factory = getFactory();
  try {
    // Create the parcel.
    let newParcel = 
    factory.newResource(namespace, 'Parcel', parcelTx.toParcel.parcelId);
    newParcel.plotNum = parcelTx.toParcel.plotNum;
    newParcel.locCoord = parcelTx.toParcel.locCoord;
    newParcel.plotArea = parcelTx.toParcel.plotArea;
    newParcel.landUse = parcelTx.toParcel.landUse;
    newParcel.landType = parcelTx.toParcel.landType;
    newParcel.sitePlanDigest = parcelTx.toParcel.sitePlanDigest;
    newParcel.active = true;
    newParcel.owner = 
    factory.newRelationship(namespace, 'Owner', parcelTx.toParcel.owner.ownerId);

    // Set relationships
    let predParcels = new Array();
    for(const fromParcel of parcelTx.fromParcels) {
      fromParcel.active = false;
      predParcels.push(factory.newRelationship(namespace, 'Parcel', fromParcel.parcelId));
      await parcelRegistry.update(fromParcel);
    }
    newParcel.predParcel = predParcels;
    // Add the parcel to the parcel asset registry.
    await parcelRegistry.add(newParcel);
  } catch(error) {
    // Add optional error handling here.
    console.log(error);
  }
}

/**
* Split Parcel Transaction
* @param {org.abc.siteplan.SplitParcelTx} parcelTx
* @transaction
*/
async function splitLandParcel(parcelTx) {
  const namespace = 'org.abc.siteplan';
  // Get the Parcel asset registry.
  let parcelRegistry = await getAssetRegistry(namespace + '.Parcel')
  // Get the factory for creating new asset instances.
  var factory = getFactory();

  try {
    for(const toParcel of parcelTx.toParcels) {
      // Create the parcel.
      var newParcel = 
      factory.newResource(namespace, 'Parcel', toParcel.parcelId);
      newParcel.plotNum = toParcel.plotNum;
      newParcel.locCoord = toParcel.locCoord;
      newParcel.plotArea = toParcel.plotArea;
      newParcel.landUse = toParcel.landUse;
      newParcel.landType = toParcel.landType;
      newParcel.sitePlanDigest = toParcel.sitePlanDigest;
      newParcel.active = true;
      // Set relationships
      newParcel.predParcel = 
      [factory.newRelationship(namespace, 'Parcel', parcelTx.fromParcel.parcelId)];
      newParcel.owner = 
      factory.newRelationship(namespace, 'Owner', toParcel.owner.ownerId);
      await parcelRegistry.add(newParcel);
    }
    parcelTx.fromParcel.active = false;
    await parcelRegistry.update(parcelTx.fromParcel);
  } catch(error) {
    // Add optional error handling here.
    console.log(error);
  }
}

The access control defined below is a simplified access privilege rules, allowing all operations on resources by all, which is normally restricted on production systems.

Access Control (permissions.acl)

rule Default {
  description: "Allow all participants access to all resources"
  participant: "ANY"
  operation: ALL
  resource: "org.abc.siteplan.*"
  action: ALLOW
}

rule SystemACL {
  description:  "System ACL to permit all access"
  participant: "ANY"
  operation: ALL
  resource: "org.hyperledger.composer.system.*"
  action: ALLOW
}

The composer application is then built and packaged into a Business Network Archive (.bna) file. This file can be installed and deployed on to the business network either in a test environment called the “Composer Playground” or directly on the Hyperledger Fabric business network. The deployed business network applications run within a Docker container as do other components of the Hyperledger Fabric.

Hyperledger Composer has a REST utility to expose all the application transaction logic for consumption by external applications via a REST server.

Figure-2 below shows a screenshot of the Composer REST server viewed through a browser. It shows the output of a Merge transaction of two parcels referenced byresource:org.abc.siteplan.Parcel#3184672 and  resource:org.abc.siteplan.Parcel#3188653, resulting in a new Parcel identified by the parcel Id 3186180. Once a Site Plan is issued, the “sitePlanDigest” field in the Parcel asset is updated with the hash value of the digitally signed plan.

Figure-2: Request and Response for Merge Parcel transaction

Conclusion

In this article, we’ve seen how to build a reliable and secure business process application featuring data provenance and deployed on the Hyperledger Fabric using the Hyperledger Composer. The real benefit is realized when multiple agencies interact securely and transparently with blockchain to complete the business request end-to-end. BPM with blockchain is a powerful combination of technologies that delivers a robust solution to address most business needs.