You are currently viewing a new version of our website. To view the old version click .
MDPIMDPI
Search all articles
Smart Cities
Download PDF
  • Article
  • Open Access

9 July 2025

A Semantic Link Network Model for Supporting Traceability of Logistics on Blockchain

,
and
1
Key Lab of Intelligent Information Processing, Institute of Computing Technology, Chinese Academy of Sciences, Beijing 100190, China
2
Department of Informatics, King’s College London, London SE1 7EH, UK
3
School of Computing and Information Technology, Great Bay University, Dongguan 523000, China
4
Great Bay Institute for Advanced Study, Dongguan 523000, China
Smart Cities2025, 8(4), 115;https://doi.org/10.3390/smartcities8040115
Version Notes
Order Reprints

Highlights

What are the main findings?
  • A semantic link network model for representing logistics transport transactions and states.
  • A semantic link with state representation for supporting data security and logistics traceability.
  • A location mapping mechanism for ensuring logistics traceability.
What is the implication of the main finding?
  • The semantic link network model is expressive and extensible in modelling complex systems and dynamic semantics.
  • The semantic link network model is capable of modelling and implementing decentralized and distributed applications.

Abstract

Logistics transports of various resources such as production materials, foods, and products support the operation of smart cities. The ability to trace the states of logistics transports requires an efficient storage and retrieval of the states of logistics transports and locations of logistics objects. However, the restriction of sharing states and locations of logistics objects across organizations makes it hard to deploy a centralized database for supporting traceability in a cross-organization logistics system. This paper proposes a semantic data model on Blockchain to represent a logistics process based on the Semantic Link Network model, where each semantic link represents a logistics transport of a logistics object between two organizations. A state representation model is designed to represent the states of a logistics transport with semantic links. It enables the locations of logistics objects to be derived from the link states. A mapping from the semantic links into the blockchain transactions is designed to enable the schema of semantic links and the states of semantic links to be published in blockchain transactions. To improve the efficiency of tracing a path of semantic links on a blockchain platform, an algorithm is designed to build shortcuts along the path of semantic links to enable a query on the path of a logistics object to reach the target in logarithmic steps on the blockchain platform. A reward–penalty policy is designed to allow participants to confirm the states of links on the blockchain. Analysis and simulation demonstrate the flexibility, effectiveness, and efficiency of the Semantic Link Network on immutable blockchain for implementing logistics traceability.

1. Introduction

Smart cities enhance the quality and efficiency of urban public services through ICT systems that integrate communication and computing technologies [1]. Modern smart logistics undertakes green, efficient, and secure transport of goods within and between smart cities, supporting the operations of smart cities. Security, privacy protection, and efficient collaboration between organizations are challenges to logistics in smart cities. The traceability of a logistics system is the ability to trace the states of logistics transports and the locations of logistics objects being transferred through the logistics transports of a logistics process. Ensuring the traceability of the logistics process helps improve customers’ informedness, especially in cross-border supply chains in smart cities.
To support traceability, a database for recording the states of logistics transports and the locations of logistics objects is necessary. Due to the restrictions of sharing transport states and locations of logistics objects among different organizations, centralized databases are often unsuitable as it is hard to meet the requirements of data privacy protection of different regions. A distributed and decentralized data management solution is desired to implement logistics traceability in a distributed, decentralized, and secure platform where logistics data can be published and traced with less centralized management. Blockchain is a promising decentralized data management model that can be used to publish logistics data in a decentralized way [2,3]. It can be used to implement decentralized and secure information-sharing applications of smart cities [4].
Smart contract enables developers to construct and deploy distributed and decentralized data management services on Blockchain platforms to implement logistics transport data publishing and querying services [5]. However, deploying logistics data on smart contract services faces the following problems:
(1) Publishing on-chain data in smart contracts is expensive, and the immutability property of Blockchain data makes it difficult to implement data management with complex semantics [6]. Implementing logistics traceability requires recording and keeping updated on the states of logistics transports. It needs a data model over immutable blockchain transactions to support data updating and tracing on the blockchain. Logistics management rules implemented in a smart contract may need to be updated during transport and should be promptly reflected in the logistics tracing process. But rewriting smart contracts is costly. The hash pointers underlying blockchain transactions can be revised to allow for updates [7], but it will break the traceability of transactions. Verification and representation of logistics rules can be implemented separately in different smart contracts, which can partially reduce re-deployments of smart contracts [8]. But, any update made to logistics management rules will still require updating smart contracts that implement the logistics rules, which can result in a loss of traceability because it has to add new smart contracts for new logistics rules.
(2) Tracing logistics processes in decentralized data requires visiting and confirming a large number of blockchain transactions that record logistics process states, which is also costly. Various storage indexing structures, such as the Patricia tree, have been developed to improve the efficiency of querying a single transaction in the local storage of computing nodes on a blockchain platform. However, it still lacks an indexing structure over the blockchain transactions to enable fast tracing along a chain of blockchain transactions.
To meet the two challenges, this paper proposes a semantic link network data model to store logistics data with a schema in blockchain transactions to represent logistic process states on a Blockchain platform. A logistics process tracing can be implemented by tracing states stored in blockchain transactions. The state updating schema is implemented in the semantic link network model and is stored with the logistics state within a blockchain transaction so that the rules of logistics states can be dynamically updated during a logistics process. States of a logistics transport can be traced and confirmed by following blockchain transactions on Blockchain, which ensures the security and traceability. A shortcut link publishing algorithm is designed to record the states of a logistics transport path, which can significantly improve the tracing process by following shortcut links. A penalty-reward policy is designed to encourage the two participants to quickly finish the confirmation of the logistics transport states in a decentralized way.
The solution based on Semantic Link Network (in short SLN) model has the following advantages:
(1) The SLN is such a flexible and extensible graph-based semantic representation model that can represent logistics transports by semantic links published on blockchain transactions [9]. It has a schema with a graph structure to define reasoning rules among links. In the model, a logistics process can be represented by a semantic link network where nodes represent the parties and semantic links between two nodes represent logistics transports between two parties. Each logistics object in the logistics process is uniquely represented by a binary string ID. The schema of SLN instances specifies rules for determining legal transitions between link states. A semantic link between two nodes is attached by a logistics object ID to represent one logistics transport of the logistics object between two parties. The logistics transport path corresponds to a path of links that transfer the same logistics object from one node at the beginning of the path to the node at the end of the path. Each semantic link is published in one blockchain transaction together with its schema to enable decentralized tracing on the Blockchain. It can be deployed as a blockchain platform without using a smart contract to manage logistics data.
(2) A state model of link is designed to represent the states of logistics transports in the logistics process. Locations of logistics objects can be derived from the semantic link states. An algorithm can be designed to publish semantic links with different states in blockchain transactions by treating the logistics objects as virtual assets of blockchain transactions. The state updating can be implemented by publishing semantic links with different states in blockchain transactions. The schema can also be published in blockchain transactions to support the verification of state transitions. The traceability can be implemented by tracing semantic links published in blockchain transactions.
(3) Shortcut links can be added to improve the query efficiency of the path of links for obtaining the state of logistics transports on a logistics transport path. Shortcut links are added in a probabilistic way so that different numbers of added links can achieve different speed-ups of the tracing process.

5. Reducing the Average Accesses to Account

To reduce the number of accesses to the hosts while still maintaining a certain level of decentralization, it is necessary to keep balance between the number of accesses to the hosts and the decentralization of storage. According to the location mapping in Definition 5, in two cases of the location of d, u—<l, d>→v is mapped onto the payer account u and in one case l is mapped onto the payee account v. Due to the location inference rules in Definition 3, the hosts of the blockchain transactions published for a link with different states is unevenly distributed among two computing host of the two accounts. Thus, for obtaining the states of links, the average number of accessing the two hosts is reduced from 2 to 1.4 as shown in Theorem 1.
Theorem 1. 
Assuming that a query on the k states of a given link l visits each state with the equal probability, the expected times of accessing the hosts of blockchain transactions for l is 1.414, when using the host mapping function in Definition 5.
Proof. 
From the link inference rules in Definition 3 and location mapping function in Definition 5, one can see that 5 out of 6 states of a link u—<l, d>→v is mapped into the account u. Then, if all k states are within the 5 states stored in u, then one access to the account u is enough, if there is at least one visit to the state stored in v, then two accesses are required. The expectation can be obtained by modelling the probability of having one host access and having two hosts accesses as a binomial distribution:
E X = 1 n ∑ i = 1 n − 1 p i + 1 − p i + 1 − p i − 1 − p i × 2 ,
where n = 6 and p = 5/6.
That is, when the states are stored in an unbalanced way distributed on two hosts of a link, more states of links can be accessed on one host of a transaction that stores more states of links than another. When p = 5/6, E(X) obtains the minimum. □

5.1. Improving Efficiency of Path Tracing by Adding Shortcut Links

Although the unbalanced storage distribution of link states can reduce the average accessing times for checking the states of a link, it is still inevitable to traverse each host of account of each blockchain transaction published for a link path when implementing the link path traceability. The total number of accesses is proportional to the number of hosts for storing the path of links. Specifically, to access a path L(di) = {v1, l1, v2, l2, v3, …, ln, vn} of the object di from node v1 to node vn, it first needs to visit the root node to obtain the first blockchain transaction starting from v1 and then it obtains the first link l1 and its corresponding states. Following the blockchain transaction pointer from v1, the next host v2 is accessed to obtain the second link l2 until reaching the final node vn, where all hosts v1, v2, v3, …, and vn are accessed sequentially by at least one time and each access needs an authorization of the payer account of the blockchain transaction. It can be time-consuming when sequentially visiting each payee account for verification of blockchain transactions.
To reduce the number of accesses to hosts for getting a link path L(d), a simple way is to separate the whole path L(d) into to ⌈n/s⌉ segments and select the first node in each segment of s nodes as a representative host to hold the links within the segment so that one access to the representative node can obtain links of the whole segment of L(d). ⌈n/s⌉ representative nodes are enough to hold all n links and the number of accesses of hosts is reduced to ⌈n/s⌉. However, the total length n of the path cannot be obtained during the link publishing process, which makes it difficult to obtain a proper s for determining ⌈n/s⌉. To overcome this limitation, an algorithm is designed to add shortcuts among nodes on a path of link L(d) in a probabilistic manner without knowing the length of the path. Instead of splitting the path L(d) into segments, it lets each node on a link path randomly add a set of shortcut links from itself to its following nodes along the path when a link is being published in a blockchain transaction. A shortcut link allows a query along the path L(d) to jump over a sub sequence of nodes from a node to the rear part of the link path by following the pointer of the shortcut link. The aim is to allow the tracing process to visit log(n) nodes to reach the end of the path and obtain all links in L(d) without knowing n. After building the shortcuts, the node holds replicas of node IDs within the sub-sequence of the link path from the node to its longest shortcut on the link path so that one can obtain the path in L(d) by visiting log(n) nodes. In this way, log(n) shortcuts are built for each node to enable accessing the path L(d) within log(n) steps of jumps from the root node to the final target node in L(d). Since each node is stored in one host, thus, log(n) hosts are accessed to obtain the link path.
Algorithm 2 shows the shortcut publishing algorithm. A shortcut is constructed as the logistics object d is transferred to a payee account when a link is published in a block transaction from a payer account to the payee account. The suffix ID of the object d is used as a token to record the account IDs that it has been transferred to. Thus, the path of d can be obtained from the suffix ID (in Line 1). For each node vi on the path, the distance si from vi to payee is l − i + 1 and a short cut is constructed in a random sampling way with the sampling probability of 1/si (from line 6 to line 10). When a shortcut link is built, a blockchain transaction with the suffix ID of the logistics object d from vi to payee is published by vi so that the account vi will have a pointer to payee (line 10). Note that the length l is not the final length of the link path, it is the length of current path that has been passed through by d. Thus, the algorithm does not need to know the length of the final path.
Smartcities 08 00115 i002

5.2. Analysis of Performance of Tracing Path Along Shortcut Links

According to Theorems 3 and 4, each node along the path L(di) will have O(ln(n)) shortcut links on average, and the expected steps to obtain the whole links of L(di) is O(ln(n)).
Figure 6 shows an example of shortcuts appended on a blockchain list for one logistics object d1. There are shortcut links across multiple nodes on the link path. For example, v1 has two shortcuts to v3 and v5, respectively, then it has replicas of node IDs of the path from v1 to v5. The shortcut to v3 is added with a probability of P(add) = 1/2 because logistics object d1 moves 2 steps from v1. The shortcut to v5 is added with a probability of P(add) = 1/4. By accessing v1, one can obtain a set of nodes from v2 to v5 of the current path, which can greatly speed up traversal performance.
Figure 6. Shortcuts on a blockchain list.
A query on a path of links is processed in an iterative way to obtain a tree structure formed by the paths of a logistics object d transported from the root account T (shown in Algorithm 3). The Algorithm 3 includes the following input arguments: parent records the current tree node to be constructed to record the paths starting from the first root node of the tree used as the final output argument of the algorithm, visistlist records the account IDs that have been processed, currenttrepath records the tree path that has been traversed from the root account, T is the current blockchain account ID that the query is processing, the logistics object ID d is the query target ID, and B is the blockchain platform service interface.
Smartcities 08 00115 i003
The Algorithm 3 starts from the root account T of a logistics process. In each iteration, a tree node currenttreenode is constructed in line 8 and is set as a child node of the tree node parenttreenode, which finally forms a tree consisting of paths of the logistics object d has been traversed as the query result. After constructing the current tree node, all the blockchain transactions started from T are obtained (line 11), and each blockchain transaction is checked to find those blockchain transactions that are used to transfer the query target d (line 13 and 14). For each of these blockchain transactions, two cases need to be handled. If the suffix ID (B.d in line 13) of the blockchain transaction B = <T, v, d, s> is longer than an existing suffix IDs that have been located and store in jumpbranches (line 18), then the blockchain transaction stored in jumpbranches is replaced by current B (line 19). If there is no such blockchain transaction, B is a new branch of transport of d and is appended to the list jumpbranches. In this way, the blockchain transaction that has the longest jump can be located. After checking all the blockchain transactions sent from T, jumpbranches contains the longest paths that d has taken. Then, for each jump in jumpbranches, the iterative call on QUERYPATH(currenttreenode, vistilist, currenttreepath, each.v, d, B) will recursively process each branch using the updated input argument in the last call of the procedure until reaching the leaf nodes that have no branch of transport of d (line 32). The recursive call can be processed in an asynchronous way so that the branches can be processed concurrently processed efficiently by leveraging the shortcut jumps.
According to Theorem 2, the expected number of shortcuts added for each node is ln(n), where n is the total number of nodes in the link. The number of steps for finding a node is also bounded by ln(n) (Theorems 3 and 4). According to Theorem 5, the number of suffix IDs for duplication during the shortcut construction along a path is O(n2). All links can be obtained within the O(ln(n)) steps by allowing a query from the starting node to concurrently process along all the shortcut links, which can be deemed as a width-first concurrent traverse on a tree of depth O(ln(n)).
Theorem 2. 
The expected number of shortcut links for v1 is O(ln(n)).
Proof. 
At the ith step of movement of di, the probability of adding a shortcut link from v1 is 1/i. The expectation of the number of links from v1 to the ith node is also 1/i. The expectation of the total number of shortcut links of v1 is the sum of expectations of the ith nodes for i = 1, …, and n, which is O(ln(n)) according to the upper bound of the limitation of the sum of the first n elements in a Harmonic series [38]. □
Theorem 3. 
The expected number of steps for reaching a target node vj from vk is O(ln(j − k)).
Proof. 
Assuming vk is at the tth step and the number of steps from vk to vj is j − k, which is represented as s(t) = j − k. Then there is one shortcut vq from vk that can jump across a segment of steps (j − k)/e with high probability. That is, vq that can help reduce the distance from 1/e of s(t) and the distance from the vq to vj is (j − k)/e. Recursively applying this process, there is at most O(ln(j − k)) steps to reach vj. □
According to Theorem 3, the following expected upper-bound of the longest jump can be obtained.
Theorem 4. 
The expected longest jump from vk to vj is O((j − k)/e).
According to Theorem 3 and 4. The expected number of IDs stored for a node vk is the (n − k)/e. There are n(n − k)/e node IDs on n nodes for one link path and a query from any node to its following ending node in the path can be processed in O(ln(n)) steps involving O(ln(n)) access to nodes.
Theorem 5. 
The expected number of suffix IDs for a link of length n is O(n2/e)).
Proof. 
According to Theorem 2, the longest expected jump is 1/e, which incurs n/e replicas of suffix IDs. Therefore, n nodes will have at most n2/e replicas of node IDs. □

5.3. Penalty-Reward for Speeding up Confirmation of Link States

A penalty–reward policy is designed to encourage users to publish semantic links in a consistent way to avoid conflict in the confirmation of a link state by the participants of the logistics transports. When publishing a semantic link u—<l, d>→v with state l(n), the hosts of node u and v of the semantic link need to confirm the consistency of the published link with the real logistics transport. If the link is correctly published, then the two hosts should reach consensus on the state of the published link. Otherwise, they should make a check on the status of the logistics transport. If they cannot reach a consensus on the state of the link, they are unable to publish new links. There should be a penalty on the account u who publishes inconsistent links that cannot be confirmed by node v. But there can be malicious responses on confirmation, thus we need to control the confirmation process to let responses also pay costs so that malicious responses can be suppressed.
To implement such a policy, each node is assigned two scores in two accounts su and ru, where su is the trustiness account that is used for starting a confirmation of link and ru is the responsibility account that is used to store the score that needs to respond to a confirmation. Then, the confirmation process is conducted by transferring scores through blockchain transactions among the trustiness account and the responsibility account of two nodes. It can be implemented in a smart contract. Four types of transactions can be issued among the four accounts of two nodes u and v as shown in Figure 7. The whole confirmation procedure can be executed in following four stages:
Figure 7. Confirmation transactions.
(1)
The trustiness transactions are issued between su and sv, which are used to send confirmation requests and confirmation responses for each published link t (two green arrows in Figure 7). The trustiness score is added by St when there is a new link t to be confirmed. A trustiness transaction will transfer St from su to sv. Thus, the trustiness transaction can be executed only once for one link. When node v confirms the link state, the trustiness score St is sent back to su in another trustiness transaction, and a reward score αt is added to both trustiness accounts of su and sv.
(2)
If node v has a conflict on the confirmation, it needs to start an argument to respond to node u. In this case, it will not use the trustiness transaction. Instead, node v uses the account rv to make an argument response transaction to ru with score St (gray arrow in Figure 7). However, the response account rv does not have initial scores, which need to borrow scores from its own trustiness account sv in a borrow trustiness transaction (dark arrows in Figure 7). Then, the score is sent to the responsibility account in an argument response transaction. When node u receives the transaction scores in its ru, it knows that there is a conflict on confirmation. Node u needs to check the transport with node v so that they can reach a consensus on the state of the link.
(3)
If they reach a consensus, node u uses the confirm response transaction to send score St back to the trustiness account sv of node v. Then, node v sends St back to node u through a trustiness transaction. In this case, the confirmation completes.
(4)
If they need further arguments, response transactions are used to send scores from their own responsibility account to counterpart’s responsibility account, until one sends the score St back to the trustiness account, which indicates that they reach consensus.
Since the responsibility account initially has a zero score, it needs to borrow scores from the trustworthiness account to make an argument. Moreover, there is an extra penalty βt charged on their trustiness account for each borrow trustiness transaction. Each argument transaction is also charged by βt. That is, if more arguments are made, their trustworthiness score will be exhausted, and they will not have enough trustworthiness score to start a new confirmation process for a new link and start an extra argument response. So, malicious responses are costly for both sides of a link. On the contrary, if they can reach consensus quickly on a confirmation just using the trustiness transactions, rewards can be accumulated in their trustiness accounts.
Finally, a reliability score Ru = su − ru can be obtained for a node u as the indicator of the performance of u. A higher Ru means that there are more consistent links published and fewer arguments for node u. The nodes with a reliability score lower than a threshold R will be halted.
As the topology shown in Figure 7 is strongly connected, the scores will finally approach an ending distribution for four accounts. In an extreme case, the two nodes halt after their reliability score is lower than R.
Theorem 6. 
The scores of su, sv, ru, and rv will approach a halting condition for one complete confirmation process with two trustiness transactions.
Proof. 
As the graph of Figure 7 is strongly connected, there are two possible ending states: two trustiness transactions are finally executed; their reliability scores T are exhausted. □
One possible situation is that one participant does not take any further action. In this case, its responsibility account and trustiness account are not balanced. The further actions can be halted according to the unbalance of the two accounts of a host.
As the account score can be exhausted when too many confirmation requirements are issued, it can help protect confirmation from DoS attacks. Moreover, the account score can be accumulated when completing the logistics process by end-users, which can also help prevent a Sybil attack to some extent when end-users are verified on the blockchain.
All the transactions are published on the blockchain and the two accounts are opened and signed by their owners so that anyone can obtain the reliability score of a host by visiting the opened transactions and corresponding trustiness and responsibility accounts. Although short cut links can increase the number of transactions published on blockchain, it is still controlled and relatively much smaller compared with real transactions published on blockchain for bitcoin transactions. Rather than using smart contract, the logistics transport data is encapsulated in transactions in a total decentralized way, which is much more secure than using smart contract-based solution that requires a central implementation of data management.

6. Experimental Evaluation of Path State Query

Simulation experiments are carried out to evaluate the path query on the blockchain. We randomly generated a set of logistics processes, each consisting of a set of logistics objects that are to be transferred among a group of parties. Then, we evaluate the average costs of obtaining a link within a path of links by using the shortcuts method.
Figure 8a shows the distribution of the number of shortcuts of nodes on a path of length 1000. It can be seen that both the average number and the max number of shortcuts for one node is bounded within a range from 1 to 25. That is, although the number n of total nodes is unknown; the number of shortcuts for one node is still in control. Figure 8b shows the steps of obtaining all nodes of one path. Each test case has 1000 paths, with an average length from 4 to 40. The x-axis represents the average length of the paths. When there is no shortcut, the average number of steps is in linear growth with the length of the path (shown in avglp_length curve in Figure 8b. When shortcuts are added to each path, the steps to obtain the whole path are within a logarithms scale with respect to the length of path (shown by avglp_short curve in Figure 8b), which is below the theoretic bound curve (log in Figure 8b). Figure 8c shows the number of replicas of node IDs produced after adding shortcuts to link paths. The number of replicas (num-rep in Figure 8c) is bounded by O(n2) (shown as n2 in Figure 8c). In summary, the simulation results confirm the analysis of the querying efficiency of paths when adding shortcuts to the path.
Figure 8. Distribution of the length and the number of shortcuts on semantic link paths of lengths from 4 to 40.
A set of simulation experiments is conducted to further evaluate the performance of tracing logistics processes by using semantic links with different shortcut adding schemas. A total of 10,000 transactions are published for 1000 logistics paths, where each path is from 4 to 40 in length. According to the procedure of adding shortcut links in Algorithm 2, starting from one node, there can be a logarithmic number of shortcut links to be added if the length of the path from the node is long enough. Moreover, if each node along the path adds its own shortcut links, the number of total shortcut links added for one path can be too many, as shown in Figure 8a. Three different strategies can be applied to adding shortcuts for a logistics process.
(1)
shortcut-head: only the head node of the logistics path needs to add shortcut links along the path. The reset nodes do not add shortcut links.
(2)
shortcut-eachone: each node only adds one shortcut link. That is, when the first shortcut link is added for a node, the process of adding shortcut links is stopped for the node.
(3)
shortcut-all: Each node performs the whole process of adding shortcut links.
Figure 9a shows the number of short links added for 1000 logistics paths of length from 4 to 40. shortcut-head has almost a constant number of added shortcuts. shortcut-eachone has a moderate number of shortcut links, which is about half of the path length. shortcut-all has the highest number of added shortcut links. The performance of tracing a path along shortcut links varies with the number of shortcut links, which is shown in Figure 9b, together with the tracing process without shortcut links. Each trace of one logistics transport step needs on average 3–4 min; thus, if the number of shortcut links is few, the performance gain can be little. shortcut-head obtains the improvement over the tracing process without shortcut links, although in some cases, it does not improve the performance. The shortcut-all has the best performance, which remains almost constant as the length of paths increases. The shortcut-eachone has a significant tracing performance improvement with a moderate number of shortcut links, which can be used as an adequate shortcut adding schema.
Figure 9. Time costs of tracing logistics processing along shortcut links added in different schemas.

7. Conclusions

The SLN can represent logistics transports and can be published on the blockchain platform in a decentralized way to support decentralized traceability of the states of logistics transports. It has a good expressiveness in representing the locations of the logistics objects and states of logistics transports in a logistics process. By establishing the mapping between the states of links and the blockchain transactions, decentralized publishing and tracing of links and their states are implemented on the blockchain. The method for constructing shortcuts on link paths achieves a logarithmic number of accesses to nodes for obtaining links on a logistics transport path. The effectiveness of the proposed method is further verified by simulation experiments. A reward–penalty policy is designed for two participants to reach consensus on the confirmation of the state of links.
The SLN provides a general model for developing various domain applications by defining the schema of SLN and the schema of state transitions. Users can query the changing states on nodes and links and efficiently trace the changes through the user interface without the need to concern the storage of data at the physical and logical level. The function of publishing and querying links on blockchain can be encapsulated as basic graph data management operators to support the implementation of decentralized graph data applications on blockchain, enabling developers to focus on high-level graph data management through the developers’ interface without knowing the details of implementing the complex data model manipulation on the blockchain platform. The SLN has extensibility for implementing wide applications that need node and path querying on a semantically rich network based on reasoning on semantic links, which can be applied to logistics path prediction and optimization in smart cities. SLN also provides a semantic model for implementing decentralized and distributed application systems.

Author Contributions

Conceptualization, X.S., S.Z. and H.Z.; methodology, H.Z.; software, X.S. and S.Z.; validation, X.S., S.Z. and H.Z.; formal analysis, X.S. and H.Z.; investigation, X.S., S.Z. and H.Z.; resources, H.Z.; data curation, X.S. and S.Z.; writing—original draft preparation, X.S., S.Z. and H.Z.; writing—review and editing, X.S., S.Z. and H.Z.; supervision, H.Z.; project administration, H.Z.; funding acquisition, H.Z. All authors have read and agreed to the published version of the manuscript.

Funding

This research was funded in part by the National Natural Science Foundation of China grant number 61876048.

Data Availability Statement

Data will be available on reasonable request.

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. Allam, Z.; Newman, P. Redefining the Smart City: Culture, Metabolism and Governance. Smart Cities 2018, 1, 4–25. [Google Scholar] [CrossRef]
  2. Amiri, M.J.; Agrawal, D.; Abbadi, A.E. Permissioned Blockchains: Properties, Techniques and Applications. In Proceedings of the 2021 International Conference on Management of Data, Virtual, 20–25 June 2021. [Google Scholar]
  3. McConaghy, T.R.M.; Müller, A.; De Jonghe, D.; McMullen, G.; Henderson, R.; Bellemare, S. BigchainDB: A Scalable Blockchain Database. 2016. Available online: https://git.berlin/bigchaindb/site/raw/commit/b2d98401b65175f0fe0c169932ddca0b98a456a6/_src/whitepaper/bigchaindb-whitepaper.pdf (accessed on 20 April 2025).
  4. Treiblmaier, H.; Rejeb, A.; Strebinger, A. Blockchain as a Driver for Smart City Development: Application Fields and a Comprehensive Research Agenda. Smart Cities 2020, 3, 853–872. [Google Scholar] [CrossRef]
  5. Choi, T.-M.; Siqin, T. Blockchain in logistics and production from Blockchain 1.0 to Blockchain 5.0: An intra-inter-organizational framework. Transp. Res. Part E Logist. Transp. Rev. 2022, 160, 102653. [Google Scholar] [CrossRef]
  6. Politou, E.; Casino, F.; Alepis, E.; Patsakis, C. Blockchain Mutability: Challenges and Proposed Solutions. IEEE Trans. Emerg. Top. Comput. 2021, 9, 1972–1986. [Google Scholar] [CrossRef]
  7. Guo, L.; Wang, Q.; Yau, W.-C. Online/Offline Rewritable Blockchain with Auditable Outsourced Computation. IEEE Trans. Cloud Comput. 2023, 11, 499–514. [Google Scholar] [CrossRef]
  8. López-Pintado, O.; Dumas, M.; García-Bañuelos, L.; Weber, I. Interpreted Execution of Business Process Models on Blockchain. In Proceedings of the 2019 IEEE 23rd International Enterprise Distributed Object Computing Conference (EDOC), Paris, France, 28–31 October 2019. [Google Scholar]
  9. Zhuge, H. Communities and Emerging Semantics in Semantic Link Network: Discovery and Learning. IEEE Trans. Knowl. Data Eng. 2009, 21, 785–799. [Google Scholar] [CrossRef]
  10. Zhao, K.; Scheibe, K.; Blackhurst, J.; Kumar, A. Supply Chain Network Robustness Against Disruptions: Topological Analysis, Measurement, and Optimization. IEEE Trans. Eng. Manag. 2019, 66, 127–139. [Google Scholar] [CrossRef]
  11. Appel, S.; Kleber, P.; Frischbier, S.; Freudenreich, T.; Buchmann, A. Modeling and execution of event stream processing in business processes. Inf. Syst. 2014, 46, 140–156. [Google Scholar] [CrossRef]
  12. Combi, C.; Oliboni, B.; Zerbato, F. Integrated Exploration of Data-Intensive Business Processes. IEEE Trans. Serv. Comput. 2023, 16, 383–397. [Google Scholar] [CrossRef]
  13. Biswas, D.; Jalali, H.; Ansaripoor, A.H.; De Giovanni, P. Traceability vs. sustainability in supply chains: The implications of blockchain. Eur. J. Oper. Res. 2022, 305, 128–147. [Google Scholar] [CrossRef]
  14. Menon, S.; Jain, K. Blockchain Technology for Transparency in Agri-Food Supply Chain: Use Cases, Limitations, and Future Directions. IEEE Trans. Eng. Manag. 2024, 71, 106–120. [Google Scholar] [CrossRef]
  15. Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008. Available online: https://bitcoin.org/bitcoin.pdf (accessed on 20 April 2025).
  16. Munasinghe, U.J.; Halgamuge, M.N. Supply chain traceability and counterfeit detection of COVID-19 vaccines using novel blockchain-based Vacledger system. Expert Syst. Appl. 2023, 228, 120293. [Google Scholar] [CrossRef] [PubMed]
  17. Dinh, T.T.A.; Liu, R.; Zhang, M.; Chen, G.; Ooi, B.C.; Wang, J. Untangling Blockchain: A Data Processing View of Blockchain Systems. IEEE Trans. Knowl. Data Eng. 2018, 30, 1366–1385. [Google Scholar] [CrossRef]
  18. Cui, J.; Ouyang, F.; Ying, Z.; Wei, L.; Zhong, H. Secure and Efficient Data Sharing Among Vehicles Based on Consortium Blockchain. IEEE Trans. Intell. Transp. Syst. 2022, 23, 8857–8867. [Google Scholar] [CrossRef]
  19. Li, X.; Jiang, P.; Chen, T.; Luo, X.; Wen, Q. A survey on the security of blockchain systems. Futur. Gener. Comput. Syst. 2020, 107, 841–853. [Google Scholar] [CrossRef]
  20. Salman, T.; Zolanvari, M.; Erbad, A.; Jain, R.; Samaka, M. Security Services Using Blockchains: A State of the Art Survey. IEEE Commun. Surv. Tutorials 2019, 21, 858–880. [Google Scholar] [CrossRef]
  21. Amiri, M.J.; Agrawal, D.; El Abbadi, A. SharPer: Sharding Permissioned Blockchains Over Network Clusters. In Proceedings of the 2021 International Conference on Management of Data, Virtual, 20–25 June 2021. [Google Scholar] [CrossRef]
  22. Kalajdjieski, J.; Raikwar, M.; Arsov, N.; Velinov, G.; Gligoroski, D. Databases fit for blockchain technology: A complete overview. Blockchain: Res. Appl. 2022, 4, 100116. [Google Scholar] [CrossRef]
  23. Wang, Z.; Wang, T.; Hu, H.; Gong, J.; Ren, X.; Xiao, Q. Blockchain-based framework for improving supply chain traceability and information sharing in precast construction. Autom. Constr. 2020, 111, 103063. [Google Scholar] [CrossRef]
  24. Liu, Z.; Li, Z. A blockchain-based framework of cross-border e-commerce supply chain. Int. J. Inf. Manag. 2020, 52, 102059. [Google Scholar] [CrossRef]
  25. Hader, M.; Tchoffa, D.; El Mhamedi, A.; Ghodous, P.; Dolgui, A.; Abouabdellah, A. Applying integrated Blockchain and Big Data technologies to improve supply chain traceability and information sharing in the textile sector. J. Ind. Inf. Integr. 2022, 28, 100345. [Google Scholar] [CrossRef]
  26. Zarrin, J.; Phang, H.W.; Saheer, L.B.; Zarrin, B. Blockchain for decentralization of internet: Prospects, trends, and challenges. Clust. Comput. 2021, 24, 2841–2866. [Google Scholar] [CrossRef]
  27. Ng, W. Developing RFID database models for analysing moving tags in supply chain management. In Proceedings of the 30th International Conference on Conceptual Modeling (ER’11), Brussels, Belgium, 31 October–3 November 2011; Springer: Berlin/Heidelberg, Germany, 2011; pp. 204–218. [Google Scholar]
  28. Lu, Q.; Xu, X. Adaptable Blockchain-Based Systems: A Case Study for Product Traceability. IEEE Softw. 2017, 34, 21–27. [Google Scholar] [CrossRef]
  29. López-Pintado, O.; García-Bañuelos, L.; Dumas, M.; Weber, I. Caterpillar: A Blockchain-Based Busi-ness Process Management System. In Proceedings of the International Conference on Business Process Management, Barcelona, Spain, 10–15 September 2017. [Google Scholar]
  30. Zhu, P.; Hu, J.; Li, X.; Zhu, Q. Using Blockchain Technology to Enhance the Traceability of Original Achievements. IEEE Trans. Eng. Manag. 2021, 70, 1693–1707. [Google Scholar] [CrossRef]
  31. Zhuge, H. “Semantic Link Network” in The Knowledge Grid: Toward Cyber-Physical Society; World Scientific Publishing Co.: Singapore, 2012. [Google Scholar]
  32. Zhuge, H. Cyber-Physical-Social Semantic Link Network. In Cyber-Physical-Social Intelligence: On Human-Machine-Nature Symbiosis; Springer: Singapore, 2020; pp. 55–141. [Google Scholar]
  33. Zhuge, H. Multi-Dimensional Summarization in Cyber-Physical Society; Elsevier: Amsterdam, The Netherlands, 2016. [Google Scholar]
  34. Ikkai, Y.; Maruta, T.; Komoda, N.; Goossenaerts, J. A Graph-Base Supply Chain Simulation Language and Tool with Multi-Functional Modeling. IFAC Proc. Vol. 2000, 33, 935–940. [Google Scholar] [CrossRef]
  35. Wu, H.Y.; Yang, X.; Yue, C.; Paik, H.-Y.; Kanhere, S.S. Chain or DAG? Underlying data structures, architectures, topologies and consensus in distributed ledger technology: A review, taxonomy and research issues. J. Syst. Arch. 2022, 131, 102720. [Google Scholar] [CrossRef]
  36. Rosenfeld, A.; Goldman, C.V.; Kaminka, G.A.; Kraus, S. PHIRST: A distributed architecture for P2P information retrieval. Inf. Syst. 2009, 34, 290–303. [Google Scholar] [CrossRef]
  37. Wu, H.; Jiang, S.; Cao, J. High-Efficiency Blockchain-Based Supply Chain Traceability. IEEE Trans. Intell. Transp. Syst. 2023, 24, 3748–3758. [Google Scholar] [CrossRef]
  38. Zhuge, H.; Chen, X.; Sun, X.; Yao, E. HRing: A Structured P2P Overlay Based on Harmonic Series. IEEE Trans. Parallel Distrib. Syst. 2008, 19, 145–158. [Google Scholar] [CrossRef]
  39. Owe, O.; Fazeldehkordi, E. A lightweight approach to smart contracts supporting safety, security, and privacy. J. Log. Algebraic Methods Program. 2022, 127, 100772. [Google Scholar] [CrossRef]
  40. Song, Q.; Chen, Y.; Zhong, Y.; Lan, K.; Fong, S.; Tang, R. A Supply-chain System Framework Based on Internet of Things Using Blockchain Technology. ACM Trans. Internet Technol. 2021, 21, 1–24. [Google Scholar] [CrossRef]
  41. Li, C.; Zhang, J.; Yang, X.; Youlong, L. Lightweight blockchain consensus mechanism and storage optimization for resource-constrained IoT devices. Inf. Process. Manag. 2021, 58, 102602. [Google Scholar] [CrossRef]
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Article Metrics

Citations

Article Access Statistics

Journal Statistics
Multiple requests from the same IP address are counted as one view.
Download PDF
Novel Machine Learning-Based Smart City Pedestrian Road Crossing Alerts
Previous
QESIF: A Lightweight Quantum-Enhanced IoT Security Framework for Smart Cities
Next