Applied design of distributed ledgers for real estate and land registration

(1)

IN

DEGREE PROJECT COMPUTER SCIENCE AND ENGINEERING, SECOND CYCLE, 30 CREDITS

STOCKHOLM SWEDEN 2018,

Applied design of distributed ledgers for real estate and land registration

RICCARDO SIBANI

(2)

Abstract

The recent emergence of a distributed technology named blockchain, clearly created a new point of view in the data storing and data distribution fields. If on one hand blockchain is mainly known for Bitcoin (an auto-regulated decentralized digital currency), on the other hand it has the potential to set up an auto regulated economy.

In this thesis, the blockchain technology will be analyzed and described starting from P2P architecture and its origin in 2009 Satoshi Nakamoto’s whitepaper, and leading to the most up to date blockchains. The advantages and disadvantages of such architecture will be pointed out keeping in mind the security, speed and cost of such infrastructure.

While Real Estate companies have often anticipated the technological innovations, land registries, instead, derive and keep a working manner which is extremely old and out of date: made of unclear procedures and wet signatures. The market needs and legislation will be researched mainly referring to other works and integrated with a technical point of view with particular focus on the decentralization of such systems.

After analyzing the flow, problems and flaws of the current system, a new proposal will be researched, in particular trying to minimize the dead time in between the diﬀerent steps of the mortgage, increase transparency, as well as reducing dependence on the central authorities, leading to more convenient interactions among the properties’ stakeholders. An attractive low capitalization decentralized financial product will also be proposed and implemented able to lower the interest rate and create a profitable investment with low risk, low interest and durable in time.

Secure and ad-hoc algorithms will be presented and, in a later section, analyzed in combination with diﬀerent blockchain technologies. Scalabil- ity and performance will also be evaluated, taking into account all the current technology limitations and the near future opportunities.

Keywords— Blockchain, DLT, Land registry, Real estate

(3)

1 Introduction

Real estate is among the most innovative markets, with research in AI, VR and blockchain. While many eﬀorts are put in providing a better consumer experience, many little has been done in order to improve the financial products attached to properties such as mortgages and loans.

Mortgages can be tracked back in time to Romans (Mutuum) and since then, the modalities of it have not changed much. The current terminology and regulation in the common law is from the end of the 18th century. While the real estate market had kept changing with diﬀerent architectures, selling channels, companies and laws: the mortgage did not change, remaining a product sold by rich entities to people in need of liquidity.

The real estate market, solely in Europe, is considered to be worth e25.1 billion in 2016 (Deloitte 2018[b]), and it also believed to be one of the most innovation driven, mainly in the north and central Europe (Deloitte 2018[b]).

The rise of the blockchain technology, dated 2008 (Nakamoto 2008), creates the opportunity for a decentralized platform where small actors can fund somebody’s property, enhancing mortgagors to access mortgages at a lower rate and, perhaps, even with a not less than perfect credit record and for small investors to become mortgagee and accessing an investment product with low risk, for long time and without big initial capital.

Blockchain can be plugged in place of or along with a traditional infrastructure, providing the database and back end services and ensuring the same functioning.

Such solution is Peer to Peer (P2P) based and, therefore it inherits all the benefits of a distributed system such as the absence of a single point of failure, and the distribution of information (which translates to resistance towards censorship).

Blockchain, thus, is designed with cryptography in its bones and the whole system can only work if it is encrypted asymmetrically (such encryption mechanism allows to verify and certify the signers and the authors of the transaction), increasing the security and still being able to prove the sender of the message, and its consequent update in the database.

This database is periodically updated, that is to say it changes its state at every new block that is broadcasted in the network. One block can contain multiple transactions in order to optimize the speed of the algorithm (only one block needs to be shared instead of all the transactions and is faster to verify big number of transactions) and, since each block points to the previous one (thanks to an hash of it), it is possible to order chronologically and recreate the same state at the same block height (meaning at the same block number in the chain).

Given the possibility to host a database locally, there arises the opportunity to access all the information without trusting any party or to simply ignore a misleading behaviour: the majority leads the algorithm.

Creating secure financial products on the blockchain is possible and without requiring the trust and certainty of a central authority (i.e. bank), thanks to a contract that is self administrating. The only operation required by the stakeholders of the mortgage is to run a node: a client-server machine that is in charge to communicate with other peer machines and generate consensus over the mortgage contract and the blockchain itself in general; the cost of running

(6)

such a machine is low: it can be done with a normal laptop or hiring a small server in a common PaaS provider (but, more in general, it depends as well on the blockchain consensus mechanism in use).

What this thesis wants to achieve is to investigate the possibility of a decentralized architecture that enables new, and possibly better, financial products.

1.1 Background

Many real estate market and land registry services around the world are still paper based or supported by outdated IT systems.

The property in many countries is proven simply with a wet signature and counterfeit contracts are more than common in India, as well as the falsification of public records held by the governmental institutions. This pushed Indian authorities in the region of Andhra Pradesh to explore the possibility of the blockchain ¹.

Another hazard is in case of a coup d’etat or civil war that erase or lose the ownership records, there are some initiatives that tries to undertake such problem with blockchain (Conferences | Abt Associates 2018).

In such cases is diﬃcult to claim the right over a property.

In the western world this scenario is far from common. It is instead possible to use the blockchain as a point of contact between diﬀerent organizations and to streamline the processes that involve real estate properties as seen in Sweden (CoinTelegraph 2018) where, thanks to a blockchain based process, is possible to transfer the property within hours (instead of months) and, at the same time, automating part of the process.

Last problem is the segmentation of assets, meaning the possibility to find investors only for a fraction of the project. For big projects this is achieved with joint ventures or consortiums that invest altogether an high amount of money to fund an initiative.

While a borrower can only request a loan to the bank, there are plenty of investors (such as pension funds) who want to invest discrete quantities of money in financial products that give them fix and stable returns for a long time, typically years.

What usually happens is that a central authority (i.e. a bank) acts as ar- bitrator between borrowers and investors asking for higher interest rates to the mortgagor and distributing lower returns to the investors.

This process if ineﬃcient from the borrower and investor perspective and can be optimized removing the bank from the process, guaranteeing higher convenience to all the other actors of the deed.

It is possible to observe that some strategic areas are interested in a decentralized network, although a real complete system is not yet public utilized.

1.2 Problem

The modality used by people to sell and buy properties, have not changed in the last years. We can aﬃrm that while the indexing processes and the operations carried out by the single company have been successfully digitalised,

1Tamper-proof degree certificates to be India government’s first blockchain project (https://factordaily.com/degree-certificates-india-blockchain-project

(7)

the information and operations between companies (and governments) did not improves in despite of the eﬀort put.

Loans, transfers of properties and verifications of the correctness of the information are processed in a modality that, in 2018, must still be carried out oﬄine: checking contracts and using wet signatures. Some companies might use technological support like FAX or emailing PDF files but these just mimic the (old) paper process.

With the new emerging technologies such us blockchain, we believe that this part of the business might be revolutionized creating new opportunities and an easier and faster workflow.

The last problem this thesis wants to address regards the segmentation of the properties (assets): this is a hot topic that many companies tried to achieve but always through internal processes and therefore without possibilities to expand and scale the market.

The principal problem of segmentation is the traceability of the owners, the polish of each record and, most important, the certainty that the total amount of shares of the mortgage/loan has not been oversold.

As an example: a property of 10 000 000e is split in 10 segments (or parts) of 1 000 000e each.

The buyer must be therefore sure that there are only 10 segments available and that a potential scammer is not not double selling (i.e. selling 11 segments when only 10 are available).

Summing up these three problems, we can observe that the main issue of the Real Estate market is based on the absence of a shared protocol where the firms can interface and collaborate.

In general the authors also observed that the Real Estate market is usually very propositive and open to innovations but has always found problems in scaling due to the diﬃculty to communicate among diﬀerent platforms (or to agree on one shared platform).

1.3 Purpose

The purpose of this thesis is to design an alternative solution to the current legacy real estate processes, which brings the current advantages of the centralized solutions but that is willing to extend the decentralization in favour of the aforementioned benefits (no middle man, higher security, high availability).

To learn in deep knowledge about blockchain and how to apply it to the real estate market adopting adequate methodologies is also a precious purpose for the writing of this thesis, possibly re-utilizing the learning outcomes received during the master degree. To present and describe an holistic view over the current state of IT applied to real estate environment oriented at the financial investment.

To provide an ethical point of view and hopefully introduce new products oriented at the crowdfunding and micro-lending of properties.

1.4 Goal

The goal of this thesis is to investigate the real estate market, and design a new solution able to undertake and solve the problems described in 1.2.

Key areas for improvements are:

(8)

1. Inter-company communication: Communication among diﬀerent actors, beyond the single company boundaries such as private investors, banks, governmental entities and / or any other actor mentioned in a standard contracts.

2. Streamline the paperwork: Introduce a structured and well defined workflow for the most common contracts; ideally embracing the majority of the situations (multiple or single actors, refuse of the transaction, inter- ruption of the negotiations etc). Lowering the amount of paperwork also through auto-complete and at-most-once (McKinley 2017) writes.

3. Central point of information: Creating a solution used by diﬀerent and distinct actors allows to gather the information into a single endpoint: eliminating the segmentation of data, the diﬃculty of querying and the need and complexity of MLS (multi listing services, meaning portals where to look up for properties). When having a single central point, usually some risks and costs arise such as the single point of failure, data ownership, storage, maintenance and server cost.

When about to design such architecture, the standard approach would sug- gest to create a centralized (and perhaps distributed) system owned and ruled by a single authority such as the Land Registry. Such architecture has been so far the only solution, showing problems in the 1. data asymmetry (the spread of information that each player of the system has access to: the owner of the system can consult the whole database, despite the clients), 2. reliability (there is the need of trusting and consider authoritative one single source), 3. system fault tolerant (a bug or down service of one single player would result in a stop for all the systems that rely on the centralized solution), 4. transparency (that can decrease the time needed to fill and sign the contract back and forth and, in general, the service and user experience) and 5. nullify the risk of corruption (since each and every change must be approved by the network). As such, given the limitations of the current centralized systems, the research question that this thesis intends to answer is:

Can we design a Blockchain based solution for real-estate management that outperforms centralized based approaches in terms

of security, scalability, accountability, and access to information?

A blockchain based solution will be developed in this paper and then evaluated in the evaluation section (6) on its performance, security, transparency, reliability and transparency, comparing it to a standard centralized solution in diﬀerent scenarios (6.4).

1.4.1 Benefits, Ethics and Sustainability

With a particular focus on ethics and sustainability this thesis wants to achieve.

1. Crowdfunding: The possibility to fund and invest in projects of refur- bishing or building of properties, possibly selling the units in advance.

2. Micro-lending: Segmenting the mortgages on the properties in units, it is possible to create an interesting investment opportunity for the middle

(9)

class with a low level of risk. At the same time is possible to borrow money for a low crediting score mortgagor.

3. Simplify the mortgage registration: With the help of banks and governments is possible to digitally stipulate contracts, simplifying among the others: tax payment for mortgages since the information can be publicly available in one point of truth.

4. Lower the contentious: With a clear workflow is easier to respect dead- lines and avoid pro forma delays, therefore lowering the legal costs.

5. Paper saving: Small achievement, but worth to be mentioned is the amount of paper saved due to the shift to digital platform and consequently limitation of the deforestation risk.

1.5 Delimitations

The solution that will be presented should be secure and at the same time should avoid the danger of data manipulation. Ideally it should not be centrally owned but rather run by a consortium of stakeholders.

The proposed solution must be cheaper and in any case not more expensive than the current and standard workflow.

The system does not need to support frequent write operations but should be fast in reading and potentially queryable.

This theis will not take into account any legal aspect and will try to keep as closely as possible to the current legislation. This work is anyhow intended as a CS master thesis and not as a law text.

(10)

2 Literature review

In order to expose the main characteristic of the blockchain technology, it might be required to take a step back and analyze the decentralized systems such a P2P, which are able to provide similar performance of a centrally controlled cluster, but in a not controlled and censorship resistant manner. Although P2P networks are advanced systems, they still lack security and privacy wise, that is the main reason why a blockchain system (which is P2P based) is needed in order to secure information.

2.1 Peer To Peer

Peer to peer (P2P) is an architecture of distributed machines that collaborate in a network where each end point is both client and server and they all have same rights and duties.

P2P (Agre 2003) is usually utilized to share resources among each partici- pant without a centralized system or authority. It is based on self organizing algorithms where each machine has the dual and symmetrical role of client - server; usually the topologies of this network is not known a priori. It is in fact possible to aﬃrm that there is a P2P network over the internet network which is called overlay network.

There are two classes of overlay network: structured and unstructured.

2.1.1 Structured network

Structured networks are usually tightly controlled by a central authority or, anyway, by a subset of super nodes with higher privileges (Agre 2003). The central authority decides where to store the contents in a distributed fashion and takes in charge of the indexing of the fields and their location in a key-value data structure. In case there is no central authority, the peers implement a distributed hash table (DHT).

When a new content needs to be stored it is first hashed and then assigned to one or more nodes where it will be stored. Essentially each peer has a Routing Table (RT) with the address of the peers. Based on the level of replication (r) it is divided into bands (b) of length (r). Given n peers we define the number of bands as:

n = b⇤ r

s.t. hash(content) % b = peerip

Where the hash function can be extended to any cryptographic hash function (Preneel 1994) in order to split similar files that would be sized in the same bucket. The DHT approach guarantees a lookup of Olog(n) and can be seen as an optimal solution if not considered unsafe (replay attack, local file corruption, etc). There are several security breaches in the DHT mainly in a P2P network of non-stakeholders nodes.

As an example: the node which host a certain content might return a corrupted file or information. In this situation, even with a distributed content DHT would be diﬃcult, if not impossible, to trace back the correct information;

(11)

although the same file delivered by a consistent majority might be considered satisfying.

An higher level of security might be implemented such as hashing the file and storing it locally, create a versioning system to detect out of date information and files or implementing public - private key system. All this improvements cannot guarantee appreciable results.

For further security consideration is suggested to check the literature (Sit and Morris 2002).

2.1.2 Unstructured Network

Unstructured P2P networks are loosely ruled networks where basically any node can join, ideally without restriction (Agre 2003), it has stronger censorship resistence and does not need the a central authority. Nevertheless the absence of a central authority makes the network hardly scalable since it is diﬃcult and time consuming to reach all the nodes (e.g. for look up operations): typically with a flooding algorithm.

Some solutions have been suggested, among them, worth to be mention is the OpenDHT (Rhea et al. 2005): a DHT hosted by some nodes which decide to publish their knowledge in a public repository, using the so called web of trust (PGP: Explanation of the web of trust of PGP 2018). Although not solving the problem of the central authorities but simply shifting the authority from the owner of the system to some more reputable source which might be in same modalities an attacker or malicious.

2.1.3 Example of P2P applications Well known P2P applications are:

1. Napster(Harris 2018): P2P file sharing characterized by a structured network and coordinated by a central search facility, and therefore a single point of failure.

2. Gnutella(Mitchell 2018): born with the same purposes of Napster as a file sharing platform. It is the first example of P2P overlay unstructured network.

2.2 The need for decentralization

Although at the end of the 20^thcentury the need of decentralization was real, as confirm the many alternatives of Napster and Gnutella (BitTorrent (BitTorrent Protocol 2018), eDonkey (eDonkey Protocol 2018) and Gnutella2 (Gnutella2 2018), just to name a few).

News often pointed at the P2P network as something illegal, blurred or to be obscured. There have been cases of websites shut down due to their behaviour as a repository bucket for P2P contents (Napster (News 2006) and Piratebay obfuscated in the Netherlands (Pirate Bay access blocked by Dutch telecoms after court ruling 2017), only as western-world examples). P2P contents are fully shareable and diﬃcult for governments and privates to censor, manipulate, regulate and perform any other exercise aimed to centralise the authority (Agre 2003).

(12)

P2P seems, in fact, to be an out-of-control tool where anything can happen:

it can host illegal as well as government censored documents. Information that governments and centralized authorities want to keep secrets for one reason or another. Rather it is correct or not the application of P2P networks allows to fight and foam the stream of the knowledge either good or bad.

2.2.1 The 3 challenges of P2P

The development of the P2P protocols went straight over the years, trying to solve the 3 main problems: scalability, synchronicity and security.

• Scalability: Mainly in unstructured network is diﬃcult to scale, some nodes could be switched oﬀ, some other might arbitrary delete files or undertake malicious behaviours. To fix this problem is possible to create a ledger which tries to maintain the current status of the system. Designing an algortihm to handle the status of the system leads to another problem:

synchronicity.

• Synchronicity: Maintaining a consistent state among diﬀerent peers is complicated. The main P2P networks such as OpenDHT uses a particular routing table construction (Rhea et al. 2005) but it all comes down to the complexity of at least On such is round robin or flood algorithms, with some possible optimization. Avoiding classic gossip algorithms through timestamp does not entirely solve the problems because the clocks are extremely hard to synchronize, not counting that malicious nodes could easily fake the time. The implementation of timestamp can also lead to reconciliation problems in case of divergence (fork), forcing, in the worst case, to end up with a classic gossip algorithm in order to ensure a syn- chronised solutions such as (Lamport et al. 2001).

• Security: One solution to increase scalability is lowering the level of security, creating the opportunity for double spending or replay attacks.

Since P2P networks use to host sensitive contents, security has always been strongly taken into account: creating slow but reliable decentralized networks. In case of fork, thus, it will be diﬃcult to determine the correct branch and without further implementations, it would be easy to create a high number of nodes (50% of the network peers) and arbitrary propose new values (rewrite attack). Such attack is extremely easy because peers could just be virtual machines.

It is easy to fall into game theory and even easier to find in this triad (scalability, synchronicity and security) analogies with the well known CAP theorem (which will be analyzed in 2.3.1).

2.3 Real Time Applications

The P2P networks faced problem in scalability (Leao, Menasche, Towsley, et al.

2014) and intrisical synchronicity is a notorious and well known design problem.

It can therefore been improved according to the CAP Theorem.

(13)

2.3.1 CAP Problem

The CAP theorem asserts that any network which shares data can have at most 2 of the following characteristics: 1. Consistency (C) 2. High Availability (A) 3. Tolerance to partitioning (P). With the due optimization is possible to find acceptable compromises of the 3 but always with some sort of trade of.

CA Having a consistent system can be the number one priority. In case of a centralized system, where no partitioning takes place, is not too diﬃcult to design. One server always running can update its information in one unique ACID operation on the database.

In case of partitioning, a conciliation strategy can be intended as temporary suspension of the availability of all the n partitions (at least for sensitive operations) or as at least momentary inconsistency of the m sources of information.

AP Having a system which is always available and partitioned leads to inconsistency of the data. As an example, one number can be written in the system.

User A writes the number 1 on partition 1, nearly at the same time, User B writes number 2 on partition 2. At this moment the two partitions are not consistent. To solve this problem, availability of the write operation must be suspended when one of the two partitions receives the write request (perhaps acquiring a lock). In real application availability can be often be confused with latency, for further information is possible to refer to (Brewer 2012).

CP Having a consistent and partitioned system implies to sacrifice the availability of it. When one partition wants to perform a write operation, it must notify the other peers and wait for the authorization to commit the change in order to preserve the consistency. The system will then be momentarily un- available.

As highlighted in (Brewer 2012), forcing to select two properties out of three is misleading. Is in fact possible to create granularity among partitions or slightly decrease (or optimize) the availability time or sacrifice a bit of consistency in order to guarantee high performances.

In the next section will be presented the blockchain technology, not as a solution to the CAP theorem since it would hinder the definition of theorem itself, but rather as an optimization of the three factors: consistency, high availability and tolerance to partitioning.

2.4 Blockchain

In 2008 a paper signed by Satoshi Nakamoto (Nakamoto 2008) flipped the table proposing new ideas. The paper undertakes the time uniformity, synchroniza- tion, scalability and security problems in a diﬀerent fashion which, at the time of writing is getting a vaste consensus.

Although the paper proposes a new electronic cash system, the real innovation in it is the blockchain concept, which is a method to gather transactions into blocks that are easy to sort.

(14)

2.4.1 Bitcoin

Bitcoin cash system has been designed addressing 3 main problems:

• No central authority: As the P2P network, Bitcoin must function without any central authority ruling it. If there are no inspectors, than nobody is allowed to change the data and balances at will. The authority is therefore given to the algorithm itself and to/by the amount of people who run a node in such configuration.

• No mediation cost: the mediation cost shouldn’t be high. Each transaction should be cheaper in compare with the central authority that can set an arbitrary price. In a P2P fashion, the node willing to mine at the lower price wins. Although in the recent period this goal seemed to be vanished (Resende 2017).

• No possibility for casual transactions: transactions should maintain a logical order and each transaction processed by the peer should be reliable.

In fact, as of the time of writing the paper a system that was able to process payments over a communication channel without a trusted party did not exist.

On one hand the legacy programs such a ATM (Magee et al. 2004), were able to provide near instantaneous transactions but with the help of a central authority. On the other hand online payment systems and digital currencies developed: debit cards, credit cards, Mondex (How smart was that? Swindon Advertiser 2018) (in Spanish), Mobipay (Bancos y operadores crean Mobipay, plataforma de pago por movil 2001), Apple Pay (Apple Pay 2018), Google Pay (Google Pay - A better way to pay 2018) and, Swish (Brunet 2017) just to name a few, couldn’t be synchronized and consistent in a distributed manner.

The solution must ensure:

• Secure transaction: The transaction should be computationally imprac- tical to reverse. Once the sender of a certain amount of money broadcasts her transaction, other users or malicious actor must not be able to change it.

• Safety from frauds: frauds should be prevented. In particular the double spending attack (Ferguson 1993) which is a common flaw among crypto currencies and digital cash systems which consists in spending the same asset more than once duplicating or deviating its original course.

• Distributed and synchronized: The timestamp is decided by the peer servers and is used in order to both validate the transaction and to generate the computational proof.

Transactions The owner of some tokens digitally signs a transaction where she specify the next owner public key and the hash of the previous transaction.

The signature allows to certify that the owner (or whoever is in control of the owner’s private key) of the token is actually performing the transaction, the next owner’s public key allows the system to transfer the tokens while the hash of the previous transaction is useful to retrieve the history of the tokens themselves:

thus it assure that the tokens are not created out of nothing.

(15)

It might be that several transactions refer to the same previous transaction.

In this situation, the first transaction mined - which means the first transaction able to unlock the unspent amount - gets the money and is recognized as valid by the P2P system which implies to receive the proof of acknowledgement by the majority of nodes. This workflow is implemented through the block chain mechanism.

Timestamp Timestamp is used as a variable in order to create diﬀerent block hashes. The timestamp assures that the block has been mined in that time as it is validated by other servers, servers accept the timestamp only if it is included between to the median of the timestamp of the last 11 blocks +2 hours (Block timestamp - Bitcoin Wiki 2018) and the last block timestamp + 1 millisecond.

Hashing a timestamp also means to reinforce the previous timestamp, rein- forcing the older transactions.

Proof of work Proof of work is a mechanism that tries to guarantee the one CPU one vote ideology. The proof of work consists in hashing a block of transactions seeking for a small value. Since the hash is nothing but a number that cannot be known a priori, it is randomly possible that this number is lower than a certain value. The hash can be generated using SHA-256. Since the number is computed in binary form, targeting a lower number is nothing but the leading zeros in the binary number representation into the memory. Since the possibility of finding a hash with many leading zeros increase as the leading zeros increases, this property is used in order to increase the diﬃculty, and therefore the time, needed to mine one block. This idea has one very interesting and game changing application:

Since finding a solution to the block in a fixed time is a matter of chances, in case one malicious user wants to change one of the transactions mined by one block, she needs to find another solution (time consuming) in order to mine a second time the block. Of course one user (or a subset of users) will need more time to find the solution, at least guaranteeing that the number of user do not have the majority of the computational power! Even once the solution to mine the block had been found, the blockchain (that mine blocks at a fixed time) will have progressed with an higher number of block. Since each block contains at its inside the hash of the previous block, it means that the block created by the malicious user is not recorded into the chain of blocks itself. The only way for the attacker to convince the others to use her chain is to start mining another block until she has a longer chain than the one on the network.

This possibility is very unlikely and the chances of success of such attack decrease as the time passes because it requires more and more computational power. A very interesting attack that can take place with less then the 50% of the computational power (ideally down to the 25% of the network) is described here (Eyal and Sirer 2014).

Network The P2P network is the core that allows Bitcoin to survive and to spread itself. When a new transaction is created, this is broadcast across all the nodes that might want to start mining a block with this particular transaction in it.

(16)

The signers of the transaction might prefer to have their own transaction mined as fast as possible and therefore create incentives for the miners that will mine their transaction: this incentive is called mining fee. When a node receives a transaction, it puts the transaction into the block (where there are other transactions) and start mining it: meaning trying to find a hash with a low number of leading zeros. The first node that finds the solution broadcasts it to all the network. The nodes that receives the solution to one block should accept it only if the transactions contained in the block are genuine and correct (no double spent and there is suﬃcient balance) and then start mining a new block with the hash of the latest block accepted, creating the chain of blocks.

The nodes have interests in accepting the block because is the longest chain the one that wins. Mining from a fresh block, thus, does not inficiate the complexity or diﬃculty of the block resolution.

In case of one node receives a block which point to a previous block which unknown by the node, it can simply broadcast a request for the missing block or blocks until it has the full blockchain.

Incentive The first transaction of the Bitcoin is particular. it allocates tokens without any premises to the creator of the block. In order to have their own transaction mined (or mined faster) the signers might leave an amount of tokens unspent and without receiver.

The miner can assign the unassigned tokens to herself plus, at every new block, a certain amount of tokens can be created until the limit of 21 Million of Bitcoin is created (What Happens to Bitcoin After All 21 Million are Mined? | Investopedia 2018).

In the situation an attacker has the majority of the computation power she can decide either to use it in order to compromise the network or either to mine and get the rewards reserved to the nodes which find the block solution.

With this system is possible to use the selfish behaviour of the users and convey it to the good of the community.

Disk space Storing the blocks and the transactions takes a linear amount of memory that, in the long term, can become diﬃcult to handle and expensive to maintain. In order to save main memory space, all the transactions are condensed in a Merkle-tree (Merkle 1987). Merkle tree consists in putting in the leafs of the tree all the transactions and hash them in pair. This procedure is done recursively until there is only one unique hash the network has to agree on. With the Merkle tree is possible to verify the correctness of one transaction, therefore ceasing the possibility to submit a non existent transaction. Thus it allows to verify the existance of one transaction in logarithmic time and space (Szydlo 2004).

2.5 Note to the reader

There are diﬀerent type of blockchains: public and permissioned. While the first one are usually open to anyone, everybody has the same role and the transactions are processed with a fee, the premissioned blockchains are usually role based and only some people have access to it. This is an example for a consortium that wants some participants to have access to it, but not allow any information out to the external world.

(17)

In this thesis, when not specified diﬀerently, permissioned blockchain will be intended when referring to blockchain.

2.6 Assets on the Blockchain

One of the biggest problems that characterized the gap between real and digital world was the possibility to duplicate files (content, or objects) at will. The arising 3D printers are one example of such a gap.

With blockchain, instead, is possible to define rules that are diﬃcult, if not impossible, to change: allowing a determined number of object to be created and not only fixing that limit, but even controlling it. Bitcoin is one example of it. There is a known quantity that increases under certain rules defined by the algorithm itself. The value of the coin is also given by the acceptance of the people towards those rules.

2.6.1 Property management

In a blockchain environment, the property over an asset is expressed via the public / private key possession. Each asset is signed and has a public key associated with it. This means that everybody can see its content but only the user whose is able to unlock it with her private key can claim the ownership.

This plus the distributed and tamper proof characteristics of the blockchain creates a game changer scenario since the storage becomes bulletproof secure.

2.7 Property Management

Real estate agencies are, among the market, one of the eager innovators. In Europe, the market is considered to be worth e86.8 billion only in the Q4 2016:

for a total of e251.1 billion in the whole 2016 (Deloitte 2018[b]).

It is also a dynamic market whose is searching for new opportunities and ideas in IT field. Among the others:

Public sales data Creating a unified and friendly endpoint where to buy and sell houses and properties. These centralized applications can also function as a platform where rent out properties or calculate / sell mortgages (as an example (Inc 2018)).

Integration with VR/AR It is possible to digitalize properties and upload the pictures or 3D spaces online so that interested clients can have the look and feel of the properties they are interested in without visiting them.

It is possible to use satellite technologies to show property boundaries, ex- terior and interior infrastructure, as well as with google indoor maps (About - Google Maps 2018) (Views For Business - Google Maps | Business View - Home 2018).

In addition is possible to render spaces with Virtual Reality (VR) or Aug- mented Reality (AR) (BBVA 2017).

(18)

Improved automated validation Software able to estimate the correct price of the property given detailed information such as location, dimension, age and condition of real estate.

Zestimate claims it can estimate the value of a real estate within the 7% for 50% of the inquires made (Zillow n.d.).

IoT to show properties Thanks to IoT is possible to open locks and show properties from remote. This feature is particularly handy for remote places or to create a rent estate platform.

Online conveyance Buy and sell properties online gives the opportunity to speed up the conveyance process. It also allows to buy and sell when the two (or more) contractors are far away from each others: creating the opportunity for a property brokerage and arbitrage.

Example of fast conveyance are the private easyConveyance (easyConveyance 2018) or the governmental controller Swedish Land Registry (CoinTelegraph 2018)

2.7.1 Property Management on the blockchain

According to Deloitte (Deloitte 2018[a]), 10% of the global GDP will be stored in the blockchain by 2025.

The main reasons why the companies are interested in blockchain technologies are:

• Nearly real time operations: Transactions can be pushed to the Bit- coin blockchain in fairly fast time: usually within 10 minutes. A record can be considered acknowledged by the network after 1 hour (Why 6 con- firmations? 2018). The contracts can therefore be signed online and the deal starts in hours and not days.

• Trustless environment: Since its decentralized nature, is possible to run the nodes and transfer assets without a central authority, thence companies do not have to rely on banks and other, potentially, corrupted or malicious entities.

• Distributed ledger: The grainy structure of the network, in combination with the fact that the whole blockchain is store by every and each node, makes possible to have history and proof of all the transactions ever happened.

• Irreversibility: The only way to delete or change a transaction is with a higher computational power than the network (and a suﬃcient amount of time).

• Censorship resistant: Thanks to the Irreversibility and Trustless environment properties, it is obvious to assume that there is no way to censor any record stored in the blockchain if not the majority of the network agrees on that.

(19)

3 Theoretical Background

The design of a platform of buy and sell properties might seem trivial, the main problem resides in the standards that must be accepted by all the actors, people might think.

It is actually far more complex. First of all is diﬃcult to accept a standard when there are so many entities in conflict. Some agencies prefer XML, some others JSON or SOAP.

Having solved these political problems, the main issue is now: who owns the data?

In a classic client server system, there must be one company that holds the data and is in charge of keeping the software up and running: one server on demand is not enough, somebody has to administrate it and this is often done by third party expensive firms such as IBM.

Another problem is the quantity of queries that can be performed: if one firm is running data intensive queries while the others are making few queries per day, why should all pay the same fee?

Of course there are several fixes to such an other situations but it might be preferable to merge the natural benefits of the blockchain and create a decentralized system where companies can have a clear and optimized APIs and, at the same time, assuring an higher degree of security.

More in general if signature features and causal order and fast transaction rendering is required, the most eﬃcient solution is blockchain.

3.1 Postchain

Postchain is a blockchain based on a SQL server. What it does is creating functions in a sort of contract (that is technically called module). Functions can be of two types:

• Operations: Operations are recorded into a block. One operation is de facto a transaction that changes the state of the system: that is the reason why it needs to be recorded and ordered into a block. When one client creates a transaction she can call one or more operations. The P2P server (blockchain) will execute those operations in order: changing the state of the blockchain in a deterministic way. For rigour, one transaction can host multiple operations, that will appear as if happened simultaneously.

• Queries: Queries are calls to the blockchain node and not to the blockchain directly. Since the node is basically a REST (REST - Semantic Web Stan- dards 2018) server that process the logic and writes / reads the updates into an SQL database, it is possible to query information without writing into the blocks but simply querying the database as a normal REST server.

Postchain is a private blockchain, which means that only the nodes who are entitled to enter the network and are accepted can participate into the consensus algorithm (which is a variation of the PBFT algorithm).

(20)

3.2 Flexible tokens

Flexible token is a module built on top of Postchain and it can be easily imported into other modules in order to transfer any kind of asset with ease.

The module allows to transfer tokens of diﬀerent assets in an atomic and secure way.

It is used in this project thanks to the abstraction that every property is an asset and every shares of the property is one unit of such asset (ChromaWay 2018).

3.3 PostgreSQL

Postchain can ideally be plugged into any database (even noSQL) thanks to its modularity. The most common database management system used so far in combination with Postchain is PostgreSQL (PostgreSQL: The world’s most advanced open source database 2018).

SQL languages are preferred because they allow custom and complex queries to be created by developers with no specific blockchain knowledge. It is in fact estimate to be more than 3mln of SQL developers while only 2000 distributed ledgers experts (MIT Venture Capital & Innovation 2018).

The reason why this project will use PostgreSQL is because it provides better data integrity, allows to create customs and complex stored procedures (which are at the core of Postchain) and is particularly well suited for complex database design (SQLite vs MySQL vs PostgreSQL 2018).

3.4 Kotlin

Postchain is based on Kotlin (Kotlin Programming Language 2018): a Java based framework which can compile in several languages, among them: Java and nodeJs.

This is particularly handful to create diversity and granularity among the nodes. It is in fact known that diﬀerent nodes should implements a variety of algorithm, software, languages and operating systems in order to avoid attacks (Buntinx 2015).

Modules can be implemented in any language supported by Kotlin, in this project the standard Kotlin will be used.

Kotlin is also statically typed, this facilitates the reading of the code and avoids errors and at the same time keeps the code concise. Kotlin is as well a safe language and avoids common compilations errors by nature such as null pointer exceptions thanks to specific wrappers (Null Safety - Kotlin Program- ming Language 2018). Kotlin has been developed in collaboration with JetBrain (What is Kotlin? The Java alternative explained | InfoWorld 2018) team and therefore it is provided with useful tools and a well integrated IDE which is IntelliJ IDEA.

(21)

4 Methods & Analysis

4.1 Design a way to replicate it

Many Land Registry around the world are paper based. The properties are transferred only via wet signatures and streamline the process is more that an optimisation.

In these situations diﬃculties can arise in recognizing the real source of truth in case of discordant data or it easy to manipulate or counterfeit the information (Tamper-proof degree certificates to be India government’s first blockchain project 2018) (Sinha 2018).

Especially in non western world countries can be diﬃcult to sell properties simply because is not possible, or diﬃcult, to express the property over a particular land or building.

In some more developed countries the cadastre is digitalised and adminis- trated by governmental oﬃcers that are entitled to process transactions.

These platforms are closed and normal citizens are prevented from checking or changing information in those databases even if the operation they want to accomplish is legally correct: by intent and pro forma.

Even though the latter approach avoids debates among parties, it is known to be slow: with transactions that can last up to months.

In a blockchain environment, such operations can be performed within hours:

respecting the security and legal bounds that are required in order to prevent any kind of fraud.

Switching to a platform blockchain based implies to design a smart contract (comments 2018), a digital and automatic algorithm on the blockchain, that strictly follows the delicate procedures of a property conveyance and, even more important requires governments to accept and recognise the blockchain as a source of truth.

Any operation performed by real estate companies, private users or governmental oﬃcers must be done on the platform and in case of inconsistencies the digital record will be used as correct. It is in fact not possible to arbitrarily change one record (if not specifically allowed by the smart contract) thus, the change is a transaction, therefore will be recorded into one block and all the users can see the manipulation.

4.2 Current Technologies

The intent of this project is to write a contract that can integrate the interests of the real estate companies, that at the same, time can both satisfies the governmental requirements in matter of security and increase the level of the service provided to the citizens.

In such a described context, blockchain seems to be an optimal solution.

Postchain has been preferred because of its integration with standard SQL database system which encourages to run complex queries without the need of over specialized blockchain engineers and because of its flexibility and in- expensiveness of use (since it is private, transactions can be uploaded to the network at no cost).

(22)

4.3 Implementation phase

The requirements of the system:

Roles:

• Governmental Oﬃcer: Some governmental employee that needs to verify the correctness of the property and certify the data contained in the registration transaction. In particular, she has to be able to check if the data correspond to the one recorded in the current land registry.

• Lawyer: The lawyer is in charge to register new properties on the blockchain, she is responsible for the data written on the the system at the moment of the creation of new properties

• Owner: The owner of the property has to validate the data that regards the property and that have been validated by the governmental oﬃcer. She can fractionalize a mortgage and sell it in case she needs funds. Investors can buy such shares.

• Investor: Investors can buy shares. Each share promises a periodically percentage on the investment until discharge of the loan. Investors, after having bought a share, can resell it at arbitrary price.

Operations:

• Property registration: Lawyer, on premise of the owner of the property and the governmental oﬃcer, registers the property on the blockchain.

• Property validation (owner): The owner of the property explicitly accepts the ownership of the property on the blockchain. From this moment he is the master of the property’s operations.

• Create shares: The owner of one property can create an arbitrary amount of shares that bake the property itself (maximum number of shares must be equals to property’s value). She can set an interest on the shares that will be paid at a predefined and customizable period.

• Sell shares: The owner of the shares (created by the owner or previously bought by an investor) can sell to the investors on the market.

• Buy shares: Investors can buy shares, expecting a return defined by the interest set by the seller.

Escrow Payment: All the payment on the blockchain must be verified. Since there is no crypto currency involved in this project, the procedure is the following.The seller puts the shares on the market, and expresses the intention of receiving money in front guaranteeing with her property.

The investor accepts to buy the shares and to get back her money, in order to accept this risk, an interest is paid back monthly. In order to express her will, the investor reserves a certain amount of shares that are on sale.

(23)

At this point the seller contacts the buyer asking for the payment of the shares. The payment of the shares takes place oﬀ chain and therefore cannot be recorded. A recommendable procedure is via bank transfer.

When the payment takes place, the seller acknowledge the receipt of the money and transfer the shares to the investor that can potentially sell them again to other investors.

This is the most sensible part of the process since many of its steps happen oﬀ chain. A bank transfer facilitates in case of disputes because is traceable, is recognised as a muniment and it has an evidential matter in front of the court.

The blockchain can certify and record all the steps of the process in an ordered and time specific timeline and can be used as muniments itself in a process.

In a developed country this process must be preferred over a crypto currency transaction where the value of the currency exchange can be highly volatile and therefore increasing out of proportion the risk for the investors.

(24)

5 Implementation

Postchain smart contracts are coded directly into the blockchain itself. What happens is that a module is created and added to the nodes that participate in the network.

In this implementation the design requires two modules: 1. Flexible token (FT) (ChromaWay 2018) 2. shares (implemented).

5.1 Basic workflow

• Claim property on one asset.

• The blockchain (the system) acknowledges and accepts it.

• Once the owner has the right on the property on the blockchain, she can sell it (or fractionalise the property and sell the fractions - units).

• Users can oﬀer to buy some of the units.

• The payment can be processed both oﬄine or on the Blockchain.

• if carried out on the blockchain the transfer of the units happens immedi- ately and automatically.

• otherwise, the seller accepts the payment from the buyer and transfers the asset (units).

• the buyer has now the ownership on the units and can resell them.

5.2 User creation

5.2.1 Contract Registration

The lawyer is the entity designed to upload someone’s property on the blockchain.

The owner of the property must prove the ownership of the property itself via any kind of documentation. Once the documentation is revised and approved, through the governmental oﬃcer, the lawyer can fill the information that iden- tifies the asset along with the owner’s public key.

One important step of such operation is to verify that the owner possesses the keypair, as an alternative is possible to generate the keypair at the moment of the contract registration in case the owner does not have one yet.

Starting from this transaction, the owner can be considered liable for the property, even though she cannot operate any transaction yet (she needs to prove to have the control over the public key), but the land registry can use this information for tax purposes and title search.

5.2.2 Contract validation

The owner of the property with her keypair can send one transaction where she validates the property details on the blockchain. From that moment she can sell or create shares placing the property as an asset (securing the mortgage with the property).

(25)

Figure 1: Blockchain operations’ workflow diagram

(26)

5.2.3 Property segmentation

The owner, from the moment she is looking for funds, can divide her property value into shares and put them on sale at a given price and with some interest attached.

For the investors that will decide to buy such shares, they can expect a repayment with given interest on a regular base (which by default can be set to monthly, fortnight, yearly). If the payment does not take place in the time frame specified in the contract, the investors can suit the owner and prove through the blockchain that they didn’t receive the payment if so, the property can be seized.

Algorithm 1: createShares

Data: txId*, ownerPubKey*, contractId, interestRate, units Result: sharesExisting

begin

if !isInvestor(ownerP ubKey) or

!isAllowedT oSell(ownerP ubKey, contractId) or units  0 then exit

1 contract getContract(contractId);

2 sharesCreated amountOfShares(contractId);

if !sharesCreated then sharesCreated 0;

if sharesCreated + units > contract.value) then exit

3 assetId registerAsset(contractId, interestRate) ; f tU pdate(txId, ownerP ubKey, assetId, units); return sharesCreated + units

Algorithm The createShares function (Algorithm 1) receives as parameters the txId (derived by the blockchain core), the ownerPubKey (derived from the transaction signature), the contractId, interestRate and units specified within the transaction.

The contractId is the unique identifier of one property, the interestRate is the interest paid for the lend and units is the amount of shares that is going to be created.

The algorithm first checks if the signer is an investor, if the signer is the owner of the property and is authorized to sell, and a generic check to ensure that the number of shares is positive.

Then it infers the contract information from the contractId (1) and checks how many shares have been created with any interest rate (keeping in mind that the number of mnotes cannot be higher than the value of the contract) (2).

After having checked that there are enough shares available, it calls the reg- isterAsset function which returns the assetId (an unique identifier for contractId and interestRate).

The shares total is then updated through the creation of new tokens and the flexible token module.

(27)

5.3 Burn shares

The owner, and only the owner, of one contract can burn (destroy) shares, this operation can be done in case shares oﬀered on the market are not bought by interested users or in case the owner is able to buy-in the shares: which de facto corresponds to the discharge of the loan.

Algorithm 2: burnShares

Data: txId, ownerPubKey*, contractId, interestRate, units Result: sharesOwnedBySigner

begin

if !isInvestor(ownerP ubKey) or !isAllowedT oSell(ownerP ubKey) or units  0 then

exit

1 assetId convertAsset(contractId, interestRate) ; if !assetId then

exit

2 sharesOwned amountOfShares(ownerP ubKey, assetId);

3 sharesOnSale sharesOnSale(ownerP ubKey, assetId);

4 sharesReserved sharesSuspended(ownerP ubKey, assetId);

5 if sharesOwned sharesOnSale sharesReserved < units then exit

f tU pdate(txId, ownerP ubKey, assetId, units⇤ 1);

return sharesOwned units

Algorithm The burnShares function (Algorithm 2): if the signer is an investor, is allowed to sell, the units are greater than 0 and if the assetId exists.

Then the algorithm verifies if there are enought shares available to be burnt.

In order to burn a share it must be owned by the owner of the contract and nor on sale nor reserved (Annotation5).

(Annotation 1) convertAsset converts contractId and interestRate to assetId.

(Annotation 2) amountOfShares returns the total amount of shares owned by the given public key. (Annotation 3) sharesOnSale returns the number of shares on sale by the given public key. (Annotation 4) sharesSuspended shares owned by the given public key of a certain asset that have been reserved by one or multiple investors.

5.3.1 Sell shares

Once the shares have been created, they can be put on the market and sold.

At this stage the blockchain needs to make computation: while in the previous steps it was just about signing transactions and slightly changing the state of the blockchain, now proper checks must be made (Algorithm 3 ).

Shares can be oﬀered on sale several times (or even removed from sale) as long as there are enough shares available for the operation and they are not expired.

Algorithm The oﬀerShares function (Algorithm 3) performs some checks:

isInvestor, isAllowedToSell, the unitPrice is positive, the units to be put on sale

(28)

Algorithm 3: oﬀerShares

Data: sellerPubKey*, contractId, interestRate, unitPrice, units Result: signerSharesOnSale

begin

assetId convertAsset(contractId, interestRate) ;

if !isInvestor(sellerP ubKey) or !isAllowedT oSell(sellerP ubKey) or unitP rice  0 or units  0 or !assetId then exit;

sharesOwned amountOfShares(sellerP ubKey, assetId);

sharesOnSale sharesOnSale(sellerP ubKey, assetId);

sharesReserved sharesSuspended(sellerP ubKey, assetId);

if sharesOwner sharesOnSale sharesReserved < units then exit;

1 sharesOnSaleAtP rice

sharesOnSaleAtP rice(sellerP ubKey, assetId, unitP rice);

if !sharesOnSaleAtP rice then sharesOnSaleAtP rice 0;

1 insertOrU pdateOf f er(sellerP ubKey, assetId, unitP rice, sharesOnSaleAtP rice + units);

return sharesOnSaleAtPrice + units

are positive and the assetId exits.

The algorithm then verifies that there are enough shares available to be put on sale and then retrieves the number of existing shares on sale at given price, assetId and public key. If the record does not exist it returns nil and therefore it must be set to 0.

The insertOrUpdate function updates the record of items on sale with the new amount.

5.3.2 Remove shares on sale

Whenever the seller wants to withdraw some shares for any reason (e.g. she doesn’t need the loan anymore, no one is interested in buying, etc) can simply remove the shares from the listing.

Algorthm The removeOﬀeredShares function (Algorithm 4) performs the following checks: the seller is an investor, can sell shares, the units to be removed and if the assetId exists.

Then the total of shares on sale at the give price is retrieved and, if the amount of units to remove is lower or equal the number of shares on sale, is possible to either remove the record of shares on sale or either to update the record with the new number of shares on sale.

5.3.3 Reserve shares

Investors can access the marketplace which is hosted within the blockchain, and reserve shares at will. They express their will to buy shares signing a transaction

(29)

Algorithm 4: removeOﬀeredShares

Data: sellerPubKey*, contractId, interestRate, unitPrice, units Result: signerSharesOnSale

begin

if !isInvestor(sellerP ubKey) or !isAllowedT oSell(sellerP ubKey) or units  0 or !assetId then exit;

/* Get the shares offered at unitPrice */

sharesOnSaleAtP rice

getSharesOnSaleAtP rice(sellerP ubKey, assetId, unitP rice);

if !sharesOnSaleAtP rice or units > sharesOnSaleAtP rice then else if units = sharesOnSaleAtP rice thenexit

/* No sahres on sale at price, is possible to remove

the whole record */

deleteOf f er(sellerP ubKey, assetId, unitP rice);

else

/* update the new amount on sale */

insertOrU pdateOf f er(sellerP ubKey, assetId, unitP rice, sharesOnSaleAtP rice units);

endreturn sharesOnSaleAtPrice - units

that automatically reserve the desired amount from the market and notifies to owner.

Through an escrow payment procedure (described in 4.3) is possible to settle down the deal.

Algorithm The reserveShares function (Algorithm 5) allows inverstors to reserve shares that are oﬀered on the market.

In order to perform such an operation, is needed to check that the buyer is an authorized investor, the unitPrice and units are positive and that the assetId exists.

Then the amount of shares on sale at the requested price is retrieved and, if the units requested by the investor are lower or equal the shares on sale, is possible to reserve the shares.

The reservation is performed adding one record into a table. Each reservation is one row, while the other entities were deleted when not needed anymore, the reservation must be persistent and possible to track in case of disputes on court.

(Annotation 1) the creationTime is derived by the time the block has been mined, which is defined by the consensus of the nodes.

5.3.4 Manage reservation

When an investor makes a reservation, the owner of the shares gets notified.

Now the two parties can settle down the payment oﬀ chain.

(30)

Algorithm 5: reserveShares

Data: buyerPubKey*, sellerPubKey, contractId, interestRate, unitPrice, units, creationTime*

Result: sharesOnSale begin

if !isInvestor(buyerP ubKey) or unitP rice  0 orunits  0 or

!assetIdthen exit;

/* Get the shares listed at unitPrice */

sharesOnSaleAtP rice

getSharesOnSaleAtP rice(sellerP ubKey, assetId, unitP rice);

if sharesOnSaleAtP rice < units then elseexit

removeOf f eredShares(sellerP ubKey, contractId, interestRate, unitP rice, units);

1 insertReservation(sellerP ubKey, buyerP ubKey, contractId, interestRate, unitP rice, units, creationT ime, 0);

return sharesOnSaleAtPrice - units

In case the payment is successful, the owner transfer the property of the shares to the investor: completing the process. Instead, if the payment is not recognized as valid or it does not happen, she can simply refuse the reservation and then put the shares back on sale.

At the moment there is no blacklisting for investors. Since all the entities are verified and approved before allowing them the access to the system, it is safe to assume that they will behave in a neutral manner.

In the eventuality that some misleading behaviour takes place, it is possible to pursue the deceitful user both oﬀ chain (with a fine or legal process) both on chain (banning the user from the system or redistributing her shares).

Algorithm The manageReservation function (Algorithm 6) allows the owner and seller of the shares to accept or refuse one reservation. It makes the usual checks and then gets the older reservation that satisfies the given parameters (Annotation 1). It is decided to automatically return the oldest reservation in order to avoid malicious behaviours where the owner accepts the most recent reservation that satisfies the parameters: potentially highliting a misleading behaviour from the buyers that will have some old shares still suspended and to be paid. Ideally is better to show that the pending payments are the most recent ones, and (without this implementation) the buyer would have no option to express the will to pay the oldest pending order.

If the oﬀ chain payment has been performed, the seller accepts the reservation and the reservation record is updated with the decision wheter to validate or not the payment and the date and time the transaction occurred.

In case of conflicts both seller and buyer can use the blockchain as a proof in court.

(31)

Algorithm 6: manageReservation

Data: txId, sellerPubKey*, buyerPubKey, contractId, interestRate, unitPrice, units, accept, decisionTime*

Result: accepted begin

if !isInvestor(buyerP ubKey) or !isInvestor(sellerP ubKey) or

!isAllowedT oSell(sellerP ubKey) or !assetId then exit;

/* Get the oldest reservation with that parameters */

1 reservation

getOldestReservation(sellerP ubKey, buyerP ubKey, contractId, interestRate, unitP rice, units);

if !reservation then exit

if accept then accepted 1;

f tU pdate(txId, sellerP ubKey, assetId, units⇤ 1);

f tU pdate(txId, buyerP ubKey, assetId, units);

else

accepted 1;

2 updateReservation(reservation.id, accepted, decisionT ime);

return accepted

5.4 Automatic behaviour

At the time of writing, Postchain (as many other blockchain) is following the RPC (Remote Procedure Call) paradigm (ConsenSys 2015), therefore users must call a transaction in order to complete an operation.

(32)

6 Evaluation

Although the research question addresses the realization of a decentralized blockchain based solution for the management of the real estate market, providing the required security, reliability, fault tolerance and data symmetry in compare with the standard centralized solutions; it seems appropriate to first focus on the performance, scalability and security aspects of the blockchain solution itself before pointing the attention to the comparison of the two solutions (centralized and decentralized) in three diﬀerent scenarios. Eventually in this section, a discussion will be carried.

6.1 Performance

Since this thesis is evaluating the approach to undertake and the advantages and / or disadvantages of the blockchain solution, the speed of the system is not measured.

This is because the number of tps (transaction per second) can be highly variable given the diﬀerent blockchain and, accordingly to some specific blockchains (e.g. Ethereum) the budget available to run the transaction. It is possible to state that in Corda there is a limit of around 170tps (Ward 2018), up to 50000tps on EOS (Year 2017), postchain 190-500tps (internal source) and between 10-30 tps on Ethereum (What’s the transaction-throughput on Ethereum (how fast the nodes can replicate transactions, not transactions per second) 2018). The logical implementation, instead, remains the same.

Of course some operations described in this work are not available in some blockchains or can be harder to code as, for example, the key-value store in Ethereum which has a non-trivial implementation even for experienced developers and requires the implementation of other blockchains as a support. Al- ternatively, it is possible to fallback to centralized solutions that might not compromise the security but can potentially lose track of the data (e.g. (Ora- clize - blockchain oracle service, enabling data-rich smart contracts 2018)). As an example, storing the reference of an object on a centrally owned database can lead to the loss of the reference but, in case of misleading response from the database, it is still possible to verify the correctness of the information: leading to a situation where the contract is de facto useless. Thus, since the blockchain cannot query an external source, this must be inserted before the creation of the transaction, creating another layer of complexity.

Having a benchmark on mortgage registration between the standard centralized solution and a decentralized blockchain solution would therefore be not correct given the fact that at the moment there isn’t a standardized and available software procedure but rather a human based procedure. Automatizing the process provides flexibility and decreases the time needed in order to issue a mortgage but not its absolute speed, meaning the performance, which is given by the underlying blockchain technology used in a specific configuration.

The software described works in virtually any Turing complete blockchain (or even not, ideally) therefore the workflow is not bound to any specific product.

For completeness it has been implemented on Postchain where it is able to reach nearly 180tps. Such tps is not even a real concern since the markets do not usually process those many transactions: in the USA as a whole in 2014 (The Home Mortgage Disclosure Act 2018) there have been roughly 5

Applied design of distributed ledgers for real estate and land registration

Applied design of distributed ledgers for real estate and land registration

RICCARDO SIBANI

Contents

1 Introduction

1.1 Background

1.2 Problem

1.3 Purpose

1.4 Goal

1.5 Delimitations

2 Literature review

2.1 Peer To Peer

2.2 The need for decentralization

2.3 Real Time Applications

2.4 Blockchain

2.5 Note to the reader

2.6 Assets on the Blockchain

2.7 Property Management

3 Theoretical Background

3.1 Postchain

3.2 Flexible tokens

3.3 PostgreSQL

3.4 Kotlin

4 Methods & Analysis

4.1 Design a way to replicate it

4.2 Current Technologies

4.3 Implementation phase

5 Implementation

5.1 Basic workflow

5.2 User creation

5.3 Burn shares

5.4 Automatic behaviour

6 Evaluation

6.1 Performance