Blockchain-Based Diversion-Point System for Balancing Customer Flow in Shopping Mall

Abstract

Changing the store layout of a shopping mall is usually costly in terms of time, resources, and money. Balancing customer flow is obviously an economical way to rationalize the store layout without displacing stores or changing their locations. However, it has long been a big challenge for managers of shopping malls, because it is difficult to build trust among stores for the sake of regulating customer flow. This trust depends on a multi-party cooperation model, of which the agreements are implemented on asymmetric information. Unfortunately, any form of endorsement with human intervention cannot support building trust on asymmetric information. To solve this problem technically, this paper proposes a diversion-point system to dynamically divert part of customer flow from popular stores to less popular ones. The system operates diversion-points and -vouchers on an asymmetric basis. It also employs a Blockchain subsystem to replace the centralized endorsement and preserve the information asymmetry, thereby building trust into the cooperation among customers, the shopping mall, and the stores therein. The evaluation shows that the proposed system is effective in remedying imperfect store layout of the shopping mall.

1. Introduction

Shopping malls are still irreplaceable kernels of modern city’s commercial districts, though e-commerce has greatly changed people’s daily consumption habits. So far, only in shopping malls can consumers enjoy a full range of one-stop services [1]. Shopping malls are constantly upgrading their services to retain and attract more customers so as to cushion the market shocks brought by e-commerce [2]. Therefore, the technological innovation that can be introduced into shopping malls is of high practical value.

One of the problems plaguing mall managers is how to tinker with store layouts that have been relatively stable since they were initially constructed [3]. A common bad situation is that some popular regions are crowed with customers while others are left out in the cold (see Figure 1). This situation usually results from just a mixed bag of the geographical locations of stores [4]. The merchants of those neglected stores may feel that the shopping mall is not conducive to the development of their brands, while the mall manager may blame those stores for their poor contributions to profits. Intuitively, it might be useful for the shopping mall to displace those stores or change their locations. However, doing so will be costly in terms of time, resources, and money. Therefore, seeking for soft and economical solutions is of great business value.

Balancing customer flow is one of such solutions. It refers to reducing the gap in customer flow between stores with different spatial locations. Some marketing tools such as advertising, coupons, and shopping points are common ways to increase customer flow, but do little to balance it [5]. This is because simply increasing the number of customers will only further widen the gap in customer flow between stores. In addition, those coupons and shopping points are quite under-utilized due to their lack of value in the minds of customers [6]. Some stores may use IT tools, such as customer relationship management (CRM) systems, online marketing platforms, data analysis systems, and social media, to individually promote their customer flow, but the efficacy, from the overall benefit of shopping malls, of those IT tools is beyond the macro control of mall managers [5,7]. Therefore, an integrated solution combining new marketing modes and technical support is urgently needed. However, the research in this area remains a blank.

Counterintuitively, information asymmetry is the basis of balancing customer flow in shopping malls. Let us suppose that both players in the Stag Hunt Game [8] are selfish in profit distribution. If they both know that the stag is very likely to end up being unevenly distributed, they will be reluctant to cooperate. In a similar way, each store wants to maximize its profits, but some of them will be overcautious about sharing customer flow with other stores. In fact, balancing customer flow does not take customers away from stores. In contrast, it will be a way to promote customer flow or even customer loyalty of a store, as long as the store can provide customers with valuable offers which make the store more attractive. However, the immediate consequence of balancing customer flow must be that some get high returns while others get low returns. If all stores can see the same information about the differences on the adjusted customer flow, some of them may develop a psychology of horizontal comparison, causing the risk-dominant equilibrium [9] to be easier to reach. Therefore, information asymmetry needs to be preserved and properly used.

However, any form of endorsement with human intervention cannot support building trust in cooperation under asymmetric information. This is because no one will trust in the cooperation controlled by one of its parties, since the party has the opportunity to benefit from collusion with others under the cover of information asymmetry. As one of the stakeholders cooperating with stores and customers, the shopping mall is obviously not eligible to play the role of endorser. We thus need a decentralized mechanism to ensure that no one has access to too much power when balancing customer flow.

Blockchain [10] is a distributed storage technology for developing decentralized applications that center on asset security [11]. Its striking features of tamper-resistance and collective maintenance are of great appeal to many application cases [12]. Therefore, Blockchain is predicted to challenge existing business models and offer opportunities for new value creation [12]. A Blockchain-based Bonus Point Alliance in shopping malls was introduced in [13]. The authors took the “alliance blockchain” as a form of organization to design a full technical solution which solved the shortcomings of traditional alliance, such as the high cost of development and the difficulties in bonus points circulation. Toward the problems of paper-based coupons on the lost-prone carrier and the complicated payback process, Bülbül et al. [6] proposed the Promotion Asset Exchange (PAX) framework, which overcame the bottleneck of traditional customer loyalty by intelligently using PAX token. The issues of privacy preserving on accurate coupon delivery in a shopping mall was carefully considered in [14], and the authors presented a Blockchain-based solution to provide privacy protection for coupon discounts range search, behavioral targeting of customers, and coupon redemption. The solution introduced in [15] explicitly used Blockchain as an alternative of centralized endorsement to carry out transactions of online book sales. The Smart Contracts in this solution played a pivotal part enabling automatic and autonomous settlement among authors, publishers, and customers.

The above cases show the capability of Blockchain in building decentralized contexts with credible factors and have greatly inspired us, but they are essentially ideas for eliminating rather than preserving information asymmetry, which means new solutions for balancing customer flow are still worth exploring very much. In this paper, we introduce such a solution, namely diversion-point system. Our work is outlined as follows:

• We propose the diversion-point operation model to balance customer flow. In this model, the shopping mall issues diversion-points to stores, and the stores issue diversion-vouchers to customers. Each diversion-voucher specifies which stores it can be spent at and incorporates a certain amount of diversion-points as an extra discount. For customers, those diversion-vouchers add to the discounts that stores can individually offer, and thus are more attractive to customers. For stores, diversion-vouchers divert a part of customers to less popular stores, while diversion-points are rewards for those who contribute to this part of customer flow.
• We propose the layered framework of the diversion-point system to support the above operation model. It uses a blockchain subsystem as the infrastructure and provides services to the application layer through a set of middleware.
• We propose a prototype of the Blockchain subsystem, where the hierarchically permissioned network guarantees that the nodes participating in consensus are basically authentic, the hybrid data model provides design flexibility for handling different types of assets in one transaction, and the cascading consensus protocol (CCP) achieves near-real-time response and eventual confirmation of transactions.
• We evaluate the diversion-point system in aspects of effectiveness, credibility, and performance.

Our work contributes to the body of knowledge in the following aspects:

• The diversion-point operation model can widely apply to shopping malls and effectively remedy the imperfect store layout. To our best knowledge, no similar model has been reported.
• Building trust between partners with asymmetric information differs from de-trusting in anonymous transactions. This is new experience in the application of Blockchain.
• The prototype of the Blockchain subsystem facilitates building trust under information asymmetry and offers design guidelines for other similar systems.

The rest of this paper is organized as follows. Section 2 formalizes the problem of balancing customer flow. Section 3 sketches out the diversion-point system and the operation model on it. Section 4 elaborates on the design of the Blockchain subsystem. We evaluate the diversion-point system comprehensively in Section 5 and introduce the related work in Section 6. Finally, we conclude this paper in Section 7 with a recapitulative summary and line out some predictable future research directions.

2. Balancing Customer Flow

The problem of balancing customer flow is defined as follows:

Let $e_i=\left\{s_i\right\}$ be an event of consuming at store $s_i$ and $P\left(e_i\right)=p_i$ the probability of $e_i$ happening. Then, we have $V=\left\{p_1,p_2,\cdots ,p_n\right\}$, where $n$ denotes the number of stores. Now, balancing customer flow is to minimize:

$${\sigma }^2={{\displaystyle \sum }}^{}\frac{{\left(p-\overline{V}\right)}^2}{n},$$

(1)

where ${\sigma }^2$ is the population variance of $V$, $p\in V$ the variable, and $\overline{V}={{\displaystyle \sum }}^{}p/n$ the population mean of $V$.

We do not use the number of customers that have visited a store to describe the customer flow of the store, because this kind of measurement from any single observational day cannot represent any statistical pattern.

3. Diversion-Points

In this section, we first sketch out the general framework of the diversion-point system, and then illustrate how diversion-points work to balance customer flow.

3.1. Diversion-Point System Overview

The diversion-point system follows a layered framework which consists of client applications, middleware interfaces, and the Blockchain subsystem, as shown in Figure 2.

The nodes in the data and network layer were provided by customers, the shopping mall, and the stores therein (CMS for short). They are referred to as customer nodes, mall nodes, and store nodes, respectively. Store nodes will take part in the Blockchain consensus, hold a full blockchain (the storage of the Blockchain subsystem), and provide services to customers; mall nodes are peers to and only interact with store nodes; Customer nodes will hold only a very small part of the blockchain for verifying transactions and not participate in any part of the Blockchain consensus. All types of nodes compose the Blockchain subsystem and jointly maintain the data consistency of the blockchain.

The functional interfaces in the middleware layer are built on the Blockchain subsystem. They are selectively available to different users in CMS. For example, Diversion-points issuance, Membership services, and Customer flow analysis are interfaces exclusive to the shopping mall.

The apps in the application layer make the system more integrated. The Wallet is for customers to receive, expend, and exchange diversion-vouchers. In particular, diversion-vouchers can be more fully used by being exchanged between different customers. The Store-end is for stores to issue and gather diversion-vouchers. It may also include some additional functions that are useful in promotion. The Mall-end is for the shopping mall to issue diversion-points and settle with stores who have gathered the diversion-vouchers that were consumed by customers. Another very important function of this app is to analyze the customer flow since the shopping mall needs to learn the current customer flow to make more precise decisions when issuing new diversion-points.

3.2. How Diversion-Points Work

First, let us to see a case of using diversion-vouchers in different stores. Alice had bought a bag at store ${\mathcal{S}}_1$ in shopping mall $ℳ$ and been rewarded with a diversion-voucher of $20. This voucher could be used next time not only at ${\mathcal{S}}_1$, but also at another store ${\mathcal{S}}_2$ which Alice had not visited ever before. Afterward, Alice got to $ℳ$ again and visited ${\mathcal{S}}_2$ due to the diversion-voucher. Alice was the customer who was diverted from ${\mathcal{S}}_1$ to ${\mathcal{S}}_2$.

In the above case, the diversion-voucher has the form as shown in Figure 3. Unlike ordinary vouchers, diversion-vouchers raise their discounts by adding diversion-points issued by the shopping mall.

Figure 4 diagrams how a customer is diverted to a specific store with the supporting of the diversion-point system. The following steps describe a complete life cycle of the diversion-points:

• The shopping mall issues different amounts of diversion-points for ${\mathcal{S}}_1$ and ${\mathcal{S}}_2$, respectively. Those diversion-points are recorded on the blockchain as the assets of ${\mathcal{S}}_1$ and ${\mathcal{S}}_2$.
• Each store determines the form of diversion-vouchers it will issue according to the agreement with the shopping mall and several other stores. The agreement should at least specify the proportion of diversion-points in the voucher and which stores the voucher can be used at.
• A customer makes purchases at ${\mathcal{S}}_1$ and then gets a diversion-voucher $d{v}_1$ that can be used in next purchase at ${\mathcal{S}}_1$ and ${\mathcal{S}}_2$. The $d{v}_1$ is recorded on the blockchain and appears in the customer’s Wallet as an asset.
• The customer consumes $d{v}_1$ at ${\mathcal{S}}_2$ and then gets from ${\mathcal{S}}_2$ a new diversion-voucher $d{v}_2$ that may entitle the customer to use it at some other stores (including ${\mathcal{S}}_1$) next time. The $d{v}_2$ is also collected in the customer’s Wallet.
• The settlement between the shopping mall and the two stores is completed at the end of the natural business cycle. First, the diversion-points that each store has gathered or been rewarded are exchanged for equal amounts of money. Then, the shopping mall disburses the money from its reserves to corresponding stores. Next, the shopping mall analyzes which stores have contributed to balancing customer flow, for example, ${\mathcal{S}}_1$ has shared some of its customers with ${\mathcal{S}}_2$, thereby rewarding those stores with more diversion-points in the next business cycle.
• The shopping mall analyzes current distribution of customer flow according to the records on the blockchain, thereby signing new agreements with relevant stores on how to issue diversion-vouchers next business cycle.

Compared with customer loyalty reward points, diversion-points are different in that they are store-oriented rather than customer-oriented, and that they serve as balancing customer flow rather than simply promoting the volume of it. However, diversion-points need to work in conjunction with the customer loyalty reward strategy, such as the diversion-vouchers.

In practice, the mall firstly analyzes the customer flow in the last business cycle, and determines which stores should be involved in the cooperation of balancing customer flow. Then, an initial strategy can be made to group those stores. According to the strategy, the mall contracts with different groups on the allocation of diversion-points in each diversion-voucher. This process issues diversion-points. Next, when customers make payments at those stores, they get a certain number of diversion-vouchers. This process issues diversion-vouchers. Every time a diversion-voucher is used at a designated store, its ownership will be passed from the customer to the store. After a period of time, the mall has observed the change in customer flow and will appropriately amend the initial grouping strategy to recontract with new stores. Doing so helps keep the balance of customer flow. Finally, at the end of the current business cycle, the mall will look up the historical transactions to settle the debt with stores, and the stores can do the same thing to check for correctness of the settlement.

4. Blockchain Subsystem

Almost every fraud can be blamed on the ease with which transaction records can be tampered with. In a centralized framework, the shopping mall has a better chance of tampering with records than stores can do. If there is information asymmetry, the shopping mall certainly has an incentive to cheat. For example, the shopping mall may overissue diversion-points to specific stores, making things unfair; or it may fake or delete some of the transaction records so that it can pay less to the stores in the settlement stage. Such baleful behaviors conflict with the interests of the stores, causing distrust of the whole environment. We believe that the Blockchain subsystem can eliminate those risks.

The Blockchain subsystem is the core of the diversion-point system. It builds trust into cooperation of balancing customer flow by replacing human endorsement. First, the network is decentralized, so every transaction will be truthfully recorded on a blockchain, or otherwise it will be detected by all the nodes in the network. Second, all the nodes in the network jointly maintain the blockchain by distributed consensus, whereby the blockchain can be consistent and tamper-resistant. Third, diversion-points and -vouchers are serialized into the well-organized data model of transactions, so that they are easy to settle and hard to falsify. As a result, no one can do bad things in a Blockchain network, even if they have more information than others. Obviously, the above effects are impossible to achieve with any human-controlled centralized infrastructure.

In this section, we first present a prototype of the Blockchain subsystem consisting of the networking, the data model, and the consensus protocol, and then explain how the Blockchain subsystem can build trust in the shopping mall scenario while keeping information asymmetry.

4.1. Hierarchically Permissioned Network

It is propitious to build peer-to-peer (P2P) networks in shopping malls. CMS contribute two types of nodes: Permanent nodes and transient nodes. The permanent nodes are offered by the shopping mall and the stores therein, while the transient nodes come from customers. All permanent nodes are jointly responsible for completing each Blockchain consensus process to keep the network decentralized and consistent. The customer nodes mentioned in Section 3.1 are transient nodes because we do not expect them to be online all the time. They take part in the generation and verification of transactions when the customers are shopping with their Wallets (installed on, for example, mobile devices), but most of the time, they may be offline. As a result, the way that the two types of nodes join the network follows a hierarchical permission model.

This model consists of two processes of giving nodes permission to join the network. The hierarchy can be described by

$$Mall nodes\stackrel{Permission P_{MS}}{\to }Store nodes\stackrel{Permission P_{SC}}{\to }Customer nodes,$$

where the $P_{MS}$ can be guaranteed by administrative authority, whereas the $P_{SC}$ should be implemented automatically since customer nodes are expected to have got permission from store nodes if their Wallets are running. The way nodes grant permission relies on a Certificate Authority (CA) server. The certificate issued by the CA server to each node must have the licensor’s signature on it.

The characteristics of the hierarchically permissioned network are as follows:

• The number of permanent nodes is finite, while that of transient nodes can be infinite.
• After getting permission from the mall node, store nodes will have equal rights with the mall node in participating in the consensus of the blockchain, i.e., no permanent node will have super authority in controlling the process of consensus.
• Transient nodes do not need to participate in the Blockchain consensus because the customers usually prefer the lightweight client and the timely response.

The CA server does not break the decentralized topology of the network. For one thing, the identities of the stores in a shopping mall are relatively fixed and easy to identify. For another, customer nodes do not participate in the consensus and are therefore harmless.

Since the network is typically built on mobile devices, two privacy concerns should be considered in different levels of permission: (1) for permanent nodes, the malicious host problem [16] may reduce the credibility of permission; and (2) for transient nodes, lack of location privacy may expose customer’s information in physical world [17]. Some well-studied technologies can be adopted here. For the first concern, protection based on Trusted Platform Module (TPM) [16,18] can facilitate node authentication as the permission can be identifiable in a hardware level. Furthermore, Abraham et al. [19] offered a reference that using TPM in asynchronous model of network consensus. For the second concern, random routing strategy [17], traffic faking [20], and routing tables perturbation [20] are all possible solutions that can be employed.

4.2. Hybrid Data Model Supporting Multitype Assets

Diversion-points and diversion-vouchers are different assets that the Blockchain subsystem must support with its data model. More complicated, diversion-points are not only independent assets, but also a featured part of a diversion-voucher as shown in Figure 5. To support such multitype assets, we need a hybrid data model, of which the elements are described as follows.

Data structures. The state database in Figure 2 saves only the current balance of assets for each user of CMS, while the historical transactions are immutably stored on the blockchain. This design is inspired by some mainstream Blockchain technologies [21,22]. The difference is that the underlying data structure of transaction must match different assets simultaneously. In our case, the diversion-points are digital assets and thus suitable for managing in the way of double-entry bookkeeping; the diversion-vouchers are similar to tokens but can only be spent once, so the Bitcoin-like data structure [23] is not a very good fit. The final confirmation of each transaction should trigger an update to the relevant user accounts in the state database. At the same time, those transactions should become reliable sources for year-end settlement.

Considering the above requirements, we present two data structures: The transaction on the blockchain (see Figure 6) and the account in the state database (see Figure 7). Note that the data structure of block is not the focus of this paper. We refer the reader to [23] for more details about it.

Assets lie in the forest of transactions. In the state database, we represent the amount of a sort of assets with a number (see Figure 7). On the blockchain, however, we represent an asset with a chain of transactions. Those transactions describe the full life cycle of the asset. For example, as shown in Figure 6, transactions #1, #2, and #4 represent a diversion-voucher, while transactions #1 and #3 represent 20 diversion-points.

Functionally, the state database and the blockchain must work together. The state database is typically used to handle transactional requests, such as balance inquiry, whereas the blockchain provides the complete transaction history of each asset that can be analyzed to learn some knowledge, such as how customers flow between stores and how well diversion-vouchers work during a business cycle. Moreover, you can have accounts (see Figure 7) in the state database, but not on the blockchain.

In storage, diversion-points are numerical assets that can be represented as key-value pairs, so the current balance of them can be recorded in the state database. However, those records cannot reflect any past state of an account (see Figure 7). Diversion-vouchers, on the other hand, are compound assets that cannot be simply represented as key-value pairs. To some extent, they can be seen as electronic bonds [24] with diversion-points as one of its components. Therefore, they are better suited to using transaction chains to uniquely express.

Data manipulations. In a data model, data structures organize data entries into datasets, and data manipulations are a group of algorithms that can be used to process those datasets in a right manner. Most transactional operations in practice are based on reading/writing the state database. The implementation of those operations is well-established. One can directly employ I/O interfaces or adopt the way of “read/write sets” as Hyperledger Fabric [21] has provided. Therefore, we mainly focus on the data manipulations which are required for some key analytical operations toward the blockchain rather than the state database. Those data manipulations must support the functional interfaces in the middleware layer shown in Figure 2, and we suggest that they should include:

• $GenTxn\left(PreHash,Pr{k}_{Signer},Pu{k}_{Holder},Pu{k}_{Issuer},Sk,Points,Rewards,Discount,Expiration, Scope\right)$, where:

• $PreHash$—hashpointer to the previous transaction;
• $Pr{k}_{Signer}$—private key of the initiator of the transaction;
• $Pu{k}_{Holder}$—public key of the current holder of the assets involved in the transaction;
• $Pu{k}_{Issuer}$—public key of the issuer of the assets involved in the transaction;
• $Sk$—symmetric key for encrypting sensitive information of the transaction;
• $Points$—diversion-points;
• $Rewards$—part of $Points$ used for rewarding the issuer;
• $Discount$—total discount of the diversion-voucher;
• $Expiration$—deadline by which the diversion-points or -voucher can be used;
• $Scope$—a public key list indicating where the diversion-voucher can be consumed.

The output of this algorithm should be one of the four types of transactions shown in Figure 6, namely, Points issuance, Voucher issuance, Unspent Transaction Output (UTXO) [25], and Voucher consumption. First, the shopping mall issues diversion-points for stores through points issuance transactions. Then, each store issues diversion-vouchers by assigning some of its diversion-points to each of those vouchers. The customers become the holders of those diversion-vouchers. Next, when a customer receives a diversion-voucher from a store, he/she must return the rest of the store’s diversion-points by generating an UTXO transaction. Lastly, customers can spend their diversion-vouchers at the stores listed in the $Scope$ of each voucher. This will generate the voucher consumption transactions, which are the ends-of-life of the diversion-vouchers as well as the diversion-points they contain. Note that voucher issuance transactions can generate only from points issuance transactions and UTXO transactions as shown in Figure 6.

• $GetUTXO\left(Pu{k}_{Store},BC\right)$, where:

• $Pu{k}_{Store}$—public key of the store for the UTXO transaction to be looked up;
• BC—blockchain.

This algorithm returns the given store’s last UTXO transaction. Although stores can easily obtain the balance of their diversion-points through querying the state database, they have to get the last UTXO transaction to issue new diversion-vouchers. A simple but inefficient way to do this is to traverse the blockchain and find out the last UTXO. However, a smart way is to make an index beforehand for doing this job.

• $QueryTxns\left(AssetId,Pu{k}_{Store},Pu{k}_{Customer},Prk,Field,BC\right)$, where:

• $AssetId$—identifier of the voucher of which the transactions are being queried;
• $Pu{k}_{Store}$—public key of the store involved in the transactions to be queried;
• $Pu{k}_{Customer}$—public key of the customer involved in the transactions to be queried;
• $Prk$—private key of the inquirer;
• $Field$—indicates where to query from, [‘Id’|‘Holder’|‘Issuer’].

When verifying transactions or settling accounts, it is necessary to query for transactions related to specified assets, stores, or customers. Acquiring those transactions will yield more detailed information than simply reading the state database.

• $ShowPointsUsage\left(Pu{k}_{Store},Prk,BC\right)$, where $Pu{k}_{Store}$ is the public key of the store of which the points’ usage is being examined.

The output of this algorithm should answer two questions: (1) how many diversion-vouchers have been issued by the specified store? (2) how many diversion-points were there in each diversion-voucher? Extending the transaction data structure in Figure 6 will result in a binary tree of transactions. Then, tracing along the branch of UTXO transactions back to the points issuance transaction is a general idea to implement this algorithm.

• $ShowVoucherUsage\left(Pu{k}_{Customer},Prk,BC\right)$, where $Pu{k}_{Customer}$ is the public key of the customer of whom the vouchers’ usage is being examined.

From the voucher consumption transactions of the specified customer, we can learn the subtle shifts of the customer’s loyalty. This algorithm returns a statistic about how the diversion-vouchers of a customer have been consumed at different stores, and helps us understand the flow of each customer.

• $AssessDiversionEffect\left(Pu{k}_{Store},Prk,BC\right)$, where $Pu{k}_{Store}$ is the public key of the store of which the diversion effect is being examined.

This algorithm aims to assess the diversion effect on the customer flow of a given store. Its output should contain the information about how many customers have been diverted to other partner stores, and figure out the ratio of diverted customer flow (RDCF).

• $ShowCustomerFlow\left(Prk,BC\right)$ lists the customer flow of each store. The results can help the shopping mall make a good decision on the diversion-points issuance for the next business cycle. Note that the customer flow refers only to the customers who have spent diversion-vouchers.
• $VerifyTxn\left(hp,hpUTXO,BC\right)$, where:

• $hp$—hashpointer pointing to the new generated transaction to be verified;
• $hpUTXO$—hashpointer pointing to the new UTXO transaction (if needed).

This algorithm returns a sign that indicates whether the new transactions are valid or not. This is the most important check on transactions before they are appended to the blockchain. A new transaction should be examined to make sure that there is no: (1) “double-spending” [26] of diversion-points and -vouchers; (2) unauthenticated signatures from the gatherers who are out of the $Scope$; and (3) invalid elements, including miscalculation of the diversion-points in UTXO, $Points>Discount$, and expired vouchers.

• $Settle\left(Pu{k}_{Store},Prk,BC\right)$, where $Pu{k}_{Store}$ is the public key of the store with which the shopping mall is going to settle.

This algorithm returns the amount of diversion-points that need to be converted into the equivalent cash to be paid to the specified store. Stores get rewarded or repaid from the voucher consumption transactions they have participated. In those transactions, the $Rewards$ will be rewarded to the issuer, and the $Points$ will be repaid to the gatherer.

This algorithm can also be used to verify the settlement, if the $Prk$ is the private key of the store. Take the transaction chain shown in Figure 6 as an example, Store 2 as the gatherer first collects the voucher consumption transactions, then decrypts $Sks$ from $Scope$ with its $Prk$, thereby revealing and sum up the values of $Points$ in those transactions, and finally check this sum by comparing it to that of mall’s settlement. As for the issuer Store 1, it can simply do the same thing as Store 2 except checking the field of $Rewards$ instead of $Points$.

4.3. Near-Real-Time Responding Consensus Protocol

In a shopping mall, the use of diversion-vouchers is near-real-time. We define “near real time” as sub-second response time, because it is short enough so that both parties of a transaction cannot feel any noticeable delay. In addition to near-real-time response, low cost is also an important requirement of the diversion-point system since high cost may have veto to block any business system. The consensus protocol of the Blockchain subsystem is the main factor influencing the transaction response time and cost input, so it needs to be carefully chosen or designed.

With the above requirements in mind, we examined common consensus protocols and analyzed their applicability to our case (see Section 6.2 for details). Although most of them did not match our requirements, some work stimulated our inspiration. MSig-BFT [27] expands the network with a role of “witness” who supervises the “leader” node by collecting broadcasters’ signatures. Hyperledger Fabric introduces an “execute-order-validate” mode to improve the latency of transactions. We borrowed these ideas and designed a CCP for achieving near-real-time response. Now, we take a diversion-voucher payment between a customer ($C$) and a store ($S$) as an example to describe this protocol as show in Protocol 1.

Protocol 1. Cascading consensus protocol (CCP)

Stage 1:

Process 1 for $C$

(1) $C\stackrel{T_{vc}}{\to }S$. Note: $T_{vc}$ is a voucher consumption transaction created by $C$, and $\to$denotes the action of sending.

(2) If $C\stackrel{Tag=Pr{k}_S\left(Hash\left(T_{vc}\right)\right)}{\leftarrow }S$, then “complete” the payment for $C$, else recover the diversion-voucher. Note: $\leftarrow$denotes the action of receiving.

Process 2 for $S$

(1) $S\stackrel{T_{vc}}{\leftarrow }C$.

(2) If $VerifyTxn\left(T_{vc}\right)=True$, then $S\stackrel{Tag=Pr{k}_S\left(Hash\left(T_{vc}\right)\right)}{\to }C$ and put $T_{vc}$ into $coun{t}_{Txns}$, else $S\stackrel{Tag=Pr{k}_S\left(”False”\right)}{\to }C$ and quit. Note: $coun{t}_{Txns}$ is the number of transactions in the transaction pool $Txns$.

(3) $S\stackrel{T_{vc}}{\to }{S}^{*}$. Note: $S^{*}$ is another store chosen randomly from $T_{vc}\left[AT\right]$, which is the address table for sending $T_{vc}$.

(4) Repeat $S\stackrel{Tag=Pr{k}_{S^{**}}\left(Hash\left(T_{vc}\right)\right)}{\leftarrow }{S}^{**}$ and remove $S^{**}$ from $T_{vc}\left[AT\right]$ in time $t$. When $t$ expires, do the next step. Note: $t$ is the interval of time and $S^{**}$ could be any other store including $S^{*}$.

(5) If $coun{t}_{Tags}\le \left(n-1\right)/2-1$, then do the next step, else quit. Note: $coun{t}_{Tags}$ is the number of received correct $Tags$, and $n$ is the number of stores.

(6) If $T_{vc}\left[AT\right]\ne \mathsf{\varphi }$, then do (3), else update the blockchain from any other node (store).

Process 3 for $S^{*}$

(1) $S^{*}\stackrel{T_{vc}}{\leftarrow }{S}^{**}$. Note: $S^{**}$ could be any other store including $S$.

(2) If $VerifyTxn\left(T_{vc}\right)=True$, then $S^{*}\stackrel{T_{vc}}{\to }{S}^{**}$, put $T_{vc}$ into $coun{t}_{Txns}$, and $S^{*}\stackrel{Tag=Pr{k}_{S^{*}}\left(Hash\left(T_{vc}\right)\right)}{\to }S$.

Stage 2

Process 4 for all stores

(1) When either $coun{t}_{Txns}\ge 2k$ or $timeout\left(t^{\prime }\right)$, do the next step. Note: $k\ge n$, and $timeout\left(t^{\prime }\right)$ means the time $t^{\prime }$ has elapsed since the last transaction or $Tag$ was received.

(2) $S^{\prime }≔elect\left(Txns\right)$. Note: $elect\left(Txns\right)$ elects a leader store who contributes the most to the first $k$ transactions of $Txns$.

(3) If $S^{\prime }$ is the current store, then collect the first $k$ transactions of $Txns$ into a new block $B$, else quit.

(4) Append $B$ to the blockchain.

(5) $S^{\prime }\stackrel{Ta{g}_B=Pr{k}_{S^{\prime }}\left(”Packing:k” | mtr\right)}{\to }{S}^{*}$, where $mtr$ is the Merkle Tree [28] root of the first $k$ transactions of $Txns$.

(6) Repeat $S^{\prime }\stackrel{Tag=Pr{k}_{S^{**}}\left(”Packed”\right)}{\leftarrow }{S}^{**}$ and remove $S^{**}$ from $Ta{g}_B\left[AT\right]$ in time $t$. When $t$ expires, do the next step.

(7) If $coun{t}_{Tags}\le \left(n-1\right)/2-1$, then do the next step, else quit.

(8) If $Ta{g}_B\left[AT\right]\ne \mathsf{\varphi }$, then do (5), else update the blockchain from any other node (store).

Process 5 for all stores. Let $S^{*}$ be the current store.

(1) $S^{*}\stackrel{Ta{g}_B=Pr{k}_{S^{\prime }}\left(”Packing: k” | mtr\right)}{\leftarrow }{S}^{**}$. Note: $k$ is the number of transactions to be packed according to $S^{\prime }$.

(2) Check the first $k$ transactions of $Txns$ to see if their Merkle Tree root is equal to $mtr$ and if $S^{\prime }$ is indeed the leader store. If so, collect those $k$ transactions into a new block $B$. If not, quit.

(3) Append $B$ to the blockchain.

(4) $S^{*}\stackrel{Ta{g}_B=Pr{k}_{S^{\prime }}\left(”Packing: k” | mtr\right)}{\to }{S}^{**}$ and $S^{*}\stackrel{Tag=Pr{k}_{S^{*}}\left(”Packed”\right)}{\to }{S}^{\prime }$.

The following points about Protocol 1 should be noted in particular:

• Process 1 determines that this protocol supports near-real-time response.
• Process 2 (5) and Process 4 (7) indicate that we need at least four nodes and at most one faulty node therein to bootstrap this protocol. Figure 8 illustrates the cascading messaging pattern of CCP.
• It is assumed that the transactions in the $Txns$ of each store are strictly chronologically ordered.

4.4. Trust Building

In this paper, we define the information asymmetry in business cooperation as an appearance that each party has an unequal knowledge of the long-term effect of the cooperation. In the shopping mall, the information asymmetry in the cooperation of balancing customer flow is twofold. For one thing, each store has no way of knowing the customer flow of other stores. For another, the shopping mall knows more about changes in customer flow and details of partnerships than any store, but it cannot tamper with the terms and results of the partnerships.

Stores should not know too much. If a store could learn about others’ agreements, it would break the equilibrium of the game in its own interest, thereby hindering the “win-win”. If customers could learn about the cooperation between any two stores, there would be a gossip-driven and non-free-will customer flow, which is often the opposite of the desired diversion effect.

Keeping information asymmetry does not amount to making cooperation unfair. The cooperation depends on reasonable agreements. Each diversion-voucher is an agreement involving the shopping mall and several stores. In the immediate interest of each individual store, those diversion-vouchers may look unfair. In the long run, however, balancing customer flow is a “win-win” strategy for the shopping mall and all stores. On the other hand, every party of a voucher has the same access to all the transactions around the voucher.

The Blockchain subsystem partly encrypts each transaction so that each user can see different information, thereby keeping information asymmetry. For example, as shown in Figure 6, each transaction has its own secret key Sk_i, and its $Scope$ lists the ciphertexts of Sk_i which have been separately encrypted with the public keys of the involved users. Only those users can read all the elements of the transactions having that $Scope$, but they cannot recognize each other. Meanwhile, $Pu{k}_{Mall}\left(S{k}_i\right)$ will always appear in the $Scope$ of each transaction, so that the shopping mall can gain more information than other users to make full sense of the effect of balancing customer flow. This encryption strategy preserves information asymmetry when consensus is reached since no one but the stakeholders of a voucher can understand the details of the transactions about the voucher.

However, a node must be able to verify a transaction even if it is not one of the stakeholders. We suggest using homomorphic encryption [29,30] to implement $S{k}_i(.)$. In this way, any node can perform confirmatory calculations on the elements of a transaction without decrypting them.

The trust built by the Blockchain subsystem comes from the following properties:

• Transaction history is undeniable. First, the centralized power of the shopping mall has been greatly reduced, and its behavior is monitored by the whole network. Second, the hierarchical permission mechanism makes the identity of each node verifiable. Besides, the fact that transient nodes do not participate in consensus avoids the interference of malicious nodes. Third, the hybrid data model increases the cost of tampering with transactions, because modifying any transaction requires modifying all subsequent transactions, and the only way those fake transactions can be reached consensus on is in the hope that the majority of the nodes are hacked into. Finally, no sensitive information in transactions will be disclosed during consensus processes due to the encryption strategy we mentioned before.
• Agreements are transparent to their participants. Only when all the stores understand the meaning and predictable effect of the agreement will they be willing to implement it. The most direct benefit is promotion, and the second is to make stores more attractive, since diversion-vouchers are exclusive deals people cannot get elsewhere. These all help to customer retention. Furthermore, diversion-vouchers are exchangeable, leading to an increased likelihood of new customers.
• Agreements are not transparent to those not involved. This is the key to preserve information asymmetry and is also a necessary condition to the cooperation of balancing customer flow. As shown in Figure 6, all the fields that can be used to infer the details of an agreement are not available in plaintext to nodes that are not parties to the agreement.
• There are compensation and rewards for balancing customer flow. Diverting customer flow, after all, seems to be a risk for some stores to lose customers. Compensation and rewards are necessary to persuade stores to participate in diversion agreements. The first measure is financial compensation. The shopping mall can reduce the rent of stores in the next year according to their RDCF (refer to Section 4.2). The second measure is reciprocal compensation. The customers diverted away have a chance to be diverted back. For example, if store ${\mathcal{S}}_1$ issues vouchers that can be consumed at store ${\mathcal{S}}_2$, then the vouchers issued by ${\mathcal{S}}_2$ must put ${\mathcal{S}}_1$ in their $Scope$. The third measure is financial rewards. As shown in Figure 6, a portion of the diversion-points in a consumed voucher will be awarded to the issuer of the voucher in the settlement stage. At the same time, stores with high RDCF will get extra diversion-points in the next business cycle.

5. Evaluation

In this section, we first demonstrate the effect of balancing customer flow by simulating the operation of the diversion-point system. Then, we analyze the credibility of the system. Finally, we evaluate the performance of the system based on the actual application requirements.

5.1. The Effect in Balancing Customer Flow

In Section 2, we have defined the problem in a statistical sense. Now, we discuss the customer behavior in a probabilistic sense before we can write an effective simulator.

Let $S=\left\{s_1,s_2,\cdots ,s_n\right\}$ be all stores in the shopping mall. A diversion-voucher issued by $s_i$ is denoted by $d{v}_{id}=\left(id,dp,rw,dc,s_i,S^{\prime }\right)$, where

• $id$—identifier of the voucher;
• $dp$—diversion-points for the discount;
• $rw$—rewards for $s_i$;
• $dc$—total discount of the voucher;
• $S^{\prime }$—scope of the voucher, $S^{\prime }\subseteq S$.

Let $P\left(e_{d{v}_{id}}\right)=q_{id}$ be the probability of using $d{v}_{id}$ to guide store selection, $P\left(e_{c,i}\right)=p_{c,i}$ the probability of customer $c$ consuming at $s_i$, and $P\left(S^{\prime }\right)=p_{S^{\prime }}$ the probability of consuming at one of the stores in $S^{\prime }$. If $c$ holds $d{v}_{id}$, then by the total probability theorem, it follows that

$$\begin{array}{lll}P\left(e_{c,i}\right)& =& P\left(e_i|e_{d{v}_{id}}\right) P\left(e_{d{v}_{id}}\right)+P\left(e_i|\overline{e_{d{v}_{id}}}\right) P\left(\overline{e_{d{v}_{id}}}\right), i=1,2,\cdots ,n, \\ \Rightarrow p_{c,i}& =& \{\begin{array}{rr}\frac{p_i}{p_{S^{\prime }}}{q}_{id}+p_i\left(1-q_{id}\right), & s_i\in S^{\prime },\\ p_i\left(1-q_{id}\right), & s_i\notin S^{\prime },\end{array}\end{array}$$

(2)

where $p_{c,i}\ge 0,i=1,2,\cdots ,n$.

Now, let us consider a simple case to see what will happen when a diversion-voucher is consumed. Suppose $S=\left\{s_1,s_2,s_3,s_4\right\}$, $p_i=i/10, i=1,2,3,4$, $d{v}_{16}=\left(16,4,1,20,s_3,\left\{s_1,s_2,s_3\right\}\right)$, and $q_{16}=0.5$. When customer $c$ holds $d{v}_{16}$, according to formula (2), $p_{c,i}$ can be calculated as:

$$p_{c,1}=0.1\times 0.5/0.6+0.1\times 0.5\approx 0.1333,$$

$$p_{c,2}=0.2\times 0.5/0.6+0.2\times 0.5\approx 0.2667,$$

$$p_{c,3}=0.3\times 0.5/0.6+0.3\times 0.5=0.4,$$

$$p_{c,4}=0.4\times 0.5=0.2,$$

where we get $\left|\left(p_{c,i},p_{c,4}\right)\right|>\left|\left(p_i,p_4\right)\right|, i=1,2,3,4$. This indicates that the customer will probably be diverted from $s_3$ to $s_1$ or $s_2$, and at the same time, $d{v}_{16}$ helps close the gap between $s_4$ and other stores in terms of customer flow.

When considering a large number of random customer visits, we can see an overall effect of the minimization of ${\sigma }^2$ (refer back to Section 2). We wrote a simulator called Simulator for Balancing Customer Flow (SBCF) [31] for the above case based on the following assumptions:

• The initial customer flow is 10,000, and the number of customers creases by 10% per month.
• Each old customer returns to the shopping mall monthly with a probability of 0.3.
• Each customer visits the shopping mall at most once a month and each time visits a random number of stores.
• Only one diversion-voucher can be used at a time.

The simulation result of customer flow in one year is shown in Figure 9 and Figure 10, where we can learn the following:

• The use of diversion-vouchers makes the customer flow ratios of stores tend to balanceable. As shown in Figure 9, ${\mathsf{\sigma }}^2$ reaches its minimum in June (i.e., the balance point), which means that we need to set the expiration date of those diversion-vouchers to this month.
• Balancing customer flow is a “win-win” strategy. In Figure 10, customer flow is increasing in all stores until the balance point is reached.
• The cooperation of balancing customer flow does not mean a loss. As shown in Figure 9, the customer flow of Store 3 has an increasing ratio even more than Store 1 and Store 2.
• It would be unwise to resist cooperation. Figure 9 tells us that stores that do not participate in balancing customer flow will gradually lose their popularity, particularly after the balance point.

5.2. Credibility

In a cooperation environment with asymmetric information, participants can only trust in an independent system which is free from human interference and does not influence human behavior. Therefore, the diversion-point system will be credible by showing that the following propositions are true.

Proposition 1.

The transaction history is impossible to tamper with.

Proof. 

An adversary might have four occasions to falsify a transaction, but it will not succeed. □

• Just when the transaction is generated. The Process 1 (1) in Protocol 1 tells that voucher consumption transactions are generated by customers only. As shown in Figure 6, to alter a new voucher consumption transaction, all previous transactions need to be altered accordingly, where the UTXO transactions require the signatures of the customer. However, the customer’s Wallet does not have the ability to write over any transaction other than the new voucher consumption transaction. As a result, neither the customer nor the store will be able to alter the new transaction.
• Before the transaction is packed into a block. According to the Process 4 and 5 in Protocol 1, each node packs new blocks individually, i.e., the adversary unilaterally modifying the transaction in its own storage does not change the consistency of the network.
• Just when the transaction is packed into a block. According to the Process 4 (2) in Protocol 1, every node can work out who the leader node will be. On one hand, blocks that are not from the leader node will not be accepted by any node. On the other hand, fake blocks will not be able to pass validation by other nodes (see Process 4 (5) and Process 5 (2) in Protocol 1), even if they come from the leader node.
• After the transaction is packed into a block. The adversary needs to alter the chains not only of the transactions but also of the blocks. By the Process 4 (7) and (8) in Protocol 1, a normal node will not download a blockchain from the adversary, unless it is in the minority while the most of others are adversaries.

In short, an adversary has to hack into at least half of the nodes in the network to falsify the transaction history, but in a hierarchically permissioned network, it is far more difficult to do that.

Proposition 2.

Non-repudiation in settlement.

Proof. 

Since Proposition 1 is true, it suffices to prove that the calculation in settlement is verifiable. The data model mentioned in Section 4.2 provides $Settle\left(Pu{k}_{Store},Prk,BC\right)$ for stores and the shopping mall to verify the results of settlement. This method first scans all the voucher consumption transactions that the given store has involved, then sums the values of the $Points$ field and the $Rewards$ field, respectively, and finally checks these sums for correctness. Even any node can perform this verification if we apply homomorphic encryption to $S{k}_i$ (see Figure 6). In other words, neither the shopping mall nor the stores are able to deny the result of settlement. □

Proposition 3.

The details of an agreement (a diversion-voucher) are hidden from irrelevant nodes.

Proof. 

As shown in Figure 6, it is by ciphertexts that each transaction lists all participants into its Scope field. These ciphertexts protect a symmetric key, and can be decrypted by each participant’s public key. The symmetric key is used to decrypt information in other fields, including $Points$, $Rewards$, and $Discount$. Therefore, irrelevant nodes can only see who issued and held the diversion-voucher, but cannot infer all partners of the agreement. Moreover, only these participants have access to the field encrypted by the symmetric key, which prevents the details of the agreement from being disclosed. □

Proposition 4.

Faulty nodes are hard to sabotage the consistency of the transaction history across the network.

Proof. 

Faulty nodes can be untrusted nodes, crash nodes, and Byzantine nodes [32]. The proposition will be proved if we can show that these types of nodes have no effect on the data consistency of the system. The proof is fourfold. □

• Under hierarchical permission, most untrusted nodes may be transient nodes (i.e., customer nodes). They are powerless in consensus processes. For example, just in Process 1 in Protocol 1, the job of the customer node is completely finished. This is not only a requirement for near-real-time response, but also a protection for consensus processes.
• The consensus protocol is fault-tolerant. Let $f$ be the number of faulty nodes. By Process 2 (5) and Process 4 (7) in Protocol 1, we can get $f\le \left(n-1\right)/2$. Suppose the extreme case $f=\left(n-1\right)/2$. In Stage 2 of Protocol 1, the leader node (i.e., the leader store) will receive $\left(n-1\right)/2$ valid tags, which means that there are $\left(n-1\right)/2+1$ nodes that keep the consistent data. Next time, if a faulty node became the leader and committed a new block, it would have passed through the test of the Process 4 (7). This contradicts the fact that the new block was impossible to pass through the test of the Process 5 (2). As a result, the faulty node will finally follow the Process 4 (7) to download a correct blockchain from another node. Therefore, $f$ faulty nodes will be tolerated. Moreover, it is clear that this fault tolerance rate better meets the needs of the diversion-point system than most variants of Byzantine fault tolerance (BFT) protocols [27,33,34,35,36].
• Eventual consistency. As long as the number of bad nodes is within the fault tolerant range, all nodes can finally reach a consensus on the blockchain. In Stage 2 of Protocol 1, the inconsistency window starts when the leader node packs a new block and ends when all the faulty nodes correct their blockchains. Furthermore, the strategy of packing the first $k$ of the transaction pool (see the Process 4 (3) in Protocol 1) also greatly reduces the likelihood of inconsistency.
• There is no leadership with leader nodes. By Proposition 1, leader nodes just initiate the block packing, but are not able to tamper with the transactions to be packed. In order for the leader node to be recognized by other nodes every time, the system chooses the store who contributes the most transactions to the first $k$ of the transaction pool as the leader node (see the Process 4 (2) in Protocol 1). We can infer that stores who issue diversion-vouchers will be more likely to be chosen as the leader nodes due to their increasing customer flow, and also these stores are those who most want the data to be consistent.

Proposition 5.

Transactions are eventually confirmable.

Proof. 

According to Proposition 1 and Proposition 4, under the guarantee of the eventual consistency, a transaction can be eventually confirmed in a finite amount of time as long as it is valid. This property ensures that the system does not loss a transaction, even if it responds to the customer in ahead of confirming the transaction. □

To sum up, although there is information asymmetry among stores, the above propositions indicate that there is no human intervention in execution the cooperation of each diversion-voucher, and the cooperation will not result in non-compliant behaviors of stores. Each store will no longer care about the effect of balancing customer flow on other stores, as long as the cooperation is profitable to itself. This is the trust that the diversion-point system builds up.

5.3. Performance

For the shopping mall scenario, the feasibility of the diversion-point system mainly depends on the runtime performance of its consensus protocol. Now that we have shown the CCP (see Protocol 1) is responsive in near-real-time, the performance we are going to evaluate in this section focuses on that of confirming transactions.

Considering the design goal of eventual confirmation, the comparable protocol includes PBFT [33], MSig-BFT [27], and SBFT [35]. We implemented these protocols and CCP on our developed Multithreaded Distributed Application Testbed (MDAT) [37], and compared them in terms of average latency and throughput of transactions with the virtual settings shown in

Table 1. Experiment settings for simulation. Note that these settings are just used for the comparison experiment, and compress the timeline of real life.

Parameter	Description	Range	Protocol
n	The maximum number of nodes	300	All
txns	Peak transaction volume	10,000	All
rd	The random delay for generating a transaction	1–10 ms	All
to	Timeout for packing a new block	10–5000 ms	All
size	Average size of a transaction	1 KB	All
tag	Average size of a tag	100 B	CCP
k	Threshold factor for packing a new block	=n	CCP
wt	Waiting time for receiving messages	1 s	CCP
tr	Transmission rate	1 Mbps	All
c	The number of commit collectors	1	SBFT
w	The number of “Witness”	1	MSig-BFT

. We ran MDAT on a server machine (CPU: x64 2.6 GHz, 6 core, 12 logic processors; RAM: 16 GB; and HDD: SSD 512 GB). However, the experiment is device-independent and can be replicated any number of times to reach the same conclusion.

The experiment results are shown in Figure 11 and Figure 12 and the following conclusions are drawn:

• As shown in Figure 11a, the impact of increasing the number of nodes on the throughput of CCP is much less than that on the throughput of other protocols.
• As shown in Figure 12a, the average latency per transaction at CCP lengthens slowly as the number of nodes increases, and remains within acceptable limits. By contrast, all the other three protocols are very hard to ensure that transactions can be eventually confirmed when there are many nodes.
• The performance of CCP degrades a little bit faster over 200 nodes, as shown in Figure 11a and Figure 12a.
• As the number of concurrent transactions changes, CCP exhibits better stability while keeping high performance, as shown in Figure 11b and Figure 12b. This implicates that the diversion-point system is able to provide efficient and stable services under high pressure of processing transactions.

We further discuss the following questions with respect to the experiment results.

• Why not consider faulty nodes? The data synchronization of faulty nodes has strong randomness in all these protocols. Take CCP as an example, the time to update the blockchain of a faulty node is when a transaction occurs on that node. In real life, however, a store may be out of business for a long time. Therefore, should faulty nodes be considered, it would not be a pure assessment on the performance of those protocols.
• Why can CCP have such performance? The consensus process of CCP is somewhat like unidirectional flooding broadcast. Each node in one consensus process sends up to one transaction (see Process 2 (3) and Process 3 (2) in Protocol 1) and four tags (see Process 2 (2), Process 3 (2), Process 4 (5), and Process 5 (4) in Protocol 1). For one thing, each node only sends a very small amount of data compared to a broadcast. For another, the size of a transaction or a tag is much smaller than that of a block. In this way, the channel capacity of the network is greatly saved, and each node can handle more concurrently arrived transactions.
• Why does CCP’s performance start to degrade a little bit faster at 200 nodes? We simulated the bandwidth cap by setting the capacity of the thread pool. When there were 200 nodes in the network, the number of messages still in transit might exceed this limit, and some threads were, thus, temporarily blocked, leading to the degradation on performance. In practice, although the performance degradation is inevitable due to the real bandwidth cap, that moment is more likely to come only when there are plenty of nodes (far more than 200) in the network.
• How does a process in CCP terminate? CCP limits the length (i.e., the number of nodes) that a message can be transmitted by attaching an address table to it (see Process 2 (3)(4)(6) and Process 4 (5)(6)(8) in Protocol 1). The address table is attached by the originator of the message. Every node receiving an address table needs to authenticate it but cannot modify it. When a node finds that the address table it receives is inconsistent with the native one, it will select an address from their intersection to forward the message, and then notifies the originator to synchronize the address table from other valid nodes. The maintenance of the address table has been well-studied, such as [38], so we did not go over it in Protocol 1.
• Why is CCP more scalable? As shown in Figure 11a and Figure 12a, none of the three BFT-based protocols worked well to the end. The reason was that too many blocks were broadcasted during the consensus. Although we repeatedly tested and adjusted the to parameter (see Table 1) to reduce block production, we had to shut down those protocols after ten minutes of hard running. By contrast, CCP kept running because of the way it packed blocks (see Process 4 (1)–(4) in Protocol 1) and the way it spread messages (see Process 2 (3), Process 3 (2), Process 4 (5), and Process 5 (4) in Protocol 1).
• Why can CCP be more stable as the number of concurrent transactions changes? From Protocol 1, it is easy to know that the transaction throughput and the average latency are related to only the number of nodes, so the degree of concurrency does not affect CCP’s performance.

6. Related Work

When designing the Blockchain subsystem, we examined existing studies about Blockchain data models and consensus protocols. Although many results were not applicable to our case in shopping malls, they inspired us a lot.

6.1. Blockchain Data Models

Current Blockchain data models commonly used fall into two categories. One is the token-based model represented by Bitcoin [23] and Ethereum [22], and the other is the digital assets model represented by Hyperledger Fabric [21].

Token-based models usually take the transaction type of “token payment”, elect bookkeepers to synchronize system states through competitive “mining”, and reward their work with tokens for incentive. These models are more applicable to contexts running public blockchains where nodes are free to join and leave [39,40]. In our case, however, stores in a shopping mall are generally fixed and definite, and thus form a permissioned blockchain rather than the public one.

The transactions in digital assets models are usually in forms of changing the states of specific digital assets, but not subject to their types. This means that such models can have a wider range of applications. For examples, in terms of medical informatization, Chen et al. [41] changed the blockchain data structures for sharing medical records in an efficient way. In terms of risk management, the risk smart ledgers [42] was proposed to identify, assess, and control risk items. A risk association tree adapted from Merkle tree was used for organizing different types of risk smart ledgers. In terms of trusted voting, Shahzad et al. [43] emphasized adjustment on the original Blockchain data model and employed new hashing techniques to ensure the security of the data in electronic voting processes. In terms of online sales of digital assets, Smart Contracts were utilized in [15] to automate the transactions of e-book sales, thereby forming an enforceable data model for author royalty protection. In terms of art trading, Pérez–Solà et al. [44] provided detailed descriptions of the data structures for different types of transactions on digital artworks. Meanwhile, this work also used the token-based model for payment. In terms of Internet of Things (IoT) data sharing, Xuan et al. [45] improved the architecture and layering of the data model in Hyperledger Fabric to meet the requirements of IoT data sharing transactions. These cases, among many others, encouraged us to study more effective data models for combining different types of assets in the diversion-point system.

6.2. Blockchain Consensus Protocols

First of all, we recommend the reader to refer to [46] for an overview of current consensus mechanisms. In view of the requirements of keeping information asymmetry and responding transactions in near-real-time, the certainty in consensus is a sufficient condition to support building trust in multi-party cooperation. This section classifies common consensus protocols into five categories and analyzes their applicability in the diversion-point system.

The first is Proof-of-X (PoX), such as PoW [23], PoS [47], dPoS [48], PoA [49], and PoR [50,51]. Those protocols are usually token-based and mining-based, and do not require much timeliness. Moreover, some of them may be at risk of blockchain forking. Obviously, we cannot see those protocols working well in the diversion-point system with near-real-time response and certainty in confirming transactions. The second is the two-phase proposal protocol, including Paxos [52] and its simplified implementation Raft [53]. Although they aim to provide high efficiency and consistency, they lose some of the decentralization and fail to cope with Byzantine nodes. In a shopping mall, there is no way to make sure that all store nodes are honest, so we cannot sacrifice the availability for just a fast-running speed. Before Raft came out, Lamport [54] refined Paxos by merging it with PBFT [33] so that Byzantine nodes could be tolerated. A couple years ago, BVP [19] was proposed on the basis of Vertical Paxos [55] to deal with Byzantine problem in a Blockchain environment. Unfortunately, those combinations resulted in reduced efficiency again. The third is the BFT-based protocol, such as PBFT [33], DPBFT [34], DBFT [36], MSig-BFT [27], and SBFT [35]. They are better suited for permissioned networks with no more than 100 nodes. However, there are often more than 200 stores in a shopping mall, leading to poor feasibility of employing those protocols. The fourth is the hardware-assisted consensus mechanism. This kind of mechanism improves efficiency and security but increases deployment costs as well. For example, FastBFT [56] relies on trusted execution environments (TEEs) such as Intel SGX [57]. The last is the consensus mechanism relying on complicated architecture, which is often hard to deploy and costly to maintain. For example, Hyperledger Fabric employs the Kafka [58] cluster and ZooKeeper [59] ensemble, which usually needs more special nodes and professional maintainers, to run ordering services.

However, as we mentioned before, some of the above protocols offered ideas for us to design the CCP. For examples, the Tag collection process in CCP came from the way of collecting signatures for confirming reception in MSig-BFT; and the idea of immediate responding to customers in CCP derived from the mode of “execute-order-validate” in Hyperledger Fabric.

7. Conclusions

This paper proposes a systematic solution for the problem of balancing customer flow in shopping mall scenarios. The distinctive idea of this solution is to build trust in multi-party cooperation that is carried out in contexts with information asymmetry. The kernel of this solution is a diversion-point system underpinned by a credible Blockchain subsystem. Evaluation results show that the proposed solution is effective for balancing customer flow, and the cascading consensus protocol, which is the computationally intensive part of the solution, outperforms existing ones.

Some limitations of our work point out future research directions. In terms of business strategy, policies based on the analysis of historical transactions are worthy of in-depth study. In terms of technical implementation, this paper has not yet answered the question of how nodes connect and communicate with each other to form an efficient Blockchain network, which may be an interesting research topic. In terms of security, while the proposed system has the security that a general Blockchain-based system should have, it still needs to further study the defense against Distributed Denial of Service (DDoS) attacks and the recovery mechanism against the 51% attack.