Blockchain-Based Diversion-Point System for Balancing Customer Flow in Shopping Mall
Abstract
:1. Introduction
- 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.
- 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.
2. Balancing Customer Flow
3. Diversion-Points
3.1. Diversion-Point System Overview
3.2. How Diversion-Points Work
- The shopping mall issues different amounts of diversion-points for and , respectively. Those diversion-points are recorded on the blockchain as the assets of and .
- 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 and then gets a diversion-voucher that can be used in next purchase at and . The is recorded on the blockchain and appears in the customer’s Wallet as an asset.
- The customer consumes at and then gets from a new diversion-voucher that may entitle the customer to use it at some other stores (including ) next time. The 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, has shared some of its customers with , 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.
4. Blockchain Subsystem
4.1. Hierarchically Permissioned Network
- 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.
4.2. Hybrid Data Model Supporting Multitype Assets
- , where:
- —hashpointer to the previous transaction;
- —private key of the initiator of the transaction;
- —public key of the current holder of the assets involved in the transaction;
- —public key of the issuer of the assets involved in the transaction;
- —symmetric key for encrypting sensitive information of the transaction;
- —diversion-points;
- —part of used for rewarding the issuer;
- —total discount of the diversion-voucher;
- —deadline by which the diversion-points or -voucher can be used;
- —a public key list indicating where the diversion-voucher can be consumed.
- , where:
- —public key of the store for the UTXO transaction to be looked up;
- BC—blockchain.
- , where:
- —identifier of the voucher of which the transactions are being queried;
- —public key of the store involved in the transactions to be queried;
- —public key of the customer involved in the transactions to be queried;
- —private key of the inquirer;
- —indicates where to query from, [‘Id’|‘Holder’|‘Issuer’].
- , where is the public key of the store of which the points’ usage is being examined.
- , where is the public key of the customer of whom the vouchers’ usage is being examined.
- , where is the public key of the store of which the diversion effect is being examined.
- 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.
- , where:
- —hashpointer pointing to the new generated transaction to be verified;
- —hashpointer pointing to the new UTXO transaction (if needed).
- , where is the public key of the store with which the shopping mall is going to settle.
4.3. Near-Real-Time Responding Consensus Protocol
Protocol 1. Cascading consensus protocol (CCP) |
Stage 1: |
Process 1 for |
|
|
Process 2 for |
|
|
|
|
|
|
Process 3 for |
|
|
Stage 2 |
Process 4 for all stores |
|
|
|
|
|
|
|
|
Process 5 for all stores. Let be the current store. |
|
|
|
|
- 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 of each store are strictly chronologically ordered.
4.4. Trust Building
- 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 issues vouchers that can be consumed at store , then the vouchers issued by must put in their . 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
5.1. The Effect in Balancing Customer Flow
- —identifier of the voucher;
- —diversion-points for the discount;
- —rewards for ;
- —total discount of the voucher;
- —scope of the voucher, .
- 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 use of diversion-vouchers makes the customer flow ratios of stores tend to balanceable. As shown in Figure 9, 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
- 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.
- 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 be the number of faulty nodes. By Process 2 (5) and Process 4 (7) in Protocol 1, we can get . Suppose the extreme case . In Stage 2 of Protocol 1, the leader node (i.e., the leader store) will receive valid tags, which means that there are 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, 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 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 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.
5.3. Performance
- 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.
- 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
6.1. Blockchain Data Models
6.2. Blockchain Consensus Protocols
7. Conclusions
Author Contributions
Funding
Conflicts of Interest
References
- Shen, L.; He, Y.; Li, L.; Chau, K. Impacts of online shopping convenience and physical retail proximity on housing prices in Shenzhen, 2016–2018. J. Hous. Built Environ. 2020. [Google Scholar] [CrossRef]
- Jin, C.; Jiang, J.; Zhu, D.; Chen, X. User experience improvement design of shopping mall based on crowd classification research. In Advances in Intelligent Systems and Computing, Proceedings of the 10th International Conference on Applied Human Factors and Ergonomics/AHFE International Conferences on Usability and User Experience, and Human Factors and Assistive Technology, Washington, DC, USA, 24–28 July 2019; Ahram, T., Falcao, C., Eds.; Springer: Berlin/Heidelberg, Germany, 2020; Volume 972, pp. 637–648. [Google Scholar] [CrossRef]
- Ruchi, M. Store layout as a determinant of consumer shopping behaviour in case of modern retail outlets. Asia Pac. J. Res. Bus. Manag. 2011, 2, 274–284. [Google Scholar]
- Ramadevi, V. A study on the influence of situational factors on the shopper’s behaviour with reference to the selected shopping mall, Bangalore. Int. J. Manag. 2015, 6, 36–45. [Google Scholar]
- Zielke, S.; Komor, M. Loyalty cards, credit options and economic market development. Int. J. Retail. Distrib. Manag. 2020, 48, 591–607. [Google Scholar] [CrossRef]
- Bülbül, Ş.; İnce, G. Blockchain-based framework for customer loyalty program. In Proceedings of the 3rd International Conference on Computer Science and Engineering (UBMK’18), Sarajevo, Bosnia-Herzegovina, 20–23 September 2018; IEEE: Washington, DC, USA, 2018; pp. 342–346. [Google Scholar] [CrossRef]
- Atulkar, S. Brand trust and brand loyalty in mall shoppers. Mark. Intell. Plan. 2020, 38, 559–572. [Google Scholar] [CrossRef]
- Rose, C.M. Game stories. Yale J. Law Humanit. 2010, 22, 369–391. [Google Scholar]
- Battalio, R.; Samuelson, L.; van Huyck, J. Optimization incentives and coordination failure in laboratory stag hunt games. Econometrica 2001, 69, 749–764. [Google Scholar] [CrossRef] [Green Version]
- ISO 22739:2020. Blockchain and Distributed Ledger Technologies—Vocabulary. Available online: https://www.iso.org/standard/73771.html (accessed on 19 November 2020).
- Li, X.; Jiang, P.; Chen, T.; Luo, X.; Wen, Q. A survey on the security of blockchain systems. Future Gener. Comput. Syst. 2020, 107, 841–853. [Google Scholar] [CrossRef] [Green Version]
- Morkunas, V.J.; Paschen, J.; Boon, E. How blockchain technologies impact your business model. Bus. Horiz. 2019, 62, 295–306. [Google Scholar] [CrossRef]
- Chen, C.; Sun, X.; Lu, G.; Kang, H.; Shen, Y. Bonus points alliance based on the block chain. In Proceedings of the 14th International Conference on Semantics, Knowledge and Grids (SKG‘18), Guangzhou, China, 12–14 September 2018; IEEE: Washington, DC, USA, 2018; pp. 229–234. [Google Scholar] [CrossRef]
- Yao, J.; Zheng, Y.; Guo, Y.; Cai, C.; Zhou, A.; Wang, C.; Gui, X. A privacy-preserving system for targeted coupon service. IEEE Access 2019, 7, 120817–120830. [Google Scholar] [CrossRef]
- Nizamuddin, N.; Hasan, H.; Salah, K.; Iqbal, R. Blockchain-based framework for protecting author royalty of digital assets. Arab. J. Sci. Eng. 2019, 44, 3849–3866. [Google Scholar] [CrossRef]
- Muñoz, A.; Maña, A. TPM-based protection for mobile agents. Secur. Commun. Netw. 2010, 4, 45–60. [Google Scholar] [CrossRef]
- Li, Y.; Ren, J. Providing source-location privacy in wireless sensor networks. In Lecture Notes in Computer Science, Proceedings of the International Conference on Wireless Algorithms, Systems, and Applications (WASA), Boston, MA, USA, 16–18 August 2009; Liu, B., Bestavros, A., Du, D.Z., Wang, J., Eds.; Springer: Berlin/Heidelberg, Germany, 2009; Volume 5682, pp. 338–347. [Google Scholar] [CrossRef]
- Morris, T. Trusted platform module. In Encyclopedia of Cryptography and Security, 2011 ed.; Van Tilborg, H.C.A., Jajodia, S., Eds.; Springer: Boston, MA, USA, 2011; pp. 1332–1335. [Google Scholar] [CrossRef]
- Abraham, I.; Malkhi, D. BVP: Byzantine vertical paxos. In Proceedings of the Distributed Cryptocurrencies and Consensus Ledger (DCCL), Chicago, IL, USA, 25 July 2016; IBM Research Europe: Zurich, Switzerland, 2016. Available online: https://www.zurich.ibm.com/dccl/papers/abraham_dccl.pdf (accessed on 20 November 2020).
- Rios, R.; Cuellar, J.; Lopez, J. Probabilistic receiver-location privacy protection in wireless sensor networks. Inf. Sci. 2015, 321, 205–223. [Google Scholar] [CrossRef]
- Hyperledger Fabric. Available online: https://www.hyperledger.org/use/fabric (accessed on 19 November 2020).
- Ethereum. Available online: https://ethereum.org (accessed on 19 November 2020).
- Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. Available online: https://bitcoin.org/en/bitcoin-paper (accessed on 19 November 2020).
- Nomura Research Institute, Ltd. 2010NEN NO KIGYO TSUUKA; Toyo Keizai Inc.: Tokyo, Japan, 2006; pp. 27–30. [Google Scholar]
- Bitcoin Developer. Available online: https://developer.bitcoin.org/glossary.html (accessed on 19 November 2020).
- Hoepman, J.H. Distributed double spending prevention. In Lecture Notes in Computer Science, Proceedings of the 15th International Workshop on Security Protocols, Brno, Czech Republic, 18–20 April 2007; Christianson, B., Crispo, B., Malcolm, J.A., Roe, M., Eds.; Springer: Berlin/Heidelberg, Germany, 2007; Volume 5964, pp. 152–165. [Google Scholar] [CrossRef] [Green Version]
- Chen, C.W.; Su, J.W.; Kuo, T.W.; Chen, K. MSig-BFT: A witness-based consensus algorithm for private Blockchains. In Proceedings of the IEEE 24th International Conference on Parallel and Distributed Systems (ICPADS‘18), Singapore, 11–13 December 2018; IEEE: Washington, DC, USA, 2018; pp. 992–997. [Google Scholar] [CrossRef]
- Merkle, R.C. A digital signature based on a conventional encryption function. In Lecture Notes in Computer Science, Proceedings of the Conference on the Theory and Application of Cryptographic Techniques, Advances in Cryptology (CRYPTO’87), Santa Barbara, CA, USA, 16–20 August 1987; Pomerance, C., Ed.; Springer: Berlin/Heidelberg, Germany, 1987; Volume 293, pp. 369–378. [Google Scholar] [CrossRef] [Green Version]
- Gentry, C. Fully homomorphic encryption using ideal lattices. In Proceedings of the 41st Annual ACM Symposium on Theory of Computing (STOC’09), Bethesda, MD, USA, 31 May–2 June 2009; ACM: New York, NY, USA, 2009; pp. 169–178. [Google Scholar] [CrossRef] [Green Version]
- Yu, P.; Zhang, S.; Zhong, J. Block-chain privacy protection based on fully homomorphic encryption. In Proceedings of the 3rd International Conference on Innovation in Artificial Intelligence (ICIAI’19), Suzhou, China, 15–18 March 2019; ACM: New York, NY, USA, 2019; pp. 239–242. [Google Scholar] [CrossRef]
- Simulator for Balancing Customer Flow (SBCF). Available online: https://github.com/lyonwong1982/SBCF/tree/master (accessed on 19 November 2020).
- Lamport, L.; Shostak, R.; Pease, M. The byzantine generals problem. ACM Trans. Progr. Lang Syst. 1982, 4, 382–401. [Google Scholar] [CrossRef] [Green Version]
- Castro, M.; Liskov, B. Practical Byzantine fault tolerance. In Proceedings of the 3rd Symposium on Operating Systems Design and Implementation (OSDI’99), New Orleans, LA, USA, 22–25 February 1999; ACM: New York, NY, USA, 1999; pp. 1–14. [Google Scholar]
- Xu, H.; Long, Y.; Liu, Z.; Liu, Z.; Gu, D. Dynamic practical Byzantine fault tolerance. In Proceedings of the 2018 IEEE Conference on Communications and Network Security (CNS’18), Beijing, China, 30 May–1 June 2018; IEEE: Washington, DC, USA, 2018. [Google Scholar] [CrossRef]
- Gueta, G.G.; Abraham, I.; Grossman, S.; Malkhi, D.; Pinkas, B.; Reiter, M.K.; Seredinschi, D.A.; Tamir, O.; Tomescu, A. SBFT: A scalable decentralized trust infrastructure for Blockchains. arXiv 2018, arXiv:1804.01626v1. Available online: https://arxiv.org/pdf/1804.01626.pdf (accessed on 19 November 2020).
- Crain, T.; Gramoli, V.; Larrea, M.; Raynal, M. DBFT: Efficient leaderless Byzantine consensus and its application to Blockchains. In Proceedings of the IEEE 17th International Symposium on Network Computing and Applications (NCA’18), Cambridge, MA, USA, 1–3 November 2018; IEEE: Washington, DC, USA, 2018; pp. 1–8. [Google Scholar] [CrossRef]
- Multithreaded Distributed Application Testbed (MDAT). Available online: https://github.com/lyonwong1982/MDAT/tree/master (accessed on 19 November 2020).
- Satoshi Client Node Discovery. Available online: https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery (accessed on 19 November 2020).
- Zhong, L.; Wu, Q.; Xie, J.; Li, J.; Qin, B. A secure versatile light payment system based on blockchain. Future Gener. Comput. Syst. 2019, 93, 327–337. [Google Scholar] [CrossRef]
- Koens, T.; van Aubel, P.; Poll, E. Blockchain adoption drivers: The rationality of irrational choices. Concurr. Comput. Pract. Exper. 2020, e5843. [Google Scholar] [CrossRef]
- Chen, Y.; Ding, S.; Xu, Z.; Zheng, H.; Yang, S. Blockchain-based medical records secure storage and medical service framework. J. Med. Syst. 2019, 43, 5. [Google Scholar] [CrossRef]
- Ma, S.; Wang, H.; Dai, H.N.; Cheng, S.; Yi, R.; Wang, T. A blockchain-based risk and information system control framework. In Proceedings of the IEEE 16th International Conference on Dependable, Autonomic and Secure Computing (DASC’18), 16th International Conference on Pervasive Intelligence and Computing (PiCom’18), 4th International Conference on Big Data Intelligence and Computing (DataCom’18) and Cyber Science and Technology Congress (CyberSciTech’18), Athens, Greece, 12–15 August 2018; IEEE: Washington, DC, USA, 2018; pp. 106–113. [Google Scholar] [CrossRef]
- Shahzad, B.; Crowcroft, J. Trustworthy electronic voting using adjusted blockchain technology. IEEE Access 2019, 7, 24477–24488. [Google Scholar] [CrossRef]
- Pérez-Solà, C.; Herrera-Joancomartí, J. BArt: Trading digital contents through digital assets. Concurr. Comput. Pract. Exper. 2020, 32, e5490. [Google Scholar] [CrossRef] [Green Version]
- Xuan, S.; Zhang, Y.; Tang, H.; Chung, I.; Wang, W.; Yang, W. Hierarchically authorized transactions for massive Internet-of-Things data sharing based on multilayer Blockchain. Appl. Sci. 2019, 9, 5159. [Google Scholar] [CrossRef] [Green Version]
- Zhang, C.; Wu, C.; Wang, X. Overview of Blockchain consensus mechanism. In Proceedings of the 2nd International Conference on Big Data Engineering (BDE’20), Shanghai, China, 29–31 May 2020; ACM: New York, NY, USA, 2020; pp. 7–12. [Google Scholar] [CrossRef]
- King, S.; Nadal, S. PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake. Available online: https://www.peercoin.net/assets/paper/peercoin-paper-nl.pdf (accessed on 19 November 2020).
- Delegated Proof of Stake (DPOS). Available online: https://how.bitshares.works/en/master/technology/dpos.html (accessed on 19 November 2020).
- Proof of Authority (PoA). Available online: https://openethereum.github.io/wiki/Proof-of-Authority-Chains (accessed on 19 November 2020).
- Wang, E.K.; Liang, Z.; Chen, C.M.; Kumari, S.; Khan, M.K. PoRX: A reputation incentive scheme for blockchain consensus of IIoT. Future Gener. Comput. Syst. 2020, 102, 140–151. [Google Scholar] [CrossRef]
- Gai, F.; Wang, B.; Deng, W.; Peng, W. Proof of reputation: A reputation-based consensus protocol for peer-to-peer network. In Lecture Notes in Computer Science, Proceedings of the International Conference on Database Systems for Advanced Applications (DASFAA’18), Gold Coast, Australia, 21–24 May 2018; Pei, J., Manolopoulos, Y., Sadiq, S., Li, J., Eds.; Springer: Berlin/Heidelberg, Germany, 2018; Volume 10828, pp. 666–681. [Google Scholar] [CrossRef]
- Lamport, L. The part-time parliament. ACM Trans. Comput. Syst. 1998, 16, 133–169. [Google Scholar] [CrossRef]
- Ongaro, D.; Ousterhout, J. In search of an understandable consensus algorithm. In Proceedings of the 2014 USENIX Conference on USENIX Annual Technical (USENIX ATC’14), Philadelphia, PA, USA, 19–20 June 2014; Gibson, G., Zeldovich, N., Eds.; USENIX Association: Berkeley, CA, USA, 2014; pp. 305–320. [Google Scholar]
- Lamport, L. Byzantizing Paxos by refinement. In Lecture Notes in Computer Science, Proceedings of the International Symposium on Distributed Computing, Rome, Italy, 20–22 September 2011; Peleg, D., Ed.; Springer: Berlin/Heidelberg, Germany, 2011; Volume 6950, pp. 211–224. [Google Scholar] [CrossRef]
- Lamport, L.; Malkhi, D.; Zhou, L. Vertical Paxos and primary-backup replication. In Proceedings of the 28th ACM Symposium on Principles of Distributed Computing, Calgary, AB, Canada, 10–12 August 2009; ACM: New York, NY, USA, 2009; pp. 312–313. [Google Scholar] [CrossRef] [Green Version]
- Liu, J.; Li, W.; Karame, G.O.; Asokan, N. Scalable Byzantine consensus via hardware-assisted secret sharing. IEEE Trans. Comput. 2019, 68, 139–151. [Google Scholar] [CrossRef] [Green Version]
- Intel SGX. Available online: https://software.intel.com/content/www/us/en/develop/topics/software-guard-extensions.html (accessed on 19 November 2020).
- Apache Kafka. Available online: http://kafka.apache.org (accessed on 19 November 2020).
- Apache ZooKeeper. Available online: https://zookeeper.apache.org (accessed on 19 November 2020).
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 |
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations. |
© 2020 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).
Share and Cite
Wang, L.; Liu, J.; Liu, W.; Wang, C. Blockchain-Based Diversion-Point System for Balancing Customer Flow in Shopping Mall. Symmetry 2020, 12, 1946. https://doi.org/10.3390/sym12121946
Wang L, Liu J, Liu W, Wang C. Blockchain-Based Diversion-Point System for Balancing Customer Flow in Shopping Mall. Symmetry. 2020; 12(12):1946. https://doi.org/10.3390/sym12121946
Chicago/Turabian StyleWang, Liang, Jiayan Liu, Wenyuan Liu, and Changwu Wang. 2020. "Blockchain-Based Diversion-Point System for Balancing Customer Flow in Shopping Mall" Symmetry 12, no. 12: 1946. https://doi.org/10.3390/sym12121946