1. Introduction
The potential of logistics, which are vital contributors to most industries and countries, depends on their power to react to their customers’ expectations while preserving a competitive advantage in their marketplace. A disruption in one company can affect multiple companies in the network. When an unplanned and unanticipated event occurs, the normal flow of goods is disrupted, which has urgent consequences for the costs and profitability and long-term consequences for the brand image and customer satisfaction level. Therefore, the performance of supply chains is highly sensitive to risks in the network [
1]. This supply chain problem was more apparent during COVID-19. Companies and transportation hubs have been closed, new safety protocols implemented, the movement of employees restricted, and customer needs and demands have changed. No region or industry has been immune to these effects.
To overcome this challenge and minimize the risk of supply chains, some enterprises invest more in the hubs, resources, digitalization, inventories, health workers, safety, etc. [
2]. Another solution is sharing economics which opens doors to other retailers or logistic service providers. For instance, Walmart recently announced the launch of a delivery service called GoLocal, which will carry goods from other local retailers to consumers [
3].
Sharing economy is a key solution to achieving fast, high-quality service. Besides, it could be the best solution to the predicated and unpredicted risk of supply chains. The sharing economy has already transformed several industries through the popularity of apps such as Mobility and Hospitality. The sharing economy will assist logistics, and it allows all contributors to share secure costs, enabling businesses to make several slighter investments rather than a single large investment, which would lead to rationalizing logistics work, improving work efficiency at delivery points, and cutting transport costs and environmental impact, compared with the conventional systems [
4,
5].
The need for sharing logistics has never been so imperious, especially since the growth of risk and uncertainty has become a serious problem. To quench their thirst for the fast delivery of parcels, small, mid-size enterprises (SMEs), and large enterprises are turning to sharing resources. Generally, sharing logistics is recognized as a significant business strategy by [
6], in which supply chain entities work collaboratively on a short-term basis to deliver parcels, advanced by digitalization which is the mainstay of supply chain 4.0.
In this respect, researchers expand the concept of open logistics and manufacturing as sharing assets, services, spaces, and workers between business processes across internal or external partners in the value chain [
7,
8]. Soon Hong Min et al. [
9] explained that the sharing economy has been referred to as the driving force behind effective supply chain management and may be the best core capability for overcoming the risks. However, the sharing economy could dramatically increase the risk of malicious attacks, and, accordingly, induces trust problems between multiple hyperconnected service providers. The current challenges of the sharing economy for supply chains are explained as follows.
Information security is invariably the main apprehension in effective collaboration. The supply chain industry is presently experiencing its own digital transformation in the form of SC4.0, where cyber-physical systems combine the physical world and digital networks to effect change. However, SC4.0 hosted a complete novel variety of safety and security issues. These security issues range from simple threats which can be easily mitigated or even ignored, to very complex threats that can render the whole system unusable [
10].
Trust and Transparency. Mutual trust and protection must be maintained between all parties in the sharing economy to guarantee a high quality of service, mitigate disputes, handle payments securely and, most importantly, encourage engagement of users and service providers. For example, in the business-to-business sharing logistics model, counterfeits and payment disputes are major issues [
11].
Liability and Insurance. The sharing logistics can be fraught with risks and liability. There is a risk that the goods or services are being shared with a lower standard quality than expected or could cause physical damage to the service requester. For the service provider, the highest risk is theft, loss, or damage. Since the platforms do not own the assets, there is little incentive initially for the platform providers to ensure goods or services. Today, users and service providers must typically ensure themselves and ask their insurers to find the best individual solution.
Interoperability and data sharing problems. There is a shortage of sharing asset and resource protocols and standards to integrate, interoperate and share the data along the supply chain process [
12]. Many interoperability and data sharing problems exist between the resource share entities. Traditionally, it has been addressed with “point-to-point” solutions and standards [
13]. However, it can hardly be widespread by the multiple collaborative parties due to the trade secrets, regional policies, etc.
Recently a novel peer-to-peer technology has been introduced for manufacturing and supply chain industries as blockchain, which can omit third parts and improve the security of the system. In this respect, a trustable collaboration platform is proposed based on blockchain and fog computing to reduce the gap between designers, customers, and manufacturers aiming to introduce an open manufacturing concept that causes interoperability and data sharing problems to improve [
14]. Blockchain-based distributed logistics platform is introduced with the power of distributed IoT nodes and offers an alternative approach to dealing with the complexity of modern supply chains by breaking them into smaller, functionally independent parts [
15]. Abir EL Azz et al. [
16] proposed the implementation of blockchain and smart contracts with the information hiding technique to enhance the security and privacy of data communication in the healthcare supply chain. Also, Tarun Kumar Agrawal et al. [
17] proposed a blockchain-based traceability framework for the textile and clothing industry. It is obvious that integrating blockchain technology into the logistics could be a potential solution. This paper attempts to raise the concept of Open Logistics (OL), a Blockchain-enabled, trustable hyperconnected logistics platform.
In this paper, we propose an OL platform to improve trust between parties and data transparency which is the main factor in achieving trustable assets and resource sharing in the sharing economy. Following the OL platform architecture, a practical roadmap is provided for the parcel logistics to achieve blockchain design, development, application, and evaluation. Moreover, three core enabling components are presented: (1) Network structure and blockchain-based software-defined networking layer, (2) Smart contract-based proof of delivery, and 3) Blockchain asset and resource sharing service.
This paper contributes to the logistic industry in the following three aspects. (1) It presents a blockchain-enabled sharing assets framework and its mechanism to realize a secure, interoperable, and feasible cooperation mode. (2) It provides a versioning smart contract-based concept to explore the PoD concept and control among the assets, workers, and materials, as well as the parties. (3) It develops an open logistics platform that could be used in existing paradigms.
The rest of this paper is organized as follows.
Section 2 presents a review of the related research.
Section 3 presents the overall architecture of the open logistics, as well as its core components.
Section 4 describes the main components and mechanism of open logistics.
Section 5 discusses the case study and implementation of open logistics.
Section 6 covers the results and discussion, and
Section 6 provides the conclusion and recommendations for further research.
3. The Architecture of the Open Logistics
This section presents OL architecture, working process, and enterprise blockchain network structure for OL. The architecture is shown in
Figure 1. It contains four layers, including distributed cloud layer (DC), Blockchain-based Software-Defined Networking (BSDN) layer, edge layer, and industrial IoT device layer (IIoT), which are connected to physical resources. In addition, these four layers connect with the enterprise Block Chain Network (eBCN). DC layer provides data storage, computing power, and blockchain infrastructure. The edge computing layer is responsible for connecting and providing limited computing power to industrial devices to provide real-time communication, and the IIoT layer directly connects with industrial devices and offers a direct bridge between the edge computing layer and industrial devices. BSDN is responsible for delivering the cooperation of different network devices. The blockchain network provides a peer-to-peer network, decentralization, trust, and governance to OL. Therefore, the OL accelerates the development, governance, and operation of a multi-institution business network. Each layer and component is defined as follows.
3.1. Distributed Cloud Layer
The DC layer has geographically dispersed infrastructure that primarily runs services at the network edge. This is different from the theoretical cloud model that relies on a centralized data center. The DC layer includes cloud data centers and computing power belonging to various cloud providers. The DC provides long-term storage and computing power to each sector that is typically less time-sensitive. In other words, the capability of this layer would be using cloud infrastructure to run big data interactions or processes in less time-sensitive data. The main components of the DC located in the cloud network area are Data Storage, Computing power, Membership, Ledger, Smart contract, API, Miner, Consensus, Events, and Connectivity.
Table 1 explains each of these key components in detail.
Figure 2 shows the key components diagram and network specification of OL. In this configuration, a logistic service provider can deliver and share assets more rapidly, reliably, and securely. The OL platform supported three types of networks. Each network is defined as follows.
Cloud Network: This is the high-level network that gives users access to computing resources through a provider operating inter-connected servers. This involves connecting to an enterprise blockchain network and helps distribute content quickly and securely. This network provides connectivity between miner nodes in the blockchain. Cloud service provider helps organizations deliver content more rapidly, reliably, and securely.
Public Network: The Public Network holds the different networks (typically the Internet), peer cloud systems, and edge services. For example, a service user uses a public network to connect to a cloud network to use services.
Enterprise network: The enterprise network is included in the user directory, enterprise applications, and enterprise data. For example, each distribution center has its enterprise network, which is connected to a cloud network via a blockchain-based software-defined network.
3.2. Blockchain-Based Software-Defined Networking Layer
Software-Defined Networking (SDN) and Network Functions Virtualization (NFV) are emerging and considered new ways of designing, building, and operating networks. These two complementary technologies can support data transition between edge nodes and cloud computing. This layer improves the dynamism of the network. For example, it is possible to change the path through which data flows between the cloud computing layer and the edge computing layer. BSDN uses a hash function instead of heavy cryptography algorithms. Therefore, BSDN can improve flexibility and performance compared to traditional SDN. This layer contains 3 planes, namely, the application plane, control plane, and data plane. It is also coupled with blockchain technology.
The application plane is an open but secure policy for various applications and devices to leverage network resources like topology and statistics. Different applications can communicate with each other and the controller via APIs and peer-to-peer communication, powered by enterprise blockchain technology.
The control plane or network brain acts as an operating system. It is a logical entity that receives instructions or requirements from the application plane and relays them to the networking components. This plane also extracts information about the network from the hardware devices and communicates back to the applications with an abstract view of the network and includes statistics and events about what is happening. The control plane system then will be programmed by the top layer using “Northbound API” or “RESTful API”.
The data plane or user plane is the part of a network that carries user traffic. It enables data transfer to and from IoT or any smart devices. Generally, it includes packet forwarding devices and communications with the network controller.
The blockchain is used as a service that provides functionalities of resource tracking and asset sharing among multiple controllers on the control plane. Therefore, resource tracking is used to track and trace the network resources of each controller and asset.
3.3. Edge Layer
The edge layer provides real-time connectivity and limited computing power, representing the perspective of industrial devices. It brings memory and computing power close to the needed industrial device. Edge nodes represent gateways and data capturing services. This layer is where the cloud resources are being distributed and moved near to the end-users and end devices. The reasoning for using edge nodes is to evaluate time-sensitive data closer to the location where data flows are collected, hence taking some of the computational load off the resources at the cloud computing layer and decreasing network load. In an early warning system, these nodes consist of services to receive data over an explicit link from devices, filter the input data stream, aggregate the measured values and send the data to the cloud computing layer. Hence, an edge computing layer can reduce significant traffic from the core network. That is why OL provides low latency and location awareness and optimizes users’ experience under quality-of-service requirements for time-critical and even real-time applications. So, the OL has the characteristics of decentralization and real-time change and involves networking and the mechanism of communication between nodes.
3.4. Device Layer
The device layer or IIoT layer provides ubiquity connections with industrial devices or service users. This layer is responsible for data transferring between the drives (machines and robots) and the service providers in a real-time manner. Physical components such as a robot, truck, or trailer can remotely control or send and receive data. IoT devices are connected with an autonomous agent. This node connects to OL via membership verification. This connection is long-lasting, and each node needs membership verification; this connection is explained in reference [
28].
5. Simulation Platform
The resource-sharing platform involves a significant number of different resources and assets which are associated with various third-party service providers (3PL), such as trucks, trailers, material-handling systems, and storage systems. Analyzing this type of system in a real environment is infeasible because of the long period that would be required for the development of resources for each service. It is also very difficult to test the multiple scenarios when attempting to compare alternative solutions. One way of overcoming this problem is to use a simulation platform that behaves like a real system. We developed a simulation platform to evaluate the potential benefits of employing OL.
Figure 6 illustrates the developed simulation platform with its three main components. The main advantage of this simulation platform is that it can distinguish the software level from the hardware level. Therefore, as with the real implementation, each service has three different entities in this simulation platform: (1) the agent inside the physical simulation module, which simulates the capability of the hardware and local decisions such as a vehicle, ASRS, robot, etc. (2) the communication channel for each specific service which is responsible for transaction between OL module and physical simulation module. (3) the OL module is an implementation of the proposed platform.
5.1. Physical Simulation Module
In this section, we consider a process of sharing truck and swap drivers in the transportation hub as a case study. Logistics resource (e.g., truck and drivers) sharing between service providers has been common in recent years. Still, different companies make different decisions about providing logistics services or sharing. We consider three suppliers with multiple 3PL service providers. After the performance of each service, the PoD will be sent to the service requester and service provider. The most important information between supplier (service user) and 3PL service provider is defined in
Table 2. This physical simulation module simulates product delivery in the USA. The supply chain includes four manufacturing facilities and ten distribution centers that order a random amount of the product every 1–3 days. Three 3PL carrier companies provide delivery services between the manufacturers and distribution centers. When a manufacturing facility receives an order from a distributor, it checks the number of products in storage; then, it signs the smart contract with the distributor if the required amount is available. Then it sends a delivery request to carrier companies. The first company to complete the mining task will be awarded a delivery contract. The reward carrier company signs the smart contract with the manufacturer to perform the service. We consider four 3PL service providers for the last mile delivery task. So, when the customer purchases the product, the nearest distribution center receives the request, then checks the product availability. If the requested product is available, then the distribution center sends a last-mile delivery request to service providers. The first last-mile delivery company which completes the mining task will be awarded a last-mile delivery contract. The rewarded last-mile company signs the smart contract with the distribution center to perform the service. All PoDs of services are then shared with service users and service providers.
This model is essentially a multi-model. Distributors, 3PL, trucks, resources, and manufacturing facilities are agents with customer behavior. Agents live in a GIS (Geographic information system) space. GIS search engine is used to find locations on the map and place agents there. Trucks move on real roads, and routes are created when vehicles start moving to destinations. Customers located near each distribution center, considering a maximum five-hour distance.
The carrier service is performed by truck with 1000 product capacity from supplier to distributor, which takes 6 h (the average time of all drives). Each loading and unloading process action needs 20 min (the average time of all processes). For each product, the processing time for packaging and shipping was 10 min, and the queue time for the AVG in the line was three minutes. Each product was assumed to be sent to a different destination and required a separate packaging processing time. The last-mile delivery time for each package was normal distribution with a mean of 4 h and a standard deviation of 5. And we consider 5000 parcels for each day needed to deliver to the customer. The capacity of a truck for last-mile delivery is 500 products, and we assume this number is fixed for all last-mile delivery services. The tests considered five days of working hours. The adapted time unit was 1/150th of a minute, the standard time data provided.
5.2. Implementation of OL
To develop OL by Hyperledger Fabric, we set up a multi-host blockchain network with three physical machines. We created OL with one Orderer organization and six peers’ organization.
Figure 7 shows the developed blockchain network. Peers E0 and E3 connect to the Cyan channel for chain codes C and D, and peers E2 and E1 connect to the Red channel for chain codes; A and B, and peers E4 and E5, connect to the Pink channel for chain codes E and F. We implemented a smart contract with a following endorsement policy appropriate to peers. We also implemented practical Byzantine fault tolerance (pBFT) as a consensus algorithm.
Implementation of Proof of the Delivery and Smart Contract
The proposed PoD system contains two main elements Nodes and Smart contracts. Each element is explained as follows:
Node: A user who uses a mobile, web application, or IoT to connect OL via a public network or enterprise network. We clustered this user into two main types, namely user node (UN) and provider node (PN). The node that requests a service is called a UN. Any participant who will accomplish the service by fulfilling all the requirements is called a PN. All the nodes will have to take the authorization process to utilize the system and have a user interface to update their capabilities. This process is accomplished by registering themselves in the system. each node has the following attributions:
N is the unique node ID
LocN is the location of the node on the map (attitude and longitude).
TN is the latest time at which the node participated in any services.
SN is the status of the node (e.g., busy, or available).
Csn is a class of service provided to OL by node NP.
Crn is a class of service request by Node NU.
Ssid is a unique id for each service in the system.
Cpid is the current satisfaction point of the service.
Locid is the location where the service needs to be performed.
Rid is a unique resource or assets id (truck ID or drivers ID) which performs the specific service and corresponds to the BASS.
Raid is the status of a resource that performs a specific service.
LocR is the location of the resource that performs the service.
The UN can request service at the OL respective to time, location, and cost. The UN must provide the service location, the due date of service, number of needed services and budget for service, service type (e.g., last-mile delivery, distribution center), service description, and minimum requirements of the NP to perform this service. A smart contract is an agreement between the UN and NP. The contract runs automatically according to predefined rules and protocols. Algorithm 1 shows the specific action of the smart contract between UN and UP, which is named an internal contract. The output of this algorithm is a contract between NUs.
Algorithm 1. Smart contract between UN and carrier NP |
Input: UN, UP, Sn, LocN |
Output: The updated contract state between NU and NP |
1: if (Crn == Csn) |
2: if (Sn == available && Locid == LocR) then |
3: if (Ssid != create) then |
4: Let Ssid = ServiceToBeCreated.NP; |
5: NP initiates to create |
6: Request sends to NP; |
7: else if (Ssid ==create && accepted by NP) then |
8: Ssid update & service sent to UN by NP; |
9: else if |
10: Show an error and update contract state |
11: else |
12: Show an error and update contract state |
13: end |
Algorithm 2 shows the internal smart contract inside NP between manager and resources.
Algorithm 2. Smart contract for internal NP and update ststus to NU |
Smart contract 2: Resource state for internal- NP |
Input: Raid, NP, Sn, LocR, Ssid |
Output: The updated contract state of newest resource state |
1: if (NP == NP1) then |
2: if (Raid != Updateby Ssid) then |
3: if (outcome== True) then |
4: Let Raid = Intra- Ssid |
5: Create and send a notification about the start of the service. |
6: else if |
7: Next step cannot start, update status to the system |
8: else if |
9: Show an error and update contract state |
10: else |
11: Show an error and update contract state |
12: end |
In this study, all chain code (smart contract) is written in the GO language, and the OL mainly permits the authorized node to operate the system. To request a service or to receive a service. After completion of the registration process, the OL will provide a unique user identity (User ID) to the user. However, there might be several malicious users who can exploit the system by creating fake user identities. This kind of intrusion is called the Sybil attack. To prevent a Sybil attack, the participant should submit an identification card and must be approved by the other members of the OL.
5.3. Communication Module
This module is responsible for providing the interaction between the agent in the physical simulation module and OL.
Figure 8 shows how agents in the physical module interact with peers to retrieve the ledger in the OL module. Ledger request connections involve a simple three-step dialogue between an agent and a peer. Ledger update interactions are a little more involved and require two extra steps. Agents connect to peers when they need to access ledgers and smart contracts. Via a peer connection, agents can execute smart contracts to query or update a ledger. The result of a ledger query transaction is returned immediately, whereas ledger updates involve a more complex interaction between agents, peers, and orderers. In
Figure 8, agent A links to P1 and evokes smart contract S1 to inquire or update the ledger L1. P1 evokes S1 to create a response proposal that contains a query result or a ledger update. When agent A gets the response, then the process is completed. After that, for updates, agent A creates a transaction that contains all responses, then transmits it to O1. O1 accumulates transactions through the network into blocks and distributes these to all peers. When transactions are sent to P1 via O1, P1 validates the transaction, then applies to ledger L1. Once L1 is updated, P1 generates an event received by A to signify completion.
5.4. Results and Discussion
For evaluation and validation of OL based on the case study, we first investigate the result of the case study, then test the performance of the core OL network.
5.4.1. Result of Case Study
We evaluated the case study based on the two main KPIs: response time (RT) and service usage rate (SUR). RT is the total amount of time it takes to respond to a request for service. RT represents the response time between the service requester and 3PL. We compute the RT from the request initialization until 3PL accepts and signs the smart contract. In this step, we simulated for five days and collected data for 5000 daily orders. The transaction size, block size, and response time are shown in
Table 3. We can highlight two key results from this table. First, the transaction size and block size directly affect the RT. Second, the block size of service for the internal distribution center is much larger than other services because we considered all services in one block, and multiple smart contracts need to sign simultaneously.
SUR represents whether the manufacturer or distribution center can control the requested service (resource sharing). If the utilization rate is high, the service requester can communicate with the 3PL in time and obtain updated information. If the information-sharing efficiency is low, the service requester cannot know in time which 3PL has the idle resources. As a result, manufacturers or distribution centers cannot make immediate arrangements, which may hold products in manufacturers or distribution centers for a long time. For the 3PL, if the manufacturer or distribution center fails to request service in time, resulting in a low SUR, it will reduce the economic efficiency of the 3PL. For the 3PL, when the manufacture or distribution center still needs service, but the SUR is still low, the manufacture or distribution center and the 3PL have low information sharing capacity and low communication efficiency, which will also reduce the cost economic efficiency of the 3PL. The statistical results are shown in
Figure 9. The result shows that the SUR is very low at the first 6 h, but after 12 h, the SUR normally is more than 80 percent. This happens because we didn’t consider the warming time in the system.
5.4.2. The Core OL Network Evaluation
The performance analysis of the core OL network was conducted to evaluate the impact of transaction size on transaction response times, known as latency. Latency is one of the main key KPIs to evaluate the performance of the blockchain network in the platform. We consider three types of transaction time to deliver a wide-ranging assessment of latency, hash creation time, transaction to block via agents, and service endorsement time.
Figure 10 presents a surface chart of the latency of various transaction sizes, ranging from 10 kB to 400 kB. We consider this range because it can support all transactions in the OL. It proves the trend that the total time increases with the transaction sizes. Moreover, the increasing rate enlarges when the total transaction size is over 150 KB, which provides insights for block size configuration to enable an OL with high performance.
There are three key points in this chart.
- I.
It clears that the size of the transaction is related to the time of the transaction. A larger transaction indicates a longer hash creation time, upload transaction to block via agent time, and service approval transaction time. The results show that transaction size influences the standard deviations of times, which generates a greater impact on upload transactions to block time.
- II.
A huge difference exists between 100 KB and 150 KB transaction sizes, showing that the network will face a latency problem if the transaction size is more than 150 KB. So, the best transaction for the OL is between 5 KB to 100 KB.
- III.
The total time of the transaction for block sizes 300 and 400 is quite high. This rise in transaction time creates instability in the system. Therefore, each operation concerning a transaction size greater than 250 KB brings unpredictability to completing the requested operation. Therefore, we suggested setting the block size as 150 kB to guarantee a stable and high performance in the OL.
Figure 11 denotes the monitoring data. In this figure, we show the results of two main KPIs of the OL environment. These indicators include CPU utilization and network in. These results show that the OL can support real applications without status failed issues and require less CPU utilization. Therefore, the developed network has an acceptable level of scalability for big data support.
We recorded the network operation of the number of committed blocks every minute for all experiments.
Figure 12 shows the number of committed blocks for different block sizes. We categized these results by considering the different numbers of nodes in the network 5, 10, 15, and 20, respectively. The number of transactions is 5, 10, 15, 20, and 25 per second. The result shows that the network’s performance is reduced by increasing the number of transactions. Nevertheless, when increasing the number of nodes to 15 and more, the network performs differently. With 15 nodes block committed to 10 ts is more than 5 ts. For example, in the first 10 min of simulation, 175 blocks are committed to 10 ts transactions, a number 20 more than 5 ts. Better performance is observed when committing 20–25 transactions to a block than when committing 5–10 transactions to a block for the network of 20 nodes. The frequency of generating new blocks is inversely related to the block size if a small block size and a constant transaction generation period are used. Increasing the frequency of block generation leads to an increase in the number of transactions within the protocol, most of which are sent from each node to all others. As a result, the network becomes overloaded, reducing performance and leading to a decrease in the number of committed blocks.
5.4.3. Qualitatively Analysis
The proposed platform is compared qualitatively with two main existing platforms, including traditional sharing and web-based sharing platforms. According to the existing definitions for sharing platform characteristics presented in the literature, some common key characteristics, such as scalability, that is, the ease to use or customize and learnability, privacy, tractability, and security, are selected and compare the proposed OL with the other existing platform. Besides, some criteria reflecting the cost are also illustrated, such as transaction speed. The result of this comparison is shown in
Table 4. It is clear that the OL, due to the advantages of blockchain-enabled technology and a smart contract-based service sharing model, could provide better security, liability, and transparency to all stockholders, which improves the trustability of the whole system.
6. Conclusions and Discussion
Asset and resource sharing among partners in a supply chain is commonly considered a key factor in enhancing supply chain performance. Sharing logistics improves efficiency at delivery points and cuts transport costs and environmental impact. However, due to the lack of trust and arising security issues of shared resources, the companies didn’t rely on the third-party services provider.
The open logistic network platform can speed up the delivery cycle and reduce the associated cost of delivery and product storage. On the one hand, trustworthy and transparent service sharing can effectively use the slack supply chain resources to increase the utilization of the facilities and manpower of the supply chain and logistic systems. On the other hand, secure data sharing among companies can help them focus on their core competencies. In addition, blockchain and smart contract asset sharing mechanisms enable a secure and standardized approach to achieve a higher level of sharing among stockholders. Furthermore, the edge computing approach improves flexibility and brings extra distributed networks to the supply chain environment, which is highly aligned with SC4.0.
In this paper, we attempt to solve the main problems of sharing resources and assets in logistics. We propose a novel blockchain-enabled resource and asset sharing platform for realizing data exchange and service sharing in logistics based on blockchain and edge computing technology and named it OL. Firstly, we provided the OL computer and network architecture, then the key components and mechanism of OL were explained in detail. The proposed platform supports an open, decentralized, yet secured network and a new type of proof-of-delivery for transparency of resource sharing. An experimental simulation was conducted in the context of B2C logistics, and the feasibility of the proposed platform was evaluated via different and suitable KPIs.
The expected benefits from the OL platform include: (1) The new PoD based on the smart contract helps the 3PLs effectively track and trace their resources and assets, easily improving trust, payment liability, and insurance problems. (2) The OL platform, with the help of AI, would improve information security and a trustworthy connection to IoT devices. (3) The OL platform would provide the distributed computing power, which is interoperable with the enterprise and public network.