Spatial Blockchain: Enhancing Spatial Queries and Applications through Integrating Blockchain and Spatial Database Technologies

Abstract

The fusion of spatial data with blockchain technologies presents an innovative approach towards a decentralized, secure, and trustworthy framework for spatial information management. This integration brings spatial representation to the forefront of blockchain, opening avenues for various sectorial applications. However, challenges like slow processing times, restricted query capabilities, and consistency issues have been identified within the blockchain system. Addressing these challenges, we propose an optimized method for spatial queries by leveraging the high-performance capabilities of spatial databases. Unlike conventional off-chain query techniques, our approach synergistically combines hyperledger fabric with a specialized spatial database. This fusion facilitates distributed spatial queries within blockchain framework, incorporating spatial operation functionalities into smart contracts while preserving the distributed nature of nodes and spatial databases. Enhancing system security, we incorporate a dual-stage verification mechanism alongside a salt-hash storage strategy to counteract potential unauthorized alterations. Initial results validate the efficacy of our methodology in terms of performance and security. Building on this foundation, we introduce a rental transaction system that effectively merges spatial data with blockchain, demonstrating the feasibility and potential of integrating spatial information into the blockchain, especially in the realm of real estate.

1. Introduction

Blockchain technology has catalyzed revolutionary shifts across diverse sectors in recent years. The evolution of blockchain has progressed from the foundational Blockchain 1.0, characterized by Bitcoin [1], to the contract-centric Blockchain 2.0 epitomized by Ethereum [2], leading to the multifaceted Blockchain 3.0. This contemporary version broadens its scope to encompass various societal activities, emphasizing equity, transparency, and openness. Hyperledger fabric [3] stands as a prime representative of Blockchain 3.0.

Geographic information technology has evolved alongside the burgeoning wave of information advancements [4]. Spatial data offers tangible depictions of geographic information. As business requirements expand, the demand for massive data storage, analysis, and processing necessitates robust solutions. Currently, the predominant solutions hinge on centralized databases or distributed storage systems. Centralized systems, although efficient, are prone to single-point failures and potential data manipulations, undermining system trustworthiness and historical traceability. Merging blockchain with spatial data can harness the decentralized, reliable, and trustworthy attributes of the former to enhance spatial data management. This integration paves the way for diverse geospatial blockchain applications, such as construction industry [5], land management [6], real estate transactions [7,8,9], and spatial data sharing [10,11].

Existing research on integrating blockchain with spatial data primarily bifurcates into two strategies [12,13,14]. The first approach modifies the structure of blockchain to accommodate spatial data storage. However, this faces challenges with intricate spatial data, causing limitations in system throughput and query variety. The second approach employs an external database for spatial querying. The latter utilizes an external database for spatial queries but struggles with data consistency and potential performance choke points. The current release of hyperledger fabric lacks native support for spatial query operations; it compensates for this by relying on third-party geographic query plugins. Addressing these challenges, we introduce an optimization method that integrates a spatial database with hyperledger fabric.

Our primary contributions within this paper are as follows:

(1)

Innovative Data Management: We utilize a spatial database, introducing an innovative streaming replication architecture that distinctively separates read and write operations and synchronizes blockchain data with spatial data, overcoming inefficiencies inherent in spatial queries and single-method limitations.

(2)

Consistency and Security in Querying: Through the alignment of peer nodes with databases, and the incorporation of spatial query operations within smart contracts, we not only establish a bridge between off-chain and on-chain operations but also enhance the integrity and security of a cohesive distributed query architecture by introducing a fortified storage mechanism and a dual-stage verification process.

(3)

Application Development: We construct a rental transaction system, substantiating the practical applicability of our integrated method by combining spatial data and blockchain technologies, thereby demonstrating tangible advancements in real-world scenarios within the real estate domain.

Through our experimental framework utilizing hyperledger fabric and PostGIS, our method showcases enhanced spatial data query efficiency and robust defense against tampering compared to the third-party plugin strategy. On this solid foundation, we develop a rental transaction system harnessing the synergies of spatial data and blockchain.

In subsequent sections of this paper, we unfold our research systematically. Section 2 delves into related works, setting a contextual foundation. Section 3 outlines our methodology, while Section 4 presents experiments and analyses validating our approach. Section 5 manifests our methods in a practical rental transaction system application, and Section 6 wraps up our findings and suggests future research directions.

2. Related Works

In light of the burgeoning intersection between blockchain technology and geospatial data management, a myriad of studies has paved the way toward understanding, and further optimizing, the dynamic and challenges between these two domains.

2.1. Blockchain Architectures and Management of Spatial Data

The application of blockchain technology to spatial data has opened novel avenues for secure and distributed data management. The evolution from Blockchain 1.0 to 2.0 and subsequently to Block-DAG [15] has sequentially addressed performance and architectural challenges, which have further been targeted by endeavors like the ST_Block-DAG [16]. These structures aimed to improve the efficiency of storing and querying spatio-temporal data. The integration of blockchain with recognized spatial indices like geohash [17] proffers a notable stride towards combining GIS and blockchain yet contends with blockchain’s intrinsic constraints in storage and query capabilities. A common remedy involves resorting to dimension-reduction techniques, enhancing query speeds but limiting the support to two-dimensional point data and simple range queries, thus curbing their applicability in more diverse contexts.

On-chain and off-chain data management strategies have been the focus of research to address the inherent limitations of blockchain. Notable strategies, such as the approach proposed by Benahmed Daho [18] and Li et al. [19], aim to achieve a balance between immutability and scalability by dividing data storage into verifiable on-chain hashes and comprehensive off-chain data. Meanwhile, the “on-chain + off-chain IPFS extension” model [20] seamlessly integrates decentralized IPFS storage with blockchain, albeit at the cost of veering towards a semi-centralized framework. Within these architectures, ensuring the security and protection against unauthorized modifications in spatial databases is paramount. Yu et al. [21] proposed a relational query solution that employs the technique of adding salt and preliminary hash value in database storage to guard against certain malicious tampering.

2.2. Spatial Query Capabilities and Integrating Databases with Blockchain

Hyperledger fabric lacks native support for spatial queries, and CouchDB, which serves as the state database of fabric, is limited to JSON queries [22]. Confronting the challenges and limitations intrinsic to CouchDB, researchers have developed a variety of strategies to enhance its spatial query capabilities. A prevalent approach to optimizing databases that do not accommodate spatial search involves utilizing algorithms like geohash, which is a dimensional reduction method converting two-dimensional arrays into one-dimensional text [23,24]. Additionally, plugins like hastings and easton in CouchDB have also been leveraged to augment spatial querying capabilities, although with inherent complexities and possible performance bottlenecks within the plugin integration method.

When juxtaposing spatial databases, MongoDB and PostgreSQL emerge as beacons from the NoSQL and SQL realms, respectively, providing contrasting insights into spatial query performance and computational capabilities. MongoDB exhibits superior query speed, outstripping PostgreSQL by a factor of 10 to 25 times [25]. Conversely, SQL databases tend to outperform NoSQL counterparts in geographic information computations at the database level [26]. Nevertheless, it is vital to elucidate that integrating spatial databases, even those with powerful query capabilities, with blockchain technologies involves navigating through certain intrinsic limitations. Due to the inherent execution speed constraints of blockchains, the robust query efficiency of normal databases surpasses the blockchain’s execution rate, thereby not fully exploiting the heightened performance of the former. Therefore, pairing a spatial database with blockchain presents a more favorable combination.

2.3. Diverse Applications of Blockchain in Geospatial Data

The nexus between blockchain technology and geospatial data application has ushered in a plethora of innovative solutions addressing challenges in data privacy, integrity, and various other applications in distinct sectors. Ensuring the privacy of geospatial data, especially in location-based services, has been pivotal in numerous studies. For example, blockchain technology has been exploited to devise decentralized approaches that safeguard user privacy while affirming location trustworthiness [27]. Notably, researchers have explored means like proof-of-location schemes and integrated models (such as k-anonymity) to not only preserve user location privacy but also abate potential leakages during transaction processes in spatial crowdsensing systems [28,29].

Preserving geospatial data integrity is another crucial application, with blockchain enabling secure storage and information transfer, especially in Earth observation (EO) data. Various initiatives and blockchain models, like the Blockchain for Space Activities (BC4SA) project validate the integrity and provenance of EO data, securing platforms against potential security threats in remote sensing data sharing. FOAM (https://www.foam.space/, accessed on 19 September 2023) is another example, which provides a decentralized, consensus-driven world map, leveraging blockchain’s security and reliability with geospatial data specificity.

The emerging research and deployments across varied domains underline the formidable potential and applicative horizon of integrating spatial data with blockchain technology, revealing not only its viability but also its transformative capacity in diverse fields. Particularly, in the realm of real estate and housing rental, the amalgamation of blockchain and geospatial data could innovate secure, transparent, and efficient systems for managing rental agreements, payments, and property data, thereby unlocking new possibilities for both tenants and landlords.

3. Methodology

The proposed system employs a listener that iterates through the transactions in every block, and for valid transaction key-value pairs it constructs a comprehensive data storage structure. The data storage structure then translates the on-chain GeoJSON format into the corresponding relational schema for the spatial database, followed by storing the data therein. Additionally, spatial query APIs related to the spatial database are embedded within the smart contracts, enhancing the blockchain’s spatial query capabilities. The secure storage of the database employs the validation mechanism of FabricSQL [21], focusing on securing the most recent geospatial data. On this basis, a dual-stage verification mechanism, coupled with a storage validation mechanism and blockchain endorsement policies, is instituted to ensure the consistency and security of the blockchain.

3.1. Transactional Flow within the System Model

Illustrated in Figure 1, user applications interface with fabrics utilizing software development kits (SDKs), executing specific smart contracts based on the user’s organizational affiliation and channel. Peer nodes from respective organizations propagate transactions to an ordering node. This node, following transaction ordering and packaging, circulates them back to the peer nodes. Upon receipt, each peer node integrates a newly formed block into the ledger.

A dedicated listener persistently monitors block information, identifying and extracting pertinent details upon the generation of a new block. Geospatial data, originally encapsulated in the GeoJSON format, is converted to align with the PostGIS format, facilitated by a specialized conversion function. These restructured data are then transferred to PostGIS for storage. To assure data integrity, a security storage mechanism computes the hash value for each data segment, preserving this hash value in the associated PostgreSQL table.

Upon user initiation of spatial data queries, the smart contract retrieves database connection details from the peer node, establishes a data connection pool, and executes the relevant spatial query SQL statement. Subsequently, the database transmits the spatial query result back to the user via the smart contract. To validate data authenticity, the validation mechanism employs a dual-stage verification method, invoking system error alerts in instances of data tampering.

3.2. Spatial and Query Mechanisms for Data Storage

Peer nodes are the foundational elements of fabric, encompassing both smart contracts and ledgers. Each ledger consists of two components: the world state and the blockchain. The fundamental layer of the world state is engineered to leverage CouchDB, thereby preserving the most recent value of the present object. Every peer node is uniquely and exclusively paired with a corresponding CouchDB instance, adhering to a one-to-one pairing principle. In our proposed model, we retain this principle but introduce an alteration by implementing PostgreSQL, given its robust capabilities in spatial data management. This PostgreSQL deployment can be characterized by two distinct configurations:

• Single-node deployment: Each peer node is associated with an individual PostgreSQL instance, operating autonomously and free from mutual interference.
• Master-replication deployment: One master node, capable of read and write operations, synchronizes transactional activities with multiple read-only replication nodes to ensure data consistency.

Employing a master-replication database deployment strategy, only one master database is vested with writing capabilities, facilitating each organization to implement a single listener and validator and thereby reducing operational strain. Due to the predominantly read-oriented nature of the spatial database, the master-replication setup, which prioritizes read-write separation, is congruent with its primary utilization. Thus, the master-replication library deployment with read-write separation is adopted. In this scenario, each organization maintains a master library for synchronous data writing, while individual peer nodes utilize their respective replication libraries for spatial queries and operations.

The spatial database design, inspired by the fabric ledger architecture, integrates three main tables: the latest spatial data, historical data, and hash tables, each serving to preserve the latest transactional state value and retain all transaction-related records, analogous to the ledger’s world state and block, respectively. The establishment of the latest spatial data table is strategic in high-frequency operation scenarios to prevent potential delays and performance decline due to the reordering and filtering of the latest spatial data.

Addressing the interaction between smart contracts and databases unveils notable challenges, particularly the inability of smart contracts to directly utilize spatial queries from databases and the prospective accidental disclosure of confidential database configurations. A judicious solution proffered in this context involves the incorporation of spatial queries within smart contracts to back distributed querying mechanisms. Here, each spatial database is unequivocally affiliated with a singular peer node. This ensures the sustenance of the system’s distributed architecture and perpetuates the decentralized essence of the blockchain. Delving into the implementation of the proposed solution, it is crucial to avoid integrating plaintext configurations directly into smart contracts, mitigating the risk of exposing sensitive database information due to the public nature of the smart contract’s code. The proposed approach involves managing database operations via the peer node, thereby shielding spatial database configuration details and enabling connections to respective independent spatial databases.

In practical terms, the process unfolds as follows: each peer node sets up crucial database connection details—hostname, port number, account number, and password—before initialization. Once initialized, the peer node retrieves this configuration information, delivering it to the smart contract via the API. Utilizing existing smart contract methods and functions, like the function “getState(key)”, which retrieves a single transaction value from the ledger using a primary key, a consistent key value such as “pg_config” is assigned within the peer node, linking this key to the previously stored configuration variable. Thus, during the initial deployment of the smart contract, invoking “getState(pg_config)” retrieves the database configuration and establishes a connection. This connection instance is saved in a global variable, ensuring that subsequent spatial queries do not necessitate redundant connection re-establishments, preserving both efficiency and security.

Algorithm 1 outlines the essential steps of the aforementioned methods.

Algorithm 1 Integrated Algorithm for Managing Spatial Data via Smart Contracts

1: procedure DatabaseConnection 2:     $\mathrm{peerNodeConfig}\leftarrow \mathrm{configureDatabaseDetails}\left(\mathrm{hostname},\mathrm{port},\mathrm{account},\mathrm{password}\right)$ 3:     $\mathrm{retrieveConfig}\leftarrow \mathrm{peerNode}.\mathrm{retrieveConfiguration}\left(\mathrm{peerNodeConfig}\right)$ 4:     $\mathrm{API}\leftarrow \mathrm{sendConfigurationToSmartContract}\left(\mathrm{retrieveConfig}\right)$ 5:     $\mathrm{connection}\leftarrow \mathrm{smartContract}.\mathrm{invokeMethod}(“\mathrm{getState}”,“\mathrm{pg}\_\mathrm{config}”)$ 6:     $\mathrm{storeConnectionInGlobal}\leftarrow \mathrm{globalVariable}.\mathrm{store}\left(\mathrm{connection}\right)$ 7: end procedure 8: procedure SpatialQuery 9:     if $\mathrm{globalVariable}.\mathrm{connectionExists}\left(\mathrm{connection}\right)$ then 10:         $\mathrm{executeSpatialQuery}\left(\right)$ 11:     else 12:         $\mathrm{establishConnection}\leftarrow \mathrm{smartContract}.\mathrm{invokeMethod}(“\mathrm{getState}”,“\mathrm{pg}\_\mathrm{config}”)$ 13:         $\mathrm{executeSpatialQuery}\left(\right)$ 14:     end if 15: end procedure 16: procedure PushSpatialData(Block raw data) 17:     $\mathrm{network}\leftarrow \mathrm{getNetwork}\left(\mathrm{channelName}\right)$ 18:     $\mathrm{listener}\leftarrow \mathrm{network}.\mathrm{addBlockListener}\left(\mathrm{options}\right)$ 19:     $\mathrm{blocks}\leftarrow \mathrm{processListener}\left(\mathrm{listener}\right)$ 20:     for each block in blocks do 21:         $\mathrm{transaction}\leftarrow \mathrm{processBlocks}\left(\mathrm{block}\right)$ 22:         $\mathrm{geom}\leftarrow \mathrm{toGeom}\left(\mathrm{transaction}\right)$ 23:         $\mathrm{history}\leftarrow \mathrm{toHistory}\left(\mathrm{transaction}\right)$ 24:         $\mathrm{hash}\leftarrow \mathrm{toHash}(\mathrm{lastHash},\mathrm{history},\mathrm{salt})$ 25:         executeSQL(geom, hash, history) 26:     end for 27: end procedure 28: procedure ProcessLatestGeographicData(transaction data of the block) 29:     Output: Returns the SQL 30:     if $\mathrm{json}.\mathrm{geometry}.\mathrm{type}=\mathrm{Point}$ then 31:         $\mathrm{geoJSON}\leftarrow \mathrm{processPoint}\left(\mathrm{json}\right)$ 32:     else if $\mathrm{json}.\mathrm{geometry}.\mathrm{type}=\mathrm{LineString}$ then 33:         $\mathrm{geoJSON}\leftarrow \mathrm{processLineString}\left(\mathrm{json}\right)$ 34:     else if $\mathrm{json}.\mathrm{geometry}.\mathrm{type}=\mathrm{Polygon}$ then 35:         $\mathrm{geoJSON}\leftarrow \mathrm{processPolygon}\left(\mathrm{json}\right)$ 36:     end if 37:     $\mathrm{pgFormatGeom}\leftarrow \mathrm{transfer}\left(\mathrm{geoJSON}\right)$ 38:     if $\mathrm{json}.\mathrm{gid} \mathrm{exists} \mathrm{in} \mathrm{newGeomTable}$ then 39:         $\mathrm{sql}\leftarrow \mathrm{update}\left(\mathrm{pgFormatGeom}\right)$ 40:     else 41:         $\mathrm{sql}\leftarrow \mathrm{insert}\left(\mathrm{pgFormatGeom}\right)$ 42:     end if 43:     return sql 44: end procedure

3.3. Ensuring Data Integrity through Secure Storage and Dual-Stage Verification

The secure storage mechanism emphasizes two pivotal processes: data hashing and salt processing. A lengthy random string, or ‘salt’, is concatenated to the hash to enhance its security profile. The strategy interlinks each transaction data entry by aggregating historical data with the hash value of the last transaction in the hash table, thereby complicating illicit alterations to data. If data are compromised, modification to all corresponding transaction data and hash values in the table becomes necessary, raising the complexity and overhead of malicious activities.

To elaborate, the computation of the current hash value, ${\mathrm{hash}}_{\mathrm{cur}}$, is conducted using SHA256, a cryptographic hash function. Specifically, ${\mathrm{hash}}_{\mathrm{cur}}$ is calculated by hashing the concatenation of the previous hash value, ${\mathrm{hash}}_{\mathrm{last}}$, the value returned by the historical table, ${\mathrm{value}}_{\mathrm{his}}$, and the aforementioned salt. By utilizing the hash of the preceding transaction and including it in the computation of the current hash value, the methodology ensures that any unauthorized alterations in the transaction history can be easily detected. The mathematical representation of the process is illustrated as follows:

$$\left.{\mathrm{hash}}_{\mathrm{cur}}=SHA256{(\mathrm{hash}}_{\mathrm{last}}+{\mathrm{value}}_{\mathrm{his}}+\mathrm{salt}\right)$$

(1)

Upon secure archiving, the implementation of a dual-stage verification mechanism is imperative for authenticating both the historical and the most recent spatial data tables. This mechanism involves the periodic traversal of data tables and a re-computation of hash values based on table contents. Any discrepancies between the computed and stored hash values trigger an error alert, safeguarding data integrity.

The first verification mechanism meticulously traverses the latest spatial data table, calculating the current hash value and comparing it with the data hash value associated with the present id in the historical data table, thereby securing the integrity of the most recent spatial data. This direct correlation across all data entries affirms the reliability of the latest spatial data table. Meanwhile, the second verification mechanism focuses on authenticating the historical data table and hash table, extending its scope to each entry in the historical data table and ensuring their genuineness through similar processes.

In contrast to verification mechanisms that directly juxtapose the blockchain with the database [21], this dual-stage verification strategy operates independently of the blockchain. By exclusively reading data from the database, it alleviates operational pressure on the blockchain, achieving a harmonious balance between security and performance.

4. Experiments and Analysis

4.1. Experiment Setup and Data Overview

The experimental environment was configured on an Ubuntu server, equipped with an AMD EPYC 7551 48-thread processor, and 98G RAM. hyperledger fabric v2.3.1 was utilized for constructing the blockchain environment, with smart contracts and other interactive elements developed using Node.js. Data employed in the experiments were extracted from map data relevant to Beijing, confined to a specific latitude and longitude range (116.25${}^{\circ }$ to 116.48${}^{\circ }$ N and 39.83${}^{\circ }$ to 40.01${}^{\circ }$ E) within the WGS84 coordinate system. The focal area was proximate to central Beijing to optimize the spatial query hit rate. The datasets incorporated:

• POI data: Point data with over 80,000 records, encapsulating various locations, including restaurants and residences.
• Road data: Line data, amounting to more than 60,000 records.
• Building data: Polygon data, totaling upwards of 390,000 records.

During the experiments, two distinct methods, namely, the “plug-in integration method” and the “integrated database method”, were employed. The plug-in integration method utilized independent Hastings and Easton plugins on each peer node. Conversely, the integrated database method was configured with version 14 of PostgreSQL and version 3.2 of PostGIS on each peer node. While the former method employed separate plugins for each peer node, the latter utilized a master-replication database architecture across each organization. The master database was dedicated to synchronous writing, whereas the replication database facilitated spatial queries for each peer node within the organization. Both methods utilized hyperledger fabric as the fundamental blockchain platform and shared analogous methods for spatial query execution. However, they diverged in their approaches to data storage and indexing strategies.

4.2. Experimental Performance: Results and Analysis

In this section, we evaluate the performance of two distinct methods: the plug-in integration method and the integrated database method, within the realm of spatial queries. The comparative analysis focuses on three specific tests: range query, geometric relationship, and K-nearest neighbor (KNN) search. The range query utilizes spatial data enveloped within a circle as its querying parameter, with a randomly selected radius between 500 m and 5 km. The geometric relationship assessment hinges on the intersections between polygons and spatial data, while the KNN search aims to identify the 50 spatial data points nearest to a targeted point.

For evaluation, Caliper serves as the benchmarking tool for fabric blockchain performance. The test configuration encompasses five clients, each test duration spans 30 min, and each test is repeated five times to ensure consistency. Our dataset, comprising points, lines, and polygons, is specific to Beijing. The key performance indicator for this experiment is transactions per second (TPS), here denoting the frequency of spatial query executions per second.

Figure 2 explored the dynamics of spatial query performance under different operational conditions. Figure 2a demonstrates the impact of varied data volumes on spatial query performance while maintaining a consistent transaction backlog. On the other hand, Figure 2b presents how spatial queries respond to changes in backlog transactions with a fixed data volume. The results reveal that the query rate for the integrated database method nearly doubles that of the plug-in integration method.

Despite the theoretical superiority of the R*-Tree index (utilized by the plug-in integration method), it was consistently outperformed by the integrated database method. Two primary factors account for this discrepancy:

• Communication overhead: The plug-in integration method, specifically tailored for Fabric’s CouchDB, facilitates geographic queries through the hastings and Easton plugins, thereby requiring inter-plugin communication through HTTP connections, subsequently introducing a considerable query process delay.
• Computational demand: Compared to the integrated database method’s planar coordinate system, the plug-in integration method’s employment of a geographic coordinate system necessitates an abundance of trigonometric computations, which is especially perceptible given the relatively localized range of our experimental data.

As illustrated in

Table 1. Performance evaluation in (a) range query, (b) geometric relationship, and (c) KNN search.

	(a) Range Query		(b) Geometric Relationship		(c) KNN Search
Geometry Type	Plug-in	Database	Plug-in	Database	Plug-in	Database
Point	295.1	967.8	636.3	1341.4	216.1	802.0
Line	237.3	599.4	631.3	1321.4	172.2	527.7
Polygon	145.4	468.6	603.2	1240.3	96.9	429.4

, we evaluated the performance from different geometrical queries. As geometric complexity is elevated-signified by the augmentation of endpoints from an average of 4 (line data) to 19 (polygon data)—a conspicuous deterioration in query efficiency is observed, particularly for the resource-intensive polygon data.

Despite its merits, the integrated database method is not exempt from limitations, the most primary being the fabric itself. To mitigate this, the overall system speed can be enhanced by increasing the number of peer nodes. Moreover, associating multiple peer nodes with a singular PostGIS can reduce resource usage without compromising performance. The relationship dynamics between peer node quantities and PostGIS instances, as elucidated in Figure 3, further accentuate this point. The illustration delineates that for node counts ranging between 1 and 3, a single PostGIS manifests adequate efficacy in managing the query requisites of up to three nodes, albeit with a subtle performance dip when each node is allied with a PostGIS instance, potentially indicative of resource contention amongst PostGIS instances.

A divergence in performance trajectories is witnessed as node counts ascend beyond 4. The many-to-one configuration witnesses a query rate descent, highlighting that a single PostGIS instance, particularly when inundated with substantial data quantities and request volumes, evolves into a system performance bottleneck, subsequently amplifying processing delays and overall efficacy degradation. In contrast, the one-to-one configuration, wherein each PostGIS instance serves a singular peer node, maintains a surplus of performance bandwidth to adeptly navigate the query demands. Although the incorporation of multiple PostGIS instances sows seeds for potential CPU contention, it does not crystallize as a principal barrier within this experimental framework, thus permitting a sustained ascension in the overall query rate.

4.3. Tamper-Resistance Experiments

The storage verification mechanism and the endorsement strategy of the blockchain jointly strengthen the tamper-proof capability. The former protects against unauthorized database alterations, while the latter ensures cross-organization data consistency. Experiments demonstrated tamper detection via successive modifications to the latest spatial and historical data tables of the spatial database. Initially, 200,000 data points were inserted, and subsequently the first 100,000 were updated based on the same ID, leading to the latest spatial data table containing 200,000 points, while the historical data table accumulated 400,000 points.

Utilizing verification mechanism one (mentioned in Algorithm 2), the validator retrieved 10,000 points per page from the latest spatial data table, averaging 9.742 s of verification time per page. Algorithm 3 illustrates that altering data at the 100,000th position triggered the validator to detect a discrepancy between the calculated dataHash from the 10,000th data and the stored dataHash in the historical data table, identifying the anomaly after 97 s and issuing a warning.

Algorithm 2 Dual-Stage Verification Mechanism

1: procedure VerificationMechanismOne(newGeoTable, historyTable, hashTable) 2:     for each key in newGeoTable do 3:         geom ← SELECT * FROM newGeoTable WHERE id=key 4:         dataHash ← SHA256(geom) 5:         history ← SELECT * FROM historyTable WHERE key= geom.id ORDER BY id DESC LIMIT 1 6:         if history.dataHash ≠ dataHash then 7:            return Error: Data Mismatch 8:         end if 9:         hashCollection ← SELECT * FROM hashTable WHERE hid=history.id, history.id-1 10:         lastHash, curHash ← hashCollection 11:         calHash ← SHA256(lastHash, history, salt) 12:         if calHash ≠ curHash then 13:            return Error: Hash Mismatch 14:         end if 15:     end for 16: end procedure 17: procedure VerificationMechanismTwo(historyTable, hashTable) 18:     for each entry in historyTable do 19:         history ← SELECT current value FROM historyTable 20:         lastHash ← SELECT hash of previous id FROM hashTable 21:         calHash ← SHA256(lastHash, history, salt) 22:         if calHash ≠ hash of current id in hashTable then 23:            return Error: Hash Mismatch 24:         end if 25:     end for 26: end procedure

Algorithm 3 Database Operation and Validation

1: Step 1: Retrieve Geographic Data 2: Connect to the main database. 3: Execute the query: 4: SELECT id, ST_AsText(ST_Transform(geom,4326)) AS geo 5: FROM mychannel_geom 6: WHERE id = 100,000; 7: id: 100,000, geo: POINT(116.384741 39.882145) 8:   9: Step 2: Modify Geographic Data 10: Tamper with the geographic table data. 11: Execute the query: 12: UPDATE mychannel_geo SET geom = 13: ST_Transform(ST_GeomFromText(’SRID = 4326; POINT(116.321321 39.123456)’), 4796) 14: WHERE id = 100,000 RETURNING *; 15: id: 100,000, geo: POINT(116.321321 39.123456) 16:   17: Step 3: Data Validation 18: Start the validator and use validation mechanism one. 19: After 97 s, an error will be reported if data are tampered with. 20: [StartTime] 0 s, [Time] 97,230.45 ms, [Error] DataHash not equal, [Msg] The calculated hash value of geo is not equal to the hash value in history.

Employing validation mechanism two, the validator ensured the historical data table’s integrity by paging through it, retrieving 10,000 data per page, with an average validation time of 4229 ms per page. As shown, altering the data at the 200,000th position caused the validator to detect a discrepancy between the calculated hash value and the corresponding value in the hash table. This anomaly was identified after 86 s, triggering a system warning.

In this context, the blockchain’s endorsement policy, which determines the minimum set of organizations required to validate a transaction, augments security. This involves nodes from respective organizations executing and signing the outcome of associated smart contracts, thereby ensuring transaction validity.

However, the blockchain’s endorsement mechanism is unsuitable for detached off-chain query systems due to the uniform data acquired by each peer node. In contrast, using the original endorsement strategy can directly bolster security in an integrated and distributed database solution. For example, the endorsement policy dictated by the smart contract in this section’s experiment necessitates signatures from at least one peer node across two organizations. As Algorithm 4 demonstrates, if a database from a specific peer node of Organization 2 exhibits geographic data tampering, the endorsement strategy cannot be satisfied, leading to the smart contract’s abnormal termination, effectively detecting inconsistencies across organizations even if the two-factor authentication mechanism fails to promptly identify data tampering.

Algorithm 4 Tampering with the Databases of Different Organizations

1: Step 1: Modify Geographic Data 2: Connect to the database of organization two and modify geographic data: 3: UPDATE mychannel_geo SET geom = ST_Transform(ST_GeomFromText(’SRID = 4326; POINT(116.365555 39.915555)’), 4796) WHERE id = 5000; 4:   5: Step 2: Perform Queries Using SDK 6: Invoke SDK with information of organizations one and two. 7: Perform KNN query: 8: query(org1, org2, ’SELECT id, gid, ST_AsText(ST_Transform(geom, 4326)) AS geom, ST_DISTANCE(geom, ST_Transform(ST_GeomFromText(“SRID=4326;POINT(116.34 39.92)”), 4796)) AS distance FROM mychannel_geo ORDER BY geom <> ST_Transform(ST_GeomFromText (“SRID = 4326;POINT(116.34 39.92)”), 4796) LIMIT 2;’) 9: Store results for each organization separately. 10: Perform Range query: 11: query(org1, org2, ’SELECT id, ST_AsText(ST_Transform(geom, 4326)) AS geom, ST_DISTANCE(geom, ST_Transform(ST_GeomFromText(“SRID=4326; POINT(116.34 39.92)”), 4796)) AS distance FROM mychannel_geo WHERE ST_DWithin(geom, ST_Transform(ST_GeomFromText (“SRID = 4326; POINT(116.34 39.92)”), 4796), 300);’) 12: Store results for each organization separately. 13:   14: Step 3: Validate Consistency and Report Errors 15: if Results of organization one ≠ organization two then 16:     Report an error: “Results returned by the two organizations are inconsistent.” 17:     Output error details: “TransactionError: Commit of transaction df....c8dd failed...” 18: end if

5. Application of Spatial Blockchain: Rental Transaction System

5.1. Hierarchical Architecture of the Rental Trading System

The rental trading system employs a hierarchical architecture (as shown in Figure 4), organized into five distinct layers: the data layer, network layer, consensus layer, control layer, and application layer. Each layer plays a pivotal role, ensuring the system’s robust functionality and security across various processes and transactions.

The data layer: the comprehensive management of system-related data. The data layer consolidates all system-related data, including user, transaction, and spatial data, among others. It is divided into three components: the fabric ledger, PostgreSQL, and PostGIS. The primary repository for transaction data, including spatial elements, is CouchDB, utilized over the native LevelDB by hyperledger fabric. On the other hand, PostGIS stores and indexes transaction data replicas, primarily formatted as geographic data, while PostgreSQL manages data related to users, websites, and metadata.

The network layer: ensuring secure and efficient distributed applications. Critical in enabling robust and secure distributed applications through hyperledger fabric, the network layer adopts the gRPC communication protocol to enhance efficient communication. It also utilizes the TLS protocol to secure data against unauthorized access or alteration. To augment data security and node isolation, each node operates within individual docker containers in hyperledger fabric, and peer nodes, modified as per this study, interface with PostGIS to enable spatial querying functionalities.

The consensus layer: achieving network-wide agreement. The consensus layer aims to achieve consistent agreement across all network nodes regarding transactions, ensuring that every node attains a unified perspective on the veracity of transactions upon completion. This layer also manages transaction sequencing and atomicity, maintaining the integrity and coherence of data within the distributed ledger. Hyperledger fabric supports a range of consensus algorithms, such as Solo, Kafka, and PBFT, which are interchangeable. This study employs the PBFT consensus algorithm to achieve node consensus within the network.

The control layer: bridging applications and the blockchain framework. Acting as an intermediary between the application layer and the hyperledger fabric blockchain framework, the control layer includes smart contracts and facilitates interaction with the blockchain system via SDKs. This establishes a channel for communicating with smart contracts. While hyperledger fabric provides provisions for smart contract development in three languages: Java, Go, and Node.js, we utilize Node.js, leveraging the Fabric-Node.js-SDK for development purposes in this research. Furthermore, the control layer synchronizes data and ensures secure storage within PostGIS.

The application layer: user interaction and functionality. Positioned above the control layer, the application layer provides interactive functionalities for users, including NFT data upload, trading, and retrieval. Employing the Vue framework for web client development and integrating the Baidu Map API for detailed map structuring and visualization, this layer also implements a two-factor authentication mechanism to mitigate data manipulation risks, complemented by real-time monitoring and alerting protocols.

5.2. Systematic Design and Functional Implementation of the Rental Transaction Platform

Built upon the integrated database approach, this section delineates a secure, reliable, and queryable rental transaction system with capabilities for information visualization. Subsequent subsections delve into the structure of each functionality.

House listing upload: The platform enables landlords to list their property, associating them with a distinct geographical locations as unique (non-fungible token) NFT identifiers. Upon successful registration, landlords are permitted to input various property details, encompassing the property type (full rental or shared rental), location, layout, square footage, rental fee, contact specifics, and accompanying visuals. After the system validates the listing, the provided data are transferred to the blockchain network. Subsequently, the affiliated smart contract is triggered, facilitating the creation of the property record and ensuring the secure deposition of spatial information in PostGIS. Users have the ability to peruse these data assets within their dedicated property center.

Rental property search: This platform empowers tenants to navigate and refine property listings tailored to their requirements. Users can filter by locations, property types, dimensions, rental price, and additional criteria to streamline their property search. A salient feature of this system is its map-centric search approach, encompassing functionalities like region-specific searches and subway-centric search. Each search result prominently displays the geographical location information of listing, enhancing user accessibility to property details. Leveraging the Baidu Maps API and spatial querying capability of the smart contract, the system innovative introduces a subway-proximate housing search. This permits users pinpoint listings in proximity to subway lines, tailored further by their preferred rental price or size brackets. Such an approach resonates with contemporary rental market trends, prioritizing accessibility to subway stations, thereby optimizing user convenience in property selection.

Rental property transaction: Upon identifying a suitable housing listing, tenants can proceed with the rental property transaction within the system. The system manages and records transaction details, ensuring the security and transparency of the transaction. All transaction information is stored on the blockchain to guarantee immutability.

5.3. Design of System Network Architecture

The fabric network is categorized into two pivotal entities: the rental transaction platform and the regulatory institution, each playing a critical role in facilitating and overseeing transactions. The ensuing discussion illuminates the roles of these entities and illustrates their network configurations.

The rental transaction platform: This entity functions as the primary interface for users, facilitating various features, including property listing uploads, property transactions, proof of existence, and token issuance. Its design emphasizes user engagement and transaction processing, thereby establishing a straightforward avenue for users to interact with and utilize the platform.

The regulatory institution: The regulatory institution, often a government department, provides legal backing and exercises regulatory oversight for rental transactions. Ensuring accurate registration and verification of property details by the regulatory institution is crucial. In the event of disagreements or conflicts, it holds the authority to intervene expediently and mediate resolutions.

The network configuration and management: The configuration of the network involves several peer nodes and multiple master-replication databases for each organization, as depicted in Figure 5. The number of PostGIS deployments can be dynamically adjusted based on specific hardware configurations and the quantity of peer nodes. In scenarios with a substantial number of peer nodes, several of them can be associated with the same database, preserving resources without undermining performance. In contrast, when peer nodes are scarce, incorporating additional master-replication databases to maintain a 1:1 ratio between the peer nodes and PostGIS instances is vital to assure data security.

5.4. Implementation of the Blockchain System

The system implementation comprises two principal components: a blockchain developed with hyperledger fabric, integrated with a spatial database, and a frontend developed using Vue.js. All blockchain services operate in docker containers, employing docker compose for node deployment and management.

5.4.1. Optimizing Hyperledger Fabric with Effective Node Deployment

The hyperledger fabric network consists of multiple node types, each running on a separate machine, including CA nodes, peer nodes, client nodes, and ordering nodes. CA nodes issue X.509 certificates for identity and organization info, used to digitally sign transaction proposals and contract responses. Peer nodes execute and validate transactions and store world state. Client nodes submit transaction requests and query the blockchain state. Ordering nodes order transactions into blocks and generate new blocks. All nodes consistently update their blockchain state.

Within the scope of this research, modifications were made to peer nodes to support PostGIS API interfaces by:

1.

Embedding IO read/write functions into peer ledger files.

2.

Accessing the PostGIS configuration file, which encompasses credentials and IP addresses among other data.

3.

Yielding connection information when “pg_config” is detected during the getState function.

After these code alterations, nodes must be recompiled and packaged to establish new peers. Each peer is housed within its own docker container, with docker compose orchestrating inter-container communication. During node deployment, it is imperative to meticulously configure each node, which includes delineating parameters like node types, communication endpoints, and certificates. Furthermore, network protocols and policies, such as transaction validation and certificate requisites, must be definitively configured.

5.4.2. Execution and Deployment of Smart Contracts

Within the hyperledger fabric, smart contracts serve as vehicles for executing business logic, operating on peer nodes, and being accessible through client nodes. Smart contracts are capable of receiving requests, executing various operations such as data storage and update, and returning execution results. The smart contracts for this research, scripted in NodeJS, consist of three segments: token transfer, listing transaction, and retrieval service.

The token transfer component is conceptualized following the ERC20 standard, which is prominent for token creation in Ethereum. This entails functionalities such as token issuance, transfer, and balance inquiries. Within the context of the rental system, tokens double as a payment medium, symbolizing the ownership of rental assets and facilitating the more efficient allocation and management of these assets.

When a property is enlisted, its unique identifier, deduced from the spatial location hash, is used to generate a non-fungible token (NFT). The structural schema of the data is depicted in

Table 2. Housing data fields.

Field Name	Data Type	Description
token_id	String	Unique flag id
house_owner_id	String	Owner id
house_tenant_id	String	Tenant id
house_description	String	Listing details
housing_type	String	Listing type
housing_location	String	Property location
housing_layout	String	House type
housing_area	String	Room size
housing_rent	float	Rental of premises
contact_info	String	Contact details
housing_images	String	Link to listing images

.

When tenants initiate the leasing of a property, negotiations regarding the rental fee with the landlord ensue. Once an agreement on the terms is reached, a smart contract is autonomously executed, bestowing the tenant with usage rights for the agreed lease duration. It is imperative that the transaction details, which are auto-generated, are irreversibly preserved on the blockchain, encompassing variations in tenant ID, the mutually agreed transaction price, timestamps, and other relevant specifics. Unlike standard NFT transactions, the final rental fee often demands confidentiality due to numerous landlords desiring to abstain from publicizing the finalized rental fee, thereby retaining leverage in subsequent negotiations. Hyperledger fabric’s private data capabilities are employed to assure the confidentiality of this price with the procedure being delineated as Algorithm 5. This algorithm comprehensively outlines the steps encompassing the initiation of the lease transaction, through the negotiation phase, to the conclusive finalization of the transaction, with a marked emphasis on preserving the confidentiality of the mutually agreed final price.

Algorithm 5 Leasing Process

Require: Tenant and Landlord mutually decide to initiate a lease transaction

Ensure: An immutable record of the transaction details on the blockchain

1: Tenant and Landlord negotiate on the rental fee, P 2: if terms are agreed then 3:     Tenant and Landlord each propose a price, $P_T$ and $P_L$, respectively 4:     Smart contract is executed, granting tenant usage rights for a stipulated period 5:     Transaction details, including Tenant ID, agreed price P, and timestamps, are generated and stored on the blockchain 6:     if confidentiality of P is required then 7:         P is recorded on the blockchain, accessible only to the respective owner 8:         Others can only see $\mathrm{hash}\left(P\right)$ 9:         The smart contract compares $\mathrm{hash}\left(P_T\right)$ and $\mathrm{hash}\left(P_L\right)$ 10:         if $\mathrm{hash}\left(P_T\right)=\mathrm{hash}\left(P_L\right)$ then 11:            The transaction is finalized 12:         else 13:            An error is raised and the transaction is not finalized 14:         end if 15:     else 16:         P is recorded and is visible to all on the blockchain 17:         The transaction is finalized 18:     end if 19: else 20:     The lease transaction is not initiated 21: end if

5.5. Implementation of Software Development Kit(SDK) and Frontend Interface

5.5.1. SDK Implementation

The hyperledger fabric SDK is endowed with an extensive set of APIs, facilitating developers to interface with the fabric network programmatically. For the purpose of this research, we engage the Fabric-SDK-Node to implement functionalities related to the invocation of smart contracts while also employing the Koa2 framework to construct RESTful API services, which are fundamental to supporting frontend functionalities. Notably, we leverage the SDK to instantiate both a secure storage mechanism and a dual-stage verification mechanism to uphold the integrity of the spatial database.

The two principal methods, submitTransaction and evaluateTransaction, play critical roles in managing transactions in our system, each catering to different aspects of transaction handling. The submitTransaction method oversees write operations related to smart contract transactions, ensuring transaction authenticity and accuracy through a multi-party consensus mechanism. Throughout the transaction process, compliance with consensus criteria is obligatory, demanding concurrence from multiple organizations for the successful execution and subsequent dissemination of the transaction’s outcome to all nodes, thereby assuring consistency across all ledgers. On the other hand, the submitTransaction method orchestrates the execution of query operations tied to smart contracts, eliminating the need for collaboration from other organizations and leaving the ledger unaffected. Specifically, this operation queries a node within a unique organization and retrieves the resultant data.

The secure storage mechanism firmly anchors on the SDK’s blockListener event. Establishing a blockListener with the hyperledger fabric SDK necessitates embedding the channel listener within the codebase. Once a new block is generated, the blockListener is activated, executing various tasks, which may encompass logging, manipulation, or initiating alerting functions within the application.

The dual-stage verification mechanism engages a setInterval timer to periodically validate data, initiating every ten minutes. Each validation cycle begins anew, activating verification mechanism two following the culmination of verification mechanism one. Importantly, verification is confined to the master database in the master-replication architecture since the replication database data originates from the master database’s replication stream and remains read-only. Hence, securing the master database safeguards the integrity of the comprehensive master-replication database system.

5.5.2. Frontend Implementation

The frontend interface serves as a gateway for users to access diverse functionalities. Different user types interact with the backend to trigger code executions, enabling operations on the blockchain network. The core functions are bifurcated into two segments: the first focuses on showcasing geographical spatial information on the map, while the second offers a platform for real estate property transactions.

The highlight of this system is the “Housing Search on Map” feature, which graphically depicts the geographical spatial attributes of NFT assets. Depending on the zoom level of the default map view, information layers can be displayed, including administrative district, business district, and residential communities. By highlighting specific areas on the map or tracing subway lines, users can access pertinent rental details, as illustrated in Figure 6.

Upon successful user registration, the homepage navigates users, showcasing proximal real estate properties relative to their current location. Additionally, users are presented with options to filter properties as per their preferences. Simultaneously, sellers obtain the capability to list rental properties in their personal center, furnishing basic details, rental information, a comprehensive description, and accompanying images. After submission, the data undergoes a platform review. Once approved, it is committed to the blockchain. Each feature and functionality presented in the front-end implementation is strategically devised to augment user experience while ensuring accurate and secure transactions on the blockchain network. Through interactive maps and user-friendly transaction platforms, the implemented system presents a seamless interface for managing and engaging in real estate transactions, thereby bridging the gap between technological advancements in blockchain and practical applicability in the real estate domain.

6. Conclusions

This study attempts to transcend the current constraints of integrating spatial data with blockchain technology. Addressing the challenges of inadequate spatial query functionality and inefficiencies, we introduced hyperledger fabric as the foundational platform as well as an optimized spatial query approach that integrates with a spatial database. By embedding spatial functions directly into smart contracts, can execute spatial operations more efficiently. Additionally, a dual-stage verification mechanism ensures database security. Notably, our method outperforms plug-in integration methods in performance tests.

Expanding the practical applications of our study, we developed a rental system based on spatial blockchain, illustrating the tangible potentials and usability of a spatially enabled NFT transaction system in real-world scenarios. The rental system, enabled by our spatial NFT transaction system, facilitates secure and efficient real estate transactions by leveraging smart contracts, which ensure the immutability and transparency of rental agreements and transactions on the blockchain. Furthermore, it enhances user experience by implementing map-based house finding and rental transaction interfaces.

This application in the rental market not only substantiates the practical and applied potential of integrating spatial data with blockchain technology but also highlights the potential for extending these applications to other high-value, spatially dependent domains. Such areas might include land certification, real estate registration, food traceability, and the internet of things, all of which inherently hold high value and depend heavily on spatial attributes while grappling with issues of limited platform trust. Thus, they stand out as promising candidates for the fusion of blockchain and geographic information system (GIS) technologies, illuminating a pathway for future research to explore further integrations and applications in various fields.