A Block Chain Solution for the Sri Lankan Land Registry — Part 2

This is the 2nd part of the 2-part article, where I explain how my Final Year Research in Computer Science was commercialized (or productized). In this article, I’m explaining the product LRBSL (Land Registration Blockchain for Sri Lanka). Before reading this article, it is recommended to read Part 1, where I have explained the details of my final year research titled “Permissioned Distributed Ledgers for Land Transactions’’ which led to the design of LRBSL. It should be specially mentioned that the effort of productizing the research was carried out by Mr. Ravindu Sachintha as his internship project at the Distributed Computing Group of UCSC under the supervision of Dr. Nalin Ranasinghe.

Through the research titled “Permissioned Distributed Ledgers for Land Transactions” we proposed a permissioned distributed ledger (a type of blockchain) solution for the Sri Lankan land transaction scenario.

The high level architecture of the proposed Sri Lankan distributed land ledger is shown in Fig. 1.

Fig. 1 High level architecture of the proposed Sri Lankan distributed land ledger

• Seller will submit a transaction proposal indicating the sale of her land to buyer.
• Next, the submitted transaction will be sent to all validating nodes.
• Consensus messaging takes place among validating nodes.
• If the transaction is identified as valid, it will be added to the ledger of each validating node.
• Finally, buyer could receive the status of transaction from any of the validators.

During implementation of LRBSL, it was ensured that the optimal ledger content derived from the current folio were preserved. During the research project (explained in Part 1 of this article), it was decided that Hyperledger Fabric suits for the implementation of an open-source blockchain. Hence, evaluation of the research was performed based on Hyperledger Fabric implementation. Even, during the productization effort, Hyperledger Fabric was used as the core technology. Apart from that, Convector CLI and Hurley of Convector Suite were used during implementation.

In the next section of this article, I would be explaining how land transactions designed during the research effort have been implemented in LRBSL, starting off with identifying the users of the system. Interacting parties of LRBSL could be classified into 2 categories; External users and Validators. An external user could be any person from the general public who could identify himself/herself as a Land Owner or a Land Buyer. Notaries, Surveyors and Regional Land Registries fall under the category of Validators. Notaries and Surveyors interact with external users, while Regional Land Registries do not interact with external users.

Let us now see how 2 main types of transactions, changeLandOwner and forkLand have been implemented. During the Land Ownership Changing from one person to another, the following steps shown in Fig. 2 are performed.

Fig. 2 Notary voting of changeLandOwner transaction

1. Land owner and buyer meet a public notary with the land security key (provided in the owner’s deed) and respective NICs. The land security key is a unique value provided for a land. This value changes per each land transaction.
2. Notary will initialize a land ownership changing transaction after verifying owner, buyer, deed, plan and land pedigree records. Here, the system automatically performs verification, however the validator has to provide active consent by clicking on the ‘Accept’ button.
3. Initialized land transaction request will be sent to another two public notaries associated with the said land or adjoining lands.
4. If the transaction request obtains two or more up-votes, the request will be sent to a committee of RLRs for the committing process. Otherwise, transaction request failure will be informed to notaries, who will inform that to the land owner and buyer.

During the Land Partitioning/ Forking scenario, the following steps shown in Fig. 3 are performed.

Fig. 3 Surveyor partitioning during forkLand transaction

1. Land owner meets a surveyor with the land security key (provided in the owner’s deed) and the NIC.
2. Surveyor will initialize a land partitioning transaction by analyzing and verifying owner, deed, plan and land pedigree records.
3. Surveyor will create two new child lands with updated extents and boundaries. Here, the system automatically verifies whether the sum of the extents of the new lands is consistent with the extent of original land and whether boundaries of newly created lands do not overlap with each other.
4. Initialized land transaction request will be sent to three public notaries associated with the land or adjoining lands and the transaction validation process will happen as before.

For both of the above scenarios, after the transaction request obtains two or more up-votes from notaries, the request will be sent to a committee of RLRs for the committing process. During the RLR Committing process, following steps shown in Fig. 4 are performed.

Fig.4 RLR committing process for changeLandOwner and forkLand transactions.

1. For both cases above, a notary validated transaction request will be sent to the RLR where the land is situated, to be committed to the blockchain.
2. The land transaction request will be sent to another two more RLRs. These 2 RLRs could be RLRs that hold copies of the deed. Even if they do not hold copies of the deed, since they have access to the island wide unified land ledger, voting is possible.
3. If the transaction request obtains two or more up-votes, the request will be committed to the blockchain. Otherwise, transaction request failure will be reported to RLRs and relevant public notaries.
4. Shared database will be updated according to the relevant deed data of the committed transaction.

A demonstration of the above mentioned features, is included in the following video.

In the next section of this article, I would be explaining the advantages of LRBSL over the current manual system and how the loopholes of the current system have been addressed by LRBSL.

A quorum vote based validation system has been introduced for each transaction as we believe that centralized corruptibility could be overcome by distribution of responsibility. Through this move, possible frauds by authorized parties (notaries, surveyors and RLRs) could be eliminated.

LRBSL is capable of handling deliberate manipulations of land transactions by its users. For example if a fraudulent owner tries to sell a land with a forged deed which is based on a forged NIC, it could be captured during RLR voting. Use of name/signature of deceased notaries for the purpose of land encroachment could be overcome by obtaining 2/3 notary votes. Efforts of people trying to sell the same piece of land multiple times during the time taken to update the folio in the manual system could be solved by the blockchain process. A fraudster’s attempt to collect a copy of a deed or create a forged deed, with the aim of registering and selling a land under a deceased notary’s approval, could be solved through the blockchain process and 2/3 notary vote.

Unlike in the manual system, through LRBSL, the land transaction process has been made tamper proof. It is a known fact that in the current manual system, tracing the pedigree is a time-consuming and difficult task. Although LRBSL has got away with the folio system it has ensured derivation and visualisation of the pedigree/folio tree for a land at a given time efficiently.

Thus, we firmly believe that the Proof of Concept proposed by LRBSL justifies the suitability of a blockchain based land registry for the Sri Lankan land transaction scenario.