Tokenizing Commercial Property With SmartContracts

Chad Fernandez1, Stefan Hickmott2, and Alex Norta3

1 Blockgemini.com, UABchad@blockgemini.com

2 Evarei and Evareium, Downtown Dubai, UAEinfo@evarei.com

3 Large-Scale Systems Group, Tallinn University of Technology, Estoniaalex.norta.phd@ieee.org

Abstract. Trading commercial property currently involves several mid-dlemen who are extra time-consuming and cost-consuming elements in atransaction. With recent blockchain-based smart contract innovations, itis possible to use distributed applications (Dapps) for disintermediatingthird parties and enabling direct peer-to-peer (P2P) transactions. Theblockchain serves as an immutable, event-recording ledger that facilitatestrust-less P2P transactions. The Evareium system is a distributed ap-plication for enabling blockchain-based commercial-property trades thatmake middlemen superfluous and consequently, investors benefit from costreductions, faster transaction times, greater transparency and reducedregulatory burdens. As a consequence of the Evareium system, investorsand other stakeholders are able to avail a direct interface with the cre-ation and dissemination of optimal financial gains from such investmentswithout interdiction. The corresponding Evareium token is structured forgoverning platform-related incentives. Besides actual commercial-propertytrades, that also comprises disruptive customer services such as online-travel agencies, smart leasing, and P2P homestay market-place functions.Furthermore, the Evareium token is also intended for Internet-of-Things(IoT) based hotel-management services such as controlling hotel-roomblindfolds, A/C, smart keys, checkin, spa, restaurant, room service, and soon. We demonstrate the utility of the Evareium platform with a runningcase that assumes Dubai as the commercial-property focus. The paperalso discusses rapid deployment options in that pre-existing blockchain-solutions are considered to cover respective parts for implementing theEvareium architecture.

Keywords: Commercial property, tokenize, real-estate investment fund, smartcontracts, blockchains, institution retail investors

1 Introduction

Commercial property trading is plagued by being an inherently illiquid asset classinvolving many hidden costs, regulations, middlemen and a lack of transparency.

2

In a recent study [5], blockchain-based smart contract solutions are mentionedas a remedy for enabling disintermediated peer-to-peer (P2P) transactions thatallow investors to save costs and time while being less burdened with regulations.

With the advent of blockchain-based smart contracts [36], a trend emergesfor establishing disintermediated collaboration structures [13] to engage in theformation of P2P transactions. Briefly, a smart contract is a computerizedform of transaction protocol [35] that carries out terms of contracts. Thus,blockchain techology [28] is suitable to achieve immutable even-tracking of acommercial property transactions and event-tracking. A blockchain is comparableto a distributed database that independently verifies artifact-ownership chains [24]cryptographic digests create in hash values. To additionally support electronicP2P-transaction platforms, the emergence of service-oriented cloud computing(SOCC) [1] promises an, ad-hoc integration and coordination of information-and business-process flows [21, 22] to orchestrate and choreograph commercialproperty trades.

The state of the art shows that technologically it is possible to create P2P com-mercial transaction platforms that eliminate cost-creating and time-consumingintermediaries and obsolete stage processes. This paper fills the gap by answeringthe question of how to provide a smart-contract/blockchain based commercialproperty trading and value-chain platform that avoids disintermediated middle-men for enabling P2P trades with low costs and optimized time consumption. Toestablish a separation of concerns, we deduce the following subquestions; Whatare the system requirements for P2P commercial property trading- and holdings?What is the architecture of this trading- and holding platform? What is thedynamic stakeholder-engagement behavior within the platform?

The remainder of the paper is structured as follows; Section 2 presents a run-ning case about the status quo and larger context of Dubai commercial propertytrading. Note that the problem of costly and time-consuming intermediaries iscurrently global and not limited to Dubai, UAE. Next Section 3 gives functional-and quality requirements for the trading platform together with a positioning ofstakeholders in that spectrum of requirements. Section 4 describes the trading-platform architecture we derive from the requirement sets and Section 5 describesthe dynamic engagement behavior of stakeholders that result in immutable eventrecordings in the trade-supporting blockchain. Section 6 gives an evaluation ofrapid deployment feasibility by checking which pre-existing blockchain systemsare available for an instant implementation of the commercial property tradingplatform. Finally, Section 7 concludes the paper and gives limitations, open issuesand future work.

2 Motivating Example and Preliminaries

We introduce in Section 2.1 a real-life running case about the commercial propertymarket status quo in Dubai. Note that the condition in Dubai of includingintermediary processes and entities, time- and money-consuming regulations are

3

rather universal. Next, Section 2.2 gives additional background preliminaries tocomprehend the running case better and also to understand subsequent sections.

2.1 Running Case

Too many institutions and companies act as intermediaries between investorswho want to purchase real estate, while in the advent of blockchain, many ofthese middlemen add no fundamental value in the process. As Figure 1 shows,banks, pension funds, and other real estate intermediaries take a percentageof the overall funds under their management; although owned ultimately byinvestors and the general public. Moreover, these institutions decide unilaterallyhow to lend and invest it, keeping in many instances a large proportion of all theprofits and gains for themselves. In addition, property developers pre-selling realestate units are often able to mask the profit the investor could really generate insuch a project, and instead keep it for themselves. Note that property developersuse the investors money to fund the entire project and are in doing so takingmarginal-, or no meaningful financial risk in the development process accordingly.

single investors

Large Holding Companies

Family O ces Institutions

administration and accounting

fund managers

Regulatory Hurdles

Fig. 1: Status quo in commercial property trading.

In the case of Dubai, over USD 400 billion of real estate has been developedin the Emirate and the surrounding Gulf Cooperation Council (GCC) regionsince 2001 of which a substantial majority has been pre-sold, off-plan real estate.This business model is a disadvantage for investors since they are required to paythe real estate company building the project over a series of installments thatthe developer then uses via an escrow arrangement to fund the project. Thus,developers use the investors money to build the entire project and retain a largeprofit margin in the project for themselves. More precisely, the developer givesthe buyer a real estate unit that requires approximately 3 years to build andyields 5-8% (gross yield i.e. before service fees, community charges, maintenance

4

costs and where applicable, taxes) for the owner after construction completion,whilst the developer has profited substantially from the investors’/consumersfunds. This peculiar interrelationship between the developer and investor wherethe developer is being largely funded by the buyers in the role of investment, yetis being treated contractually and economically as a consumer of the finishedproduct that their funds then create is one that is practically unique to thereal estate sector as an asset class, and where Evareium considers there to bevast opportunity for regularization. Additional single-owner problems in the real-estate sector are compounded by such factors that include the costs, risks andtime spent renting the property, collecting rent, maintaining the property, payingservice charges, settling disputes, etc. Furthermore, if an owner wants to sell aproperty, perhaps the most significant disadvantage of real estate investment canbecome apparent in that it might take months to find a buyer at the desired price;consequently, real estate is notoriously an inherently illiquid form of investment,even though it is by far the most favored type of substantial personal investmentin the region today.

2.2 Background Preliminaries

For the running example in Figure 1, we assume that commercial propertyis upgraded with Internet-of-Things (IoT) [42] devices for turning into smartbuildings [40]. Briefly IoT is a network of sensor devices, home appliances, withembedded software and network connectivity to enable data exchange. The IoTdevices act autonomously and comprise sensors for processing contextual events,actuators to project actions to an IoT-device context, a knowledge base and aninternal controller for reasoning.The advantage of establishing smart buildingsare several. For example, using smart keys [20] allows for managing access rightsto apartments, energy consumption [44] can be optimized, security provision [18]can be tightened, and so on.

We present next the methodology employed in subsequent sections and thepresentation of the Evareium system following a model-driven design (MDD)methodology [4]. MDD focuses on a system-design process that results in fastimplementation deployment. Thus, we present a series of models that providean increasingly deeper understanding of the static and dynamic features ofthe Evareium system. Thus, we first employ a goal-model [34] to describe therequirements of the system, second a UML component [23] diagram to outlinethe static architecture, and finally a UML sequence diagram to illustrate thedynamic behavior of the system that stores key events in the blockchain.

Goal models as part of the agent-oriented modeling (AOM) method [34] isused to specify the requirements of the Evareium system. AOM goal modelscomprise the simple notation in Figure 2 (a) to specify the functional goals of asystem, ‘quality goals’ or non-functional requirements, and agents with specifiedroles that may be human or artificial.

The root of a hierarchically decomposed AOM goal model is a ‘value proposi-tion’ depicted as a functional goal that denotes the overall systems goal. Attached

5

Fig. 2: Icons of AOM goal-model notation in (a), UML component diagrams in(b) and UML sequence diagrams in (c).

to functional goals are quality goals and roles. Note that attached quality goalsand roles also hold for lower-level functional goals.

From the goal model we deduce a UML component diagrams [6] to specifystatic structure of the Evareium system. Figure 2 (b) depicts UML notationelements with components being labeled rectangles. The latter can be furtherrefined with sub-components and have attached provided- and required interfacesFigure 2 (b) depicts as a line with a circle and required interfaces are lineswith a cup at the end. Actors indicate how components interact with differentstakeholders and are comparable to roles in goal models.

To express the dynamic behavior of the Evareium system, we use UMLsequence diagrams [33]. Figure 2 (c) shows two entities with the labels Agent 1and Agent 2 with dashed timelines emanating vertically downwards. Directedstraight arrows show messages between the depicted entities and the bars are so-called activations that denote processing threads. Dashed directed arcs betweenentities are return messages that yield back processing control Note that theactivations of an entity may act asynchronously too.

By taking an MDD approach, we describe the distribution aspects [37] of theEvareium system. Furthermore, the rise of IoT, or cyberphysical systems (CPS)[31] is essential for creating smart commercial property [17] that allows for detailedaccess control, cost-saving energy monitoring, enhanced security provisions, andso on. CPS sets of smart objects that are internet-integrated, e.g., IoT-devices,that cloud applications [32] may orchestrate for processing complex tasks. Thus,CPS enable system-to-humans engagement via diverse means [3] that integratecomputational and physical capabilities. With respect to blockchain technology,the Evareium system relies considerably on smart-contract technology for assuringdistributed event traceability and security. The decentralized consensus findingfor blockchain transactions is essential for which proof-of-work (PoW) [38] iscurrently the dominant example in which computationally intensive puzzles mustbe solved.

6

Ethereum [41] is the de facto smart-contract standard with several acknowl-edged drawbacks. For example, PoW transactions are computationally expensiveand energy consuming. Consequently, Ethereum is a problematic choice for in-dustry applications that require fast consensus finding at low cost. Furthermore,the Solidity smart-contract programming language of Ethereum has no formalfoundation and thus, can not be verified [11] with algorithmic tool support be-fore enactment. Proof-of-stake (PoS) [10] is a more suitable option for smartcontracts [15] together with blockchain sharding [26].In PoS, the choice of a newblock creator deterministically happens depending on its wealth, i.e., the stake.Sharding leads to the partitioning of a blockchain into smaller parts that can bemanaged faster.

3 Requirements for Automated commercial propertyTrading and Holdings

The AOM method [34] is employed for defining the Evareium-system requirementsas it is a socio-technical approach to model dynamic and complex distributedsystems comprising human and software agents. We provide the overall goalmodel in parts where Section 3.1 shows the value proposition together with thefirst refinement level. Section 3.2 describes the partial goal model of the threeleft-side decompositions and Section 3.3 comprises the right-side goal refinements.

3.1 Value Proposition

The center of Figure 3 is the value proposition of the Evareium system withthe label of business-to-business (B2B) crowdfunding platform investing in com-mercial real estate at the base level, automating transparency and structuringthe operating entities to benefit retail investors. Hierarchically, below is thefirst refinement level of functional goals, namely, crowdsourcing pool of funds,Evarei fund management of fund distribution and resource allocation, propertyprofile management, decentralized leasing platform for property managementand stakeholder integrations, a dynamic synchronization of auction-pool- andproperty exit. Note that all these refining goals we explain in the subsectionsbelow in further detail.

Connected to the value proposition in Figure 3 are a set of quality goals thathold for the entire Evareium crowdfunding platform. Strategic pertains to anincentivized model that all stakeholders in the hierarchy inherit, enabling investorlong-term investment decisions to be optimally met.

Secure [2] must hold for the entire system and is further decomposed into confi-dentiality, integrity, and availability. Confidentiality is the absence of unauthorizedinformation disclosure. Integrity is the absence of improper system alterations andavailability the readiness for correct service provision. Security is an impeccablecore component for the system to thrive and maintain integrity, which inheritconfidentiality and availability. The absence of unauthorized information is a keycomponent to providing indefinite integrity. Seamless as a quality goal for the

7

Fig. 3: The value proposition and first refinement level of the Evareium goalmodel.

Evareium system stands for the precise allocation of integrable information ex-change between external and internal platform infrastructures. Adjacent systemsof stakeholders allow realtime stakeholder status and definitive management ofprocess flow. Direct denotes P2P engagement between stakeholders, digitizinginteractions which normally require in-person, or third-party authentication thatwould considerably increase turn over time and human resources. Liquid pertainsto the platform providing at all times sufficient funding for commercial propertyinvestment. Verifiable pertains to critical transactions on the Evareium platformbeing recorded on the blockchain(s) as immutable evidence. Finally, mutablemeans system settings of the crowdfunding platform are changeable based oncommercial property trading needs.

The first refinement level under the value proposition also has quality goalsattached. Decentralized and transparent do not hold for all lower-level functionalgoals and are therefore selectively assigned. Decentralized stands for collaborationtaking place in a P2P way without any component of orchestration concentrationtaking control of communication channels. Transparent pertains to transactionsand communications between parties being traceable for other system stakeholders.This is achieved by logging key events in the blockchain.

The functional goal of property profile management has the quality goalassured linked to indicate that it is certain that provided stakeholder and com-mercial property data is based on evidence and truthful. Also the functional goalof auctioned property exit links to a separate set of quality goals. Incentivizedmeans that stakeholders are encouraged by the Evareium system to engage andtransact. Thus, closely related is the goal of profitability meaning that commercialproperty auction exits result in a financial gain. Finally, stable pertains to the exittransaction being constant and as such, stored in the blockchain in an immutableway.

8

Figure 3 also shows roles attached to specific functional goals who are respec-tive stakeholders in the Evareium system. The technology partner is associated tothe functional goal for crowdfunding management and indicates that third partiesare integrated in the platform for their complementary technological serviceprovisions. Evarei as an organization also actively involves itself in crowdfundingmanagement that additionally requires a developer for its establishment anda committee too. Evarei is also involved in the management of profile man-agement. A real-estate broker takes care of leasing the commercial propertytrading platform. Finally, a decentralized autonomous organization (DAO) [29]is orchestrated via business rules such as obligations and rights that are encodedas machine-readable smart contracts. Figure 3 associates a DAO role with thefunctional goals for creating an auction pool and the auctioned property exit.

3.2 Left-Branch Goal Refinements

The refinements in Figure 4 pertain to the left three goal branches below the valueproposition. Note that the quality goals and stakeholders on higher hierarchy levelsalso hold for lower-level functional goals. As the functional goal for crowdsourcingthe pool of funds is explained in Section 3.1, we next address its refinements.Figure 4 shows as a refinement the functional goal for accepting investmentsthat are split up yet again into the functional goals for investor-profile-, andreward-system management. The latter goal shows a further functional refinementfor loyalty program management. Besides the set of inherited quality goals,only reward-system management has an extra quality goal associated for costeffectiveness. Thus, the latter goal also holds for the loyalty-program management.

With respect to roles, the functional goal for accepting investment has indi-rectly associated the investor into commercial property and Evarei as the receiverto take on investment management. Furthermore, a renter and reward partnerare associated to the functional goal of reward-system management, meaningthat these roles are receiving parties from Evarei. The renter and reward partnerare consequently also benefiters of the lower-level loyalty program.

The functional goal in Figure 4 for Evarei crowdfunding management has,as a refining functional goal, the distribution of EVM token investments. Thelatter is further refined with the functional goals for smart-building investment,grant voting rights, grant polling rights and the integration of goods- and servicepartners. Smart building investment pertains to upgrading commercial propertywith IoT technology such as smart keys, energy-optimizing devices, additionalsecurity measures, etc. For such costly upgrades, voting and polling is necessaryto assign funding means with EVM tokens. Consequently, it is possible to sourcein goods and services for upgrading commercial property to smart buildings.

The associated quality goal to the distribution of EVM token investments andlower-level functional goals being of medium- and low-risk means the upgradingof commercial property to smart buildings without the likelihood of experiencingfinancial distress. Finally, extra associated roles are the investor to the functionalgoal for distributing EVM token investments and a reward partner is associatedwith the goal of goods- and service-partner integration.

9

Fig. 4: First partial goal-refinements of the Evareium system.

The right most refinement branch of Figure 4 for the functional goal ofproperty profile management has several refinements too for showing certificationof property, fund-progress tracking, showing the occupancy statistic, locking inproperty investment and maintaining a news portal. Furthermore, the showing ofthe occupancy rate is refined with the functional goal of bed and breakfast (BnB)smart leasing. Note that EVBnB leasing enables the lease, or rent of short-termlodging in commercial property. Smart leasing means, e.g., that an organizationrenting commercial property is able to gain access via the smart key.

With respect to additional quality goals, the EVBnB leasing and the locking inof property investment must be profitable. Additionally, the latter functional goalmust also be leveragable in that funds can be invested with borrowed money as away to amplify potential gains. Also the maintenance of the news portal shouldbe social in that all involved stakeholders are able to post relevant contributionsand openly discuss them in blogs.

Additional assigned roles are a third party and a developer who are associ-ated to showing property certifications. We assume third parties may be, e.g.,public-service organizations that check if commercial property stakeholders havethe required certifications for conducting business. Furthermore, investors areassociated to the functional goals for fund-progress tracking and showing oc-

10

cupancy statistics for commercial property. A renter role is associated to theEVBnB smart leasing functional goal.

Finally, the goal model in Figure 4 depicts gray-shaded areas that encompassrespective areas of the goal models to show the application of Evareium tokens(EVT). The latter is comparable to gas in an Ethereum smart-contract system andintended purely for the use and support of the Evareium platform. Stakeholdersof the latter hold EVT for engaging and transacting in commercial propertytrades and have an interest in the appreciation of EVT.

3.3 Right-Branch Goal Refinements

The right-hand refinements in Figure 5 show three functional goal branches withthe first we explain being for leasing the Evareium platform. Lower-level functionalgoals are for broker registration, profile creation, tenant registration, the creationof ratings and rankings and the external investor property management. All thesefunctional goals are decentralized and transparent while in addition, the goals forbroker registration, the creation of ratings and rankings and the external investorproperty management are meant to be incentivized as an associated quality goal.Thus, both functional goals should involve third parties and realestate brokers ina way that financial benefits result for them. Finally, an additional role being athird-party investor is involved in the functional goals for the creation of ratingsand rankings and the external investor property management. The latter role’srespective functional-goal involvements are also supposed to be incentivized.

Fig. 5: Second partial goal-refinements of the Evareium system.

11

The auction-pool creation branch in Figure 5 is refined with the functional goalfor performing a property trade with the latter being again refined by determiningthe voting period, showing success parameters, comparing the performance ofproperty trade with real-estate investment trust (REIT) benefits and finally,the actual democratic vote. Note that additional quality goals are associated tothe property trade being incentivized and profitable, which intersect with eachother. Further associated roles are an EVMREIT investor who is involved indetermining the democratic voting period for a property trade. Also the DAO isinvolved in lower-level functional goals and Evarei is involved in comparing theREIT benefits. Note that both functional-goal branches for leasing property andcreating auction pools also partially involve EVT due to their decentralized andtransparent nature.

The last most right-hand branch of Figure 5 has, for auctioned property exit,the direct functional refinement goals of the purchase of auctioned properties,generating an EVMREIT fund whose proceeds will be reinvested into EVMEvareium. The functional goal for generating an EVMREIT fund is furtherrefined with swapping the EVMREIT, dividend payments and confirming a bidon an auctioned property. Additional quality goals of being predictive and lowrisk are associated to generating EVMREIT funds, meaning they also hold forall refining functional goals. Thus, the process of swapping dividends and tokensshould have certainty without experiencing any financial loss. Finally, additionalroles are associated to the functional goal of purchasing auctioned property beingthe EVMREIT investor and Evarei. A stock-exchange investor is associated tothe functional goal of dividend payments and an EVM investor is associated toswapping funds into EVMREIT and reinvesting into EVM Evareium.

4 Architecture of the Trading Platform

For the Evareium system, we next deduce a component architecture in which thefocus lies on arranging the components and specifying the provided and requiredinterfaces of components. Furthermore, we also show the relationship of rolesin Section 3 the component interfaces that translate in a distributed systemimplementation to a set of given application program interfaces (API) that allowsactors to interface, e.g., with mobile devices.

The remainder is structured as follows; Section 4.1 describes the mappingprocedure from Evareium goal models to the component diagram in Figure 6.Next, Section 4.2 describes in detail the Evareium architecture with a specificfocus on provided and required interfaces between them.

4.1 Mapping Approach

The architecture for the Evareium system in Figure 6 we derive from the goalmodels in Section 3. Thus, the top-level refinements correspond to the first-levelfunctional goal refinements of Figure 3. The embedded components equate thesecond-level goal model refinements from Figure 4 and 5.

12

Fig. 6: The Evarei component diagram derived from earlier goal models.

The roles from AOM goal models map onto so-called actors in the case ofcomponent diagrams while they are depicted as sticky men in both cases. Given theposition of roles in goal models, it is possible to assign the actors in the componentdiagram correspondingly to provided-, or required component interfaces. Thedifference in assumption with respect to relating actors to interfaces in Figure 6is that provided interfaces allow an actor to draw information from a component,while required interfaces serve for actors as means to input information into acomponent.

4.2 Component Model

The crowdsourcing pool component at the top left in Figure 6 has an embed-ded component for investment management. We omit refinement beyond firstrefinements levels in the architecture due to space limitation. Note the dashedgray box denotes EVT use correspondingly with the goal models in Section 3.These components have several provided- and required interfaces.The embed-ded investment management component has a providing interface that delivers

13

the Evarei actor with investment information. The providing interface receivesinvestment information from the investor actor. The top-level component forthe crowdsourcing funds pool also has a set of interfaces with a providing onedelivering profile information of investors to the Evarei actor. A correspondingrequired interface exists for the investor to deliver profile information. Finally,two providing interfaces deliver investment- and profile information to the nextcomponent for Evarei crowdfunding management. Simultaneously, the crowd-sourcing funds pool also has receiving interfaces that connect to the componentfor auction exit management, which we address in the sequel. Note that thedata-exchange labels in Figure 6 are conceptual placeholders for data exchangessignificantly more complex than we are able to express in the depicted top-levelarchitecture.

The Evarei crowdfunding-management component at the top right of Figure6 comprises a contained EVM token-management component that is gray-shadedto express EVT are applied on the first refinement level, while EVT are notapplicable on the top-level per se. The only required interface of the EVMtoken-management component allows investors to authorize corresponding fundmanagement. The remaining interfaces are connected to the Evarei crowdfunding-management component with only one being required so that a committeeis able to submit certifications about commercial property. Out of the otherproviding interfaces, three allow for stakeholders to engage, i.e., the Evareiactor receives EVM tokens, the third technology partner and property developerreceive investment information. The remaining two providing-interfaces deliverinvestment- and certification information to the component for property-profilemanagement. Finally, a committee delivers valid certificates for commercialproperty via a receiving interface.

The latter comprises refining components in correspondence with the goalmodel of Figure 4. Note that EVT are employed in the components for thecerification database (DB), the statistics calculator and the property investmentDB. The components for fund-progress tracking and the news portal do notrequire EVT. Two interfaces receive investment and certification informationwhile the third receiving interface has the Evarei actor deliver updates aboutthe property management. The remaining providing interfaces of the property-profile management deliver to the platform-leaser component certification, profile,property and statistics information.

The platform-leaser component in the center left of Figure 6 has first-levelrefinement components termed registration manager, ratings and rankings andexternal investor property manager. A third-party actor receives platform informa-tion while he delivers EVT for leasing property. The same holds for the realestatebroker actor and renter in Figure 6. The renter receives platform informationfor leasing and submits in return EVT. The remaining providing interfaces ofthe platform-leaser component deliver information to the auction-pool managercomponent about property leasing and validating certificates.

The auction-pool manager at the bottom left of Figure 6 employs EVTtogether with the platform leaser. The contained property-trader component is

14

the first-level architecture refinement in correspondence with the goal managerof Figure 5. Besides two required interfaces for receiving information aboutproperty leasing and certification validity, a third providing interface allowsDAOs to deliver auction parameters and EVT. The DAO receives via a providinginterface auction information while the remaining two providing interfaces deliverinformation for property leasing and auction requests to the auction-exit managercomponent.

The auction exit manager component at the bottom right of Figure 6 is thecommercial property lifecycle sink. Note that the functional goals in Figure 6democratic voting and determine voting period, we merge into a first-refinement-level component termed voting manager. Also the functional goals for generatingEVMREIT funds and for reinvesting into EVM Evareium we merge into a com-ponent for EVMREIT fund manager. The final refining component is a propertypurchase manager that has attached a providing interface so that the Evareiactor can withdraw fund-ownership information. The second providing interfaceof the property purchase manager component allows EVMREIT investors todeliver information about token allocations and business intelligence. The refiningEVMREIT fund manager component has providing interfaces for allowing theEVMREIT investor to withdraw platform information and also the stockex-change investor is able to withdraw dividend information. For the latter, thestockexchange investor must deliver know-your-customer (KYC) information.Finally, on the top level of the auction exit manager component, besides receivinginformation about property leasing and auction requests via required interfaces,the DAO receives concrete exit information via a providing interface. Finally,generated business intelligence together with reinvestment and profit distributionis channeled back to the top left component termed crowdsourcing funds pool tosupport the next commercial property deal.

5 Dynamic Stakeholder Engagement

We describe and specify the dynamic behavior of the Evareium system withUML sequence diagrams [33], following the notation of Figure 2(c). The sequencediagrams show data-exchange protocols and data services between roles with thecomponents described in Figure 6.

The remainder is structured as follows. Section 5.1 lists the blockchain op-erations for achieving event traceability for commercial property trade. Section5.2 gives the dynamic behavior during crowdfunding management. Next, Section5.3 describes the management of a property profile and Section 5.4 explains theleasingplatform protocol. Finally, Section 5.6 shows the creation of an auctionpool and exit.

5.1 Blockchain Operations

Storing operations of events on blockchains is costly with respect to transactionfees and consumed computing power. Note that PoW to solve cryptographic

15

riddles for transaction validation, is a performance and scalability bottleneck forhighly distributed systems such as Evareium. Thus, as outlined in Table 1, it isimportant to know the minimal set of transactions for the required traceabilityin the Evareium property trading system.

Table 1: Blockchain transactions for the Evareium system.

Table 1 lists the operations with the event, column giving identification num-bers of respective blockchain operations. Additionally, we also list the stakeholderset per operation and a corresponding explanation per operation. The first columncategorizes the operations into subsets that are assigned to respective componentsfrom Figure 6. Note the event IDs we use below in the sequence diagrams are toshow at which moments in the protocols the blockchain is used.

5.2 Crowdfunding Management

The sequence diagram in Figure 7 depicts as UML entities the components andactors depicted in Section 4.2. Note the use of pseudo-code commands for themessages between the entities that suffice to demonstrate the dynamic protocolbehavior. The numbered red dots correspond to the blockchain-operation eventsin Figure 1.

The investor in Figure 7 commences with a push(profile) message to the crowd-sourcing funds pool, which is an event that is immutably stored in a blockchain.Next, the investor sends investment information to the investment managementcomponent, triggering another recording in a blockchain. Next, Evarei requests

16

Fig. 7: The Evareium protocol for crowdfunding management.

profile information from the crowd-sourcing funds pool together with investmentinformation to check for clearance that results in a third blockchain operation.

The crowdsourcing funds pool then notifies the Evarei crowdfunding manage-ment component to generate a prospectus based on the profile and investmentinformation. The prospectus is sent to the technology partners and the developerwho turn the commercial property into smart property by means of intelligentIoT devices. There is a committee to perform a final check of the prospectus,project time the technology partners and developer submit, and the final budget.The committee-approved prospectus is sent to the EVM token managementcomponent and finally the EVM tokens are passed on to Evarei for concludingthe crowdfunding-management protocol.

5.3 property profile Management

In Figure 8, the sequence diagram for property profile manager shows that Evareisends to the property profile management information about the investment inv,the valid certificate val and the prospectus pros. The property profile managementpasses the information on to Evarei with a request to check the entire profile tosend back a possible update. Next, the property profile management sends theprofile to the certifications database CF DB that in turn forwards the profile tothe developer for a check. The latter entity returns its own certification cert1,after which the CF DB also requests a certificate cert2 from the third party.

17

Finally, the CF DB also requests a profile check from the committee that returnsa gameplan for the commercial property.

Fig. 8: property profile management sequence diagram.

The remainder of the sequence diagram in Figure 8 shows a protocol thattakes place in a loop. Thus, the committee send the investment information to theentity for fund progress (FP) tracking. The latter in turns forwards the investmentinformation again to the statistics calculator and the investor performs a checkif that investment for which statistics stats details are returned. Finally, alsithe property-investment database PI DB receives valuable statistics for decisionmaking.

There exist blockchain transaction in Figure 8 that carry the numbers from 3to 8 in correspondence to Table 1. The EVM token distribution 3 is stored inthe blockchain when the developer receives the profile for a check and when thesame check happens later by the committee. Subsequently, the developer andthird party create certificates that trigger blockchain Transaction 6 to store theseevents. Once the gameplan returns from the committee to the CF DB, blockchainTransactions 4 and 5 are triggered for recording smart-building investment deci-sions, followed by goods- and servicepartner integration respectively. Finally, inthe loop, Transaction 7 for the quarterly fund-progress tracking and Transaction8 for locking in the property investment.

5.4 Platform Leaser

The sequence diagram in Figure 9 starts with the platform property manager(PPM) dispatching the valid certificate cert, profile prof of the commercial

18

property prop and related statistics stats. Next, the platform leaser registers thebroker, profile and tenant with the registration manager who then subsequentlyalso receives registration information from the third party, realestate broker, renter.The component for external investor property management EIPM receives theaccumulated registration information.

Fig. 9: The Evarei leasing-platform sequence diagram.

The depicted loop in Figure 9 by a rounded rectangle denotes that the leasingprocess is repetitive and involves the renter, realestate broker and the third party.In order to make their respective leasing, these stakeholders use EVT. Finally, adashed rounded rectangle denotes that the last part of the protocol in Figure 9 isoptional. Thus, the EIPM puts forward a service offer to a third party, e.g., fordelivering commercial property statistics to the third party. Assuming the latterconfirms the service offer, the EIPM requests relevant statistics for a specificongoing leasing context to the component for generating ratings and rankings.

19

The received information, the EIPM then dispatches to the third party, realestatebroker and renter for educated decision making.9

Several blockchain transactions are depicted as red circles in Figure 9 num-bered from 9 to 15 in correspondence with Table 1. In Transaction 10, theplatform leasing details are stored in the blockchain. Also the registration of thirdparty, realestate broker and renter are stored in the blockchain with Transactions11 to 13 respectively. For the EVNBnB smart leasing in the loop of Figure 9, theconcrete leasing events Transaction 9 stores in the blockchain. The optional finalpart of the leasing protocol stores with Transaction 15 the fact that a specificservice offer is confirmed by a third party. Also the distribution of the statistics bythe EIPM are stored as to then have evidence for service provision compensation.

5.5 Auction-Pool Management

The platform leaser in Figure 10 pushes information about the commercialproperty prop and the valid certificate certval to the auction pool management(APM). The latter then sends an auction request req to the DAO who setsimportant auction parameters param and sends them to the APM. The propertytrader receives from the APM a command to commence with the auction, afterwhich the DAO and investor are informed about the suggested time the votingperiod lasts. We assume the DAO and investor confirm the suggested votingperiod. Alternatively, in the case of disagreement a negotiation period starts thatwe omit in the protocol for sake of brevity.

The DAO and Evarei receive from the property trader success parameterssuccpara for the pending auction and REIT information too. Subsequently, theproperty trader issues a vote request and in a loop, the DAO and investor castvotes repetitively as long as the auction period lasts. Once the period terminates,only the last vote closest to the end counts. The property trader distributesthe vote result to the DAO and investor, after which a commercial propertyhandover to Evarei takes place. The latter informs the APM who then concludesthe auction pool-management protocol.

Again, the protocol in Figure 10 employs several blockchain transactions withthe numbers 16 to 19 in Table 1. Transaction 16 records in the blockchain themoment of creating the auction pool, followed by Transaction 19 to store theagreed upon time of the auction period. Furthermore, the cast votes and alsofinal voting result Transactions 18 store in the blockchain. In Transaction 17,the commercial property trade with a handover to Evarei, is the last immutableblockchain record creation.

5.6 Auction-Exit Manager

The sequence diagrams in Figure 11 and Figure 12 show the protocol of theauction-exit manager. The reason for the split into two parts is the size of theprotocol. In Figure 11, the APM sends an exit command to the auction-exitmanager (AEM) sending the property details prop and the valid certificationcertval. The AEM next passes prop and certval on to the EVMREIT fund manager

20

Fig. 10: The auction pool management sequence diagram.

(ERFM) that next launches the actual REIT for the auction exit. The ERFMcommunicates the REIT launch to the DAO, the EVMREIT (ER) investor andEvarei. Subsequently, the latter three stakeholders then place bids to the REITfor a certain period of time. It is possible to set the bidding period similarly asin the APM case of Figure 10, which we omit in the AEM protocol for the sakeof brevity.

When the expected bidding price is met, the ERFM component informsthe DAO and next, the ERFM sends a purchase command to the property-purchase manager (PPM). The latter component in Figure 11 performs thepurchase and informs the DAO, ER-investor and Evarei about the commercialproperty purchase. The PPM finishes the commercial property buying procedureby informing the ERFM that continues the AEM protocol in Figure 12. TheERFM issues accounts for ER investors who are informed about that fact. Finally,the ERFM sends a command to the AEM about being ready for performing atoken swap.

The AEM in Figure 12 orders the DAO to concretely swap the EVM againstEVR tokens and subsequently orders a payout of the fund to the PPM that inturn distributes the fund to Evarei. The latter pushes a part of the fund back tothe CSFP for being available when the next commercial property commences. InFigure 6 this fund distribution is depicted with a specific interface connection

21

Fig. 11: First part of the auction-exit management sequence diagram.

between the AEM and the CSFP from the bottom right to the top left of thecomponent diagram. The other part of the fund Evarei pushes to the ERFM com-ponent that requests know-your-customer (KYC) details from the stockexchange(SE) investor. After the DAO approves the KYC details, the ERFM performs adividend payout to the SE investor and informs the AEM the payout is carriedout. Subsequently, the AEM requests from the PPM the collected latest businessintelligence for delivery to the CSFP, which corresponds to the second interfaceconnection in Figure 6 from AEM to CSFP.

Blockchain transactions numbered from 20 to 26 in Table 1 are depicted inFigure 11 and Figure 12. Transaction 20 in Figure 11 records that the AEMreceives the exit command for an auction. Next, Transaction 22 stores the launchof the REIT fund and Transaction 25 records in the blockchain each REITbid. The last blockchain Transaction 21 in Figure 11 records the purchase ofcommercial property with a specific fund amount via the PPM. Next in Figure12, Transaction 23 records in the blockchain the swap of EVM with EVR tokens

22

Fig. 12: Second part of the auction-exit management sequence diagram.

by the DAO. Finally, Transaction 26 records the reinvestment of funds into newcommercial property by the ERFM component and Transaction 24 stores theevent of completed dividend payouts to the SE investor.

6 Feasibility Evaluation

We perform a paper-based feasibility evaluation for the Evareium architecture inSection 4 by considering available and emerging blockchain technology-focusedprojects for a rapid system deployment. Furthermore, we consider research workto complement the discussed industry blockchain technology projects. Note thatthe suggestions for rapid system deployment are tentative.

The remaining structure is as follows. Section 6.1 suggests blockchain technol-ogy solutions for rapid deployment. Section 6.2 discusses research work that ad-

23

dresses recognized blockchain technology challenges that require solution-findingmethods beyond traditional engineering approaches.

6.1 Industry Projects

For blockchain-based mass data storage of the Evareium system, the InterPlane-tary File System4 (IPFS) [9] is suitable as a content-addressable, peer-to-peer(P2P) and distributed hypermedia protocol that yields an open-source file system.IPFS uses a highly performance, decentralized block-storage model being analternative for the regular HTTP protocol. IPFS allows for hyperlinks to addressdata sets in a highly performing block-storage model with data distribution acrossseveral computers. A single computer participates with storing data subsets usingcontent addressing, hash-linked lists and allows to develop distributed blockchainapplications on top by placing immutable, permanent IPFS links into a blockchaintransaction.

For complex operations on large datasets, BigchainDB [27] is a suitablesystem also for constructing profiles. BigchainDB is a blockchain database withimmutable decentralized control, and the ability of creating and moving digitalassets. Essential for BigchainDB as a candidate for Evareium system considerationis the ability of connecting to other decentralized systems such as IPFS, Ethereum,Qtum and so on.

As a non-permissioned smart-contract platform for the Evareium system,earlier discussed Ethereum is a potential candidate. Still, one of the profoundEthereum disadvantages is that PoW creates performance and scalability chal-lenges that may not allow a large-scale use in the Evareium system. It is ourobservation based on Table 1 that the Evareium system requires a consider-able amount of blockchain operations to immutably store critical collaborationevents. The equally non-permissioned Qtum smart-contract solution uses SPVand UTXP for supporting lite wallets that may run on mobile devices. WhileEthereum has announced the development of a PoS version, it is still not clearwhen such a version will be available. On the other hand, PoS is already fullyfunctioning in the Qtum system. Both Ethereum and Qtum use Solidity as asmart-contract development language. A permissioned alternative to Ethereumand Qtum is Hyperledger [39] that aims to create an open-source distributedledger for enterprise-scaling applications with a code base. Hyperledger Fabric [14]is a modular implementation specifically for running smart contracts that alsoprovides pluggable implementations of various functions.

Since the Evareium system assumes smart commercial property managementthat employs IoT devices, other classes of distributed ledger technology existsthat are specifically suitable for such cyber-physical systems (CPS). For example,IOTA5 uses directed acyclic graphs (DAG) as an alternative to a blockchain thatyields free and highly scaling simultaneous transactions with fast confirmation

4 https://ipfs.io/5 https://iota.org/

24

times irrespectively of their size. More recently, Hashgraph6 is an alternativeDAG system comparable to IOTA that is equally suitable for CPS applications.

Developing sound smart-contracts without security flaws is a challenge andthe architecture of Figure 6 leads to the conclusion that an Evareium systemimplementation requires a large set of cross-dependent smart contracts that mustnot yield concurrency conflicts or dependability issues [2]. Several systems existfor evaluating contracts. The Securify7 online service formally verifies Ethereumsmart contracts and checks insecure coding with critical security issues. Cur-rently, only a beta-version of Securify exists and lacking documentation posesa challenge to estimate which formal properties are checked in what specificway. An online Securify example checks for transaction recordings, recursivecalls, insecure coding patterns, unexpected Ether flows and the use of untrustedinputs in security operations. Also the Embark-framework8 and Populus9 forsmart-contract development and deployment are currently not mature enoughfor satisfactory formal verification and evaluation.

6.2 Research Work

With respect to research trends that are relevant for a full implementation ofthe Evareium system, the evaluation of smart-contract is a research topic forwhich recent publications exist. As the discussion above shows, it is most likelythat several blockchain systems using smart-contracts are likely to be part of anEvareium implementation. Writing secure smart contracts is problematic [12]since it is the norm that programs and pseudonymous users call public methods ofthird-party programs. Thus, the result is a combination of trusted and untrustedprograms that lack security. A possible partial remedy is code translation to afunctional programming language termed F* to analyze and verify the functionalcorrectness and runtime safety of smart contracts that are written in Solidity.

Furthermore, adopting best practices for the development of smart contractsdecreases common mistakes to occur and in [16], a set of corresponding heuristicsare presented. These heuristics stem from observing students who develop faultysmart contracts in programming classes. Applying these best practices for smart-contract development has empirically resulted in a considerable reduction ofmistakes in the code. Addressed pitfalls are errors in encoding the state machines,failures to use cryptography, misaligning incentives, Ethereum-specific mistakessuch as call-stack-, blockhash- and incentive bugs.

6 https://hashgraph.com/7 https://securify.ch/8 https://github.com/iurimatias/embark-framework9 http://populus.readthedocs.io/en/latest/

25

7 Conclusion

This whitepaper presents the novel blockchain technology-based Evareium systemfor a smart-contracts driven trade of commercial property. We first define therequirement that must be satisfied by presenting goal models comprising tree-organized sets of refining functional goals. Assigned to the tree of functionalgoals are quality goals and roles of stakeholders in the Evareium system. Derivedfrom the goal model, we next give a UML component-diagram architecture thatgives the static structure of the Evareium system. Subsequently, the dynamicbehavior of the components are expressed in UML sequence diagrams that showblockchain transactions for events that must be immutably stored. The feasibilitystudy shows with what pre-existing industry solutions the Evareium system canbe quickly deployed. At the same time, we also show that the aspect of creatingverifiable smart contracts for the Evareium system is still a topic of ongoingresearch.

To answer the relevant questions for the development of the Evareium system,the value proposition of the goal model is the development of a B2B-crowdfundingplatform for investment in real estate. This value proposition is refined into sixbranches, namely for crowdsourcing pool funds, Evarei crowdfunding manage-ment, property profile management, auction platform leasing, the creation of anauction pool and the auction-property exit. The majority of quality goals are asso-ciated with the value proposition being strategic, secure, seamless, direct, liquid,verifiable and mutable. Assigning these quality goals with the value propositiondenotes the former hold for all functions of the system. What is also importantis, which branches of the goal model must be realized in a decentralized andtransparent way, namely, the crowdsourcing of pool funds, platform leasing andthe creation of auction pools. Additionally, the goal model assigns the Evareiumstakeholders being a renter, reward partner, investor, Evarei, committee, tech-nology partner, developer of commercial property, third party, realestate broker,DAO, EVM investor, EVMREIT investor and stock exchange investor.

The component architecture we derive from the goal model is organized in alifecycle starting with the crowdsourcing funds pool. The Component diagramshows conceptually labeled interface exchanges in one direction towards thelifecycle sink being the component for auction-exit management. Furthermore,we also assign actors in the component diagram corresponding to the roles ofactors in the goal diagram. Gray-shaded areas and components depict in whichparts of the architecture EVT tokens are used for monetization means. Thesink of commercial-property lifecycle of auction-exit manager connects to thesource of crowdsourcing funding by transferring via interfaces reinvestment withprofit distribution and also accumulated business intelligence of which, both areinstrumental for the next commercial property trade.

The dynamic behavior of the Evareium system that we depict with sequencediagrams show that the auction-exit management protocol is the most elaborateone, while the most amount of predictable blockchain transactions are part ofthe protocol for platform leasing. The latter protocol is less elaborate than theauction-exit management that requires almost the same amount of blockchain

26

transactions. Property profile management is ranked third in terms of requiredblockchain transactions and involves the most amount of entities. Still, thesequence protocol is not as elaborate.

Finally, the limitation of the Evareium system that requires scientific attentionis the challenge of high distribution. This informal representation of the Evareiumsystem does not address in detail the predictable dependability and concurrencyconflicts that will occur in an application implementation. Understanding thesedependabilities and concurrency conflicts is important to prevent deadlocksand unnecessary loops between Evareium system components. Furthermore, thesound development of smart contracts for the Evareium system is still a challenge.Research is necessary to assure smart contracts can be verified for their soundnessahead of enactment to assure their use is secure and their behavior is as expected.

References

1. M. Aiello, E. Johnsen, S. Dustdar, and I. Georgievski. Service-oriented and CloudComputing. Springer, 2016.

2. A. Avizienis, J. Laprie, B. Randell, and C. Landwehr. Basic concepts and taxonomyof dependable and secure computing. IEEE transactions on dependable and securecomputing, 1(1):11–33, 2004.

3. R. Baheti and H. Gill. Cyber-physical systems. The impact of control technology,12:161–166, 2011.

4. K. Balasubramanian, A. Gokhale, G. Karsai, J. Sztipanovits, and S. Neema. Devel-oping applications using model-driven design environments. Computer, 39(2):33–40,2006.

5. A. Baum. Proptech 3.0: the future of real estate. 2017.

6. D. Bell. Uml basics: The component diagram. IBM Global Services, 2004.

7. F. Bellifemine, A. Poggi, and G. Rimassa. Jade–a fipa-compliant agent framework.In Proceedings of PAAM, volume 99, page 33. London, 1999.

8. F. Bellifemine, A. Poggi, and G. Rimassa. Jade: a fipa2000 compliant agentdevelopment environment. In Proceedings of the fifth international conference onAutonomous agents, pages 216–217. ACM, 2001.

9. J. Benet. Ipfs-content addressed, versioned, p2p file system. arXiv preprintarXiv:1407.3561, 2014.

10. I. Bentov, A. Gabizon, and A. Mizrahi. Cryptocurrencies Without Proof of Work,pages 142–157. Springer Berlin Heidelberg, Berlin, Heidelberg, 2016.

11. K. Bhargavan, A. Delignat-Lavaud, C. Fournet, A. Gollamudi, G. Gonthier,N. Kobeissi, N. Kulatova, A. Rastogi, T. Sibut-Pinote, N. Swamy, and S. Zanella-Beguelin. Formal verification of smart contracts: Short paper. In Proceedings ofthe 2016 ACM Workshop on Programming Languages and Analysis for Security,PLAS ’16, pages 91–96, New York, NY, USA, 2016. ACM.

12. K. Bhargavan, A. Delignat-Lavaud, C. Fournet, A. Gollamudi, G. Gonthier,N. Kobeissi, A. Rastogi, T. Sibut-Pinote, N. Swamy, and S. Zanella-Beguelin.Formal verification of smart contracts. In Proceedings of the 2016 ACM Workshopon Programming Languages and Analysis for Security-PLAS16, pages 91–96, 2016.

13. V. Butterin. A next-generation smart contract and decentralized applicationplatform, 2014.

27

14. C. Cachin. Architecture of the hyperledger blockchain fabric. In Workshop onDistributed Cryptocurrencies and Consensus Ledgers, 2016.

15. P. Dai, N. Mahi, J. Earls, and A. Norta. Smart-contract value-transfer protocolson a distributed mobile application platform. URL: https://qtum. org/uploads/-files/cf6d69348ca50dd985b60425ccf282f3. pdf, 2017.

16. K. Delmolino, M. Arnett, A. Kosba, A. Miller, and E. Shi. Step by Step TowardsCreating a Safe Smart Contract: Lessons and Insights from a Cryptocurrency Lab,pages 79–94. Springer Berlin Heidelberg, Berlin, Heidelberg, 2016.

17. J. Delsing, J. Eliasson, J. Gustafsson, R. Kyusakov, A. Kruglyak, S. McLeod,R. Harrison, A. Colombo, and J. Mendes. Building system of systems with soatechnology: A smart house use case. In Industrial Cloud-Based Cyber-PhysicalSystems, pages 219–230. Springer, 2014.

18. E. di Bella, F. Odone, M. Corsi, A. Sillitti, and R. Breu. Smart security: Integratedsystems for security policies in urban environments. In Smart City, pages 193–219.Springer, 2014.

19. H. Do and W. Ng. Blockchain-based system for secure data storage with privatekeyword search. In 2017 IEEE World Congress on Services (SERVICES), pages90–93, June 2017.

20. H. Dong-Sik and J. Park. Method and apparatus for smart-key management, May 52015. US Patent 9,026,785.

21. R. Eshuis, A. Norta, O. Kopp, and E. Pitkanen. Service outsourcing with processviews. IEEE Transactions on Services Computing, 99(PrePrints):1, 2013.

22. R. Eshuis, A. Norta, and R. Roulaux. Evolving process views. Information andSoftware Technology, 80:20–35, 2016.

23. R. S. et al. Unified Modelling Language. http://www.uml.org, 2017.24. E. Gaetani, L. Aniello, R. Baldoni, F. Lombardi, A. Margheri, and V. Sassone.

Blockchain-based database to ensure data integrity in cloud computing environments.In ITASEC, pages 146–155, 2017.

25. A. Hari and T. Lakshman. The internet blockchain: A distributed, tamper-resistanttransaction framework for the internet. In Proceedings of the 15th ACM Workshopon Hot Topics in Networks, HotNets ’16, pages 204–210, New York, NY, USA, 2016.ACM.

26. L. Luu, V. Narayanan, C. Zheng, K. Baweja, S. Gilbert, and P. Saxena. A securesharding protocol for open blockchains. In Proceedings of the 2016 ACM SIGSACConference on Computer and Communications Security, CCS ’16, pages 17–30, NewYork, NY, USA, 2016. ACM.

27. T. McConaghy, R. Marques, A. Muller, D. De Jonghe, T. McConaghy, G. McMullen,R. Henderson, S. Bellemare, and A. Granzotto. Bigchaindb: a scalable blockchaindatabase. white paper, BigChainDB, 2016.

28. S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system. Consulted, 1(2012):28,2008.

29. A. Norta. Creation of smart-contracting collaborations for decentralized autonomousorganizations. In International Conference on Business Informatics Research, pages3–17. Springer, 2015.

30. J. Peng, G. Fuchun, L. Kaitai, L. Jianchang, and W. Qiaoyan. Searchain: Blockchain-based private keyword search in decentralized storage. Future Generation ComputerSystems, 2017.

31. R. Ragunathan, I. Lee, L. Sha, and J. Stankovic. Cyber-physical systems: The nextcomputing revolution. In Proceedings of the 47th Design Automation Conference,DAC ’10, pages 731–736, New York, NY, USA, 2010. ACM.

28

32. J. Rittinghouse and J. Ransome. Cloud computing: implementation, management,and security. CRC press, 2016.

33. J. Rumbaugh, I. Jacobson, and G. Booch. Unified Modeling Language ReferenceManual, The (2Nd Edition). Pearson Higher Education, 2004.

34. L. Sterling and K. Taveter. The art of agent-oriented modeling. MIT Press, 2009.35. M. Swan. Blockchain thinking: The brain as a dac (decentralized autonomous

organization). In Texas Bitcoin Conference, pages 27–29, 2015.36. N. Szabo. Formalizing and securing relationships on public networks. First Monday,

2(9), 1997.37. A. S. Tanenbaum and M. Van Steen. Distributed systems: principles and paradigms.

Prentice-Hall, 2007.38. M. Vukolic. The Quest for Scalable Blockchain Fabric: Proof-of-Work vs. BFT

Replication, pages 112–125. Springer International Publishing, Cham, 2016.39. M. Vukolic. Rethinking permissioned blockchains. In Proceedings of the ACM

Workshop on Blockchain, Cryptocurrencies and Contracts, BCC ’17, pages 3–7,New York, NY, USA, 2017. ACM.

40. C. Wilson, T. Hargreaves, and R. Hauxwell-Baldwin. Smart homes and their users:a systematic analysis and key challenges. Personal and Ubiquitous Computing,19(2):463–476, 2015.

41. G. Wood. Ethereum: A secure decentralised generalised transaction ledger. EthereumProject Yellow Paper, 2014.

42. F. Wortmann and K. Fluchter. Internet of things. Business & Information SystemsEngineering, 57(3):221–224, 2015.

43. X. Yue, H. Wang, D. Jin, M. Li, and W. Jiang. Healthcare data gateways: Foundhealthcare intelligence on blockchain with novel privacy risk control. Journal ofMedical Systems, 40(10):218, Aug 2016.

44. B. Zhou, W. Li, K. Chan, Y. Cao, Y. Kuang, X. Liu, and X. Wang. Smart homeenergy management systems: Concept, configurations, and scheduling strategies.Renewable and Sustainable Energy Reviews, 61:30–40, 2016.

45. G. Zyskind, O. Nathan, and A. Pentland. Decentralizing privacy: Using blockchainto protect personal data. In 2015 IEEE Security and Privacy Workshops, pages180–184, May 2015.