Technical Architecture Concept

The system architecture concept of the REMAP ecosystem comprises layered modular functions with interactions occurring between layers. Such interactions are governed by decentralized autonomous organisations that reside within each layer. Hence, it is important to outline the main architectural layers of the REMAP ecosystem and their functions, the reusable modules in each of the layers, the types of DAO governance in each layer, and the models of interactions between the modules and functions in the layers. Furthermore, this section of the whitepaper introduces the concepts of secure data storage that supports the REMAP ecosystem and the technical outline for the token reward system. Although the architecture of REMAP is designed to be blockchain technology-agnostic, it is necessary to instantiate specific concepts such as reusable modules and how they are realized in well-established blockchain solutions. Generally, the modules in REMAP are organized in various layers within zones that represent the collection of various application-specific blockchains.

Layers of REMAP Architecture

The architecture of the ecosystem comprises 3 main layers. At the top is the business application layer, which is also referred to as Layer 3, consisting of various business logics of processes within the real estate ecosystem. Some examples of real estate business processes for which their business logic can be captured in Layer 3 include document creation and validation processes, asset handling, purchase and renting processes, lease management processes etc. Thus, REMAP contributors in Layer 3 (L3) can provide concrete business logics on how the outlined examples of real estate business processes can be executed by re-using existing REMAP functions. Such business logic deployed in the REMAP ecosystem by L3 contributors can be referred to as decentralized applications (DApps) and the reusable functions used in realizing the logic expressed in these DApps are referred to as modules. The business logic layer can comprise the compilation of multiple modules. The second layer of the REMAP ecosystem architecture contain these reusable modules. These modules are developed and deployed by REMAP ecosystem contributors that are part of Layer 2 (L2). Some examples of the modules include the user registration/onboarding module, generic contract module, asset verification module etc. The bottom layer of the REMAP system architecture is the infrastructure layer, which is also referred to as Layer 1 (L1). L1 consists of blockchain-specific protocol components that support the REMAP ecosystem such as public blockchain storage ledgers, decentralized databases such as the inter-planetary file systems (IPFS), and resolvers for decentralized identifiers (DID). Other interesting examples of re-usable modules that are part of L1 include the payment module, digital signature verification and governance modules. Also, since REMAP is designed as an application-specific blockchain network, the blockchain connectors are components in L1 that provide a system for exchanging information between blockchains in the REMAP network.

The most interesting part of the REMAP architecture is the design of the reusable modules in L2 of the architecture. Hence, the rest of this section focuses on describing the types of reusable modules in the REMAP network, possible interactions that can exist between the different module types, the technical aspect of DAO governance of the modules and the REMAP token reward system that supports the development of modules in the ecosystem.
Three distinctive components make up the REMAP architecture and each component comprises various layers of REMAP applications and protocols. The main components of the REMAP technology-agnostic architecture are listed as follows: REMAP Clients that run on end-users smartphones or can be accessed via Web-based interfaces, REMAP node servers that connect clients to blockchain-supported functionalities as well as various REMAP infrastructure components and third-party services. Except for the infrastructure components, the rest of the REMAP architecture components contain the REMAP reusable modules that are part of L2.

Reusable Modules in REMAP Architecture

In the current design of the system architecture, four main types of modules are possible: SDK, library modules, smart contract modules which are generally considered as state application modules, client-side modules and API modules. The REMAP SDKs provide the developers with a framework for combining various modules deployed in the REMAP network into an application-specific blockchain. The client-side modules, which are implemented with scripting languages such as Javascript, enrich the basic REMAP client with additional functionality. They contain specific libraries that can be invoked by a given DApp when interacting with the blockchain (via REMAP nodes), remote clients (in a P2P fashion) or other infrastructure components. Deterministic applications/functions in the REMAP ecosystem that require a high level of trust are mostly implemented as smart contract modules. This will enable the transparent and trusted execution of business conditions commonly encountered in PropTech and real estate within REMAP. Furthermore, interesting concepts such as user-defined or ecosystem-defined access control policies can easily be encoded on top of these modules, regulating the REMAP users that can access and reuse such modules. At the core of the REMAP layered and modular architecture is an effective reward mechanism for developers who contribute to the ecosystem. Hence, transparent and verifiable revenue sharing can be implemented on smart contract modules, such that interactions with these modules result in increased reputation and rewards for their creators. Non-deterministic applications in REMAP are considered service modules or oracles which are implemented as a type of API module. In simple terms, modules can interact with external applications that run in centralized servers using service modules. There is no specific language for implementing the service modules. Another type of API module is bridges that serve as an inter-connector between various blockchain zones that are part of the REMAP ecosystem. In future, REMAP will also provide connectivity for other PropTech applications deployed in other L1 blockchain networks such as Ethereum. Lastly, the library modules contain classes of codes which can be (re-)used to realize various PropTech-specific functionalities. Since SDKs are generally non-compiled applications, implementing automated revenue sharing (such as in smart contract modules) with their developers is quite difficult. Therefore, community-based approaches are adopted in funding the development of the library modules. These kinds of funding schemes can be governed in accordance with the DAO that resides in the layer the library modules are developed in.
To demonstrate how these module types are realized, we consider a sample task of document validation (depicted in Figure 7 and extensively presented in Section 5). Completing this task could require three modules such as optical character recognition (OCR), digital signature, and payment module. These required modules can be specified as the business logic of the task. Once these modules are compiled together into a single application, they become a DApp that is distributed across nodes of the specific blockchain zone in which the application is deployed. The OCR module being a non-deterministic application is implemented as a service module (a subtype of API module), while the payment applications could be realized via smart contract modules.

Interaction Model in the REMAP System Architecture

Interaction occurs in the REMAP ecosystem when business logic DApps are used to invoke reusable (client-side or server-side) modules that perform specific functions. In contrast, transactions resulting from such interactions may be recorded on the blockchain. To have a clearer understanding of these interactions, it is necessary to first outline various classes of actors and stakeholders that are specified in the REMAP architecture design. There are three main classes of actors: the contributors, business organizations, and the end-users. The contributors are software developers who create various types of reusable modules in the REMAP ecosystem. The business organizations compile these modules into DApps for automating various business logic within the PropTech ecosystem. The end-users interact with the DApps using frontend client/wallet applications. Interactions mainly occur between modules that reside in Layer 2 of the main components. Such components include the REMAP client and the REMAP server node. Client modules can interact with each other, for instance, by exchanging authentication credentials using a peer-to-peer (P2P) network. Another interesting interaction is between client modules and smart contract modules. An example of this interaction is during the deposit of RMC from users’ wallets for escrow-like payments specified in a smart contract. Modular interactions can also occur between smart contracts and service modules. The smart contract module can be used to specify checks necessary for validating data returned by the API module of an external oracle. Smart contract modules can also invoke each other, hence, realizing smart on-chain inter-module interactions. Since REMAP basically provides an SDK for building and deploying application-specific blockchains within the ecosystem, the interactions between modules in different blockchains of the REMAP network are facilitated using bridges.