Next Article in Journal
A Novel Cascade Model for End-to-End Aspect-Based Social Comment Sentiment Analysis
Next Article in Special Issue
A Novel Distributed Ledger Technology Structure for Wireless Sensor Networks Based on IOTA Tangle
Previous Article in Journal
A Novel Machine Learning Scheme for mmWave Path Loss Modeling for 5G Communications in Dense Urban Scenarios
Previous Article in Special Issue
Blockchain-Based Smart Propertization of Digital Content for Intellectual Rights Protection
 
 
Correction published on 26 August 2022, see Electronics 2022, 11(17), 2673.
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

A Peer-to-Peer Smart Food Delivery Platform Based on Smart Contract

Department of Computer Engineering, Jeju National University, Jeju 63243, Korea
*
Author to whom correspondence should be addressed.
Electronics 2022, 11(12), 1806; https://doi.org/10.3390/electronics11121806
Submission received: 6 May 2022 / Revised: 30 May 2022 / Accepted: 3 June 2022 / Published: 7 June 2022 / Corrected: 26 August 2022
(This article belongs to the Special Issue Blockchain Technology and Its Applications)

Abstract

:
The era of mobile information has arrived, and people’s lifestyles have undergone tremendous changes. Ordering takeaways through takeout apps on smartphones is one of them. However, most existing takeaway platforms charge high commissions in the middle. There are many fake reviews in restaurants, the authenticity of restaurant ratings is low, and the recommended dishes have low customer satisfaction. This paper aims to solve this problem by introducing a peer-to-peer architecture based on blockchain smart contracts. The proposed architecture leverages the automation of smart contracts to provide autonomous, commission-free food ordering and delivery services. In addition, the smart contract reward mechanism is used to collect order information and rating information, and a deep learning recommendation model is introduced to analyze the data to recommend restaurants and menus to the client accurately. To demonstrate the usability and efficiency of the proposed method, we conducted a case study using public chain-based technologies. At the same time, comprehensive evaluation experiments are carried out, and the results show the importance of the proposed food delivery system.

1. Introduction

With the rapid economic development and the accelerating pace of life, the catering industry has gradually improved the emerging takeaway model. The users of food delivery platforms are growing explosively. The shape of the market today Globally, the food delivery market is worth 83 billion euros, accounting for 1% of the overall food market and 4% of the food sold through restaurants and fast-food chains. It has matured in most countries, and the overall annual growth rate for the next five years is estimated to be only 3.5% [1]. More significant challenges also include developing new business models for app-based food delivery. In recent years, takeaway platforms have mainly encountered the following problems:
  • Degraded food quality: Maintaining food quality at the customer’s door is challenging, with distance and packaging making it challenging to maintain the same quality of freshness. In addition, customers cannot be sure that the food delivered is prepared in hygienic conditions;
  • Lack of discounts: The takeaway platform attracts users and restaurants to use the platform through substantial discounts. Due to such a significant discount strategy, restaurants increase the price of dishes, and the takeaway platform draws commissions, resulting in losses for both restaurants and users;
  • Manipulating food orders: Food delivery platforms can modify order prices and user evaluations privately, thereby misleading users to consume, resulting in a drop in customer satisfaction. At the same time, there are many fraudulent orders, which can increase restaurant sales by cheating;
  • The food delivery personnel often fail to deliver the meals to the user’s door on time. The food is damaged or lost during delivery, and the food delivery personnel and the restaurant directly shirk their responsibilities.
In a centralized take-out platform, take-out information is subject to a greater degree of human intervention. As a result, the authenticity of the data and information of the food delivery platform is reduced, and solving these problems has become the primary goal at present. The use of blockchain technology [2] in food delivery platforms will solve the above problems. Blockchain, in a nutshell, is a decentralized database that stores data in “blocks” that are connected to form a distributed ledger technology that provides an immutable and unchangeable record of all transaction blocks. The security and transparency provided by chain technology make it sufficient to regulate business operations effectively. For example, the food industry supply chain contains multiple players, such as raw material suppliers, restaurants, food delivery platforms, delivery agents, and consumers.
The blockchain helps verify the authenticity between industries and effectively develops an efficient and trust-based ecosystem. This article applies blockchain to the food delivery platform and has the following advantages:
  • Improve the reliability of the supply chain: Blockchain can help users verify the authenticity of the supply chain. Such as the freshness of raw materials, expiration date, etc.;
  • Seamless commission distribution between food delivery staff and restaurants: Since the related parties are connected, both commission distribution and payment must be paid through the takeaway platform. Using the blockchain can make point-to-point payments and cancel the high cost of the intermediate takeaway platform—the amount of service commission;
  • Blockchain helps to uphold the strict safety standards of the food industry. It tracks all actions performed by the delivery person and the restaurant; any regulatory violations can be tracked before commissions are paid, reducing payment delays due to investigations;
  • Centralized authority and trust issues: Solving trust issues between food delivery platforms, restaurants, food delivery staff, and customers has become a breeze thanks to blockchain-powered applications. A decentralized blockchain system provides transparency to all members of the ecosystem.
Blockchain technology is usually used in supply chain and traceability solutions for food safety. Traditionally, it is used in takeaway platforms to undertake the docking relationship between restaurants and customers, B2C. The blockchain food delivery platform will automate the process of ordering and delivering meals through intelligent contract technology, making them compliant with food safety regulations.
The mainstream food delivery platform recommendation systems (RS) provide users with catering screening methods mainly through user ratings, price ranges, and distances. At the same time, most of the existing food delivery software algorithms are user-based collaborative filtering algorithms, which are difficult to achieve personalized and accurate food delivery. The algorithm application scenarios are highly limited. Especially in the blockchain food delivery platform, personalized recommendation algorithms are difficult to implement because the anonymity of the blockchain makes it impossible to collect user information. However, while big data analytics has long been used to support humans in processing user input and making decisions, they need to introduce new, scalable RS algorithms has become apparent [3]. The application of machine learning in this context has significantly driven recommendation algorithms. Moving from traditional RS [4], Ref. [5] using clustering, nearest neighbor, matrix factorization, and collaborative filtering to a new generation of RS, a new generation of recommender systems in depth with the support of the learning system, a wide and diverse field of application has been developed. These include e-commerce [6], social media [7] and networking [8], e-learning [9], social behavior analysis [10], energy savings [11], healthcare [12], Internet of Things [13], travel [14], fashion [15], and food industry [16].
Research Questions Addressed in this Study:
(1)
Research and analysis of the existing food delivery market and food delivery platforms;
(2)
There are high commissions for takeaway platforms, fake reviews, trust issues, and order bias on centralized platforms;
(3)
It is difficult to query order information (other than private information) publicly, and the degree of order automation is low;
(4)
The method of data information collection involves the issue of data information privacy;
(5)
The self-recommended degree of preference for items in the personalized recommendation system;
(6)
There are scalability issues related to blockchain in large-scale data storage and management.
Problem Solving Challenges:
(1)
Since food delivery is a multi-terminal collaborative work, applying the blockchain to the emergency judgment of the point-to-point food delivery platform is difficult;
(2)
The credibility of the data cannot be guaranteed until the data is stored on the blockchain;
(3)
The protection of public data and private data in transaction data;
(4)
Large-scale order transactions; the efficiency of blockchain network transaction processing;
(5)
The decentralized food delivery platform can only guarantee the authenticity and validity of the data, and it is difficult to deal with disputes;
(6)
It is difficult to encrypt and process private data to prevent the leakage of private data;
(7)
The problem of user initiative in the collection of datasets in recommender systems.
Contributions of This Research:
(1)
Solve the problems of high commission and false information of existing food delivery platforms based on public chain technology and smart contracts;
(2)
Provide point-to-point take-out services to improve transaction and service efficiency between clients;
(3)
Provide automatic function services based on smart contracts. This article completes the business through smart contracts’ life cycle (contract status);
(4)
Based on the automatic reward mechanism of smart contracts, users provide and collect evaluation data sets independently and introduce a deep learning recommendation model to realize a high-precision and automatic recommendation system.
The rest of this paper is structured as follows: Section 2 reviews recent food delivery industry surveys and blockchain implementation cases in food delivery platforms. Section 3 introduces the designed peer-to-peer food delivery platform architecture and describes the business processes in the system. Section 4 introduces the architecture for designing recommender systems and describes how smart contracts work in recommender systems. Section 5 details the case study implementation and interaction process for the three clients, showing the implementation results through various screenshots. Section 6 evaluates the performance of the proposed food delivery platform. Section 7 summarizes the whole paper and points out future research directions.

2. Related Work

The birth of the blockchain is the result of the evolution of the entire business society. The first half of the human world was a centralized process. Various powers, business institutions, and the establishment of corporate systems, etc., in the digital world continue the centralized mechanism. At this point, the centralized organizational structure has faced the following certain obstacles to economic development:
  • Privacy protection issues. At present, user data is concentrated on platforms such as WeChat, and the data belongs to the users themselves;
  • Cost issues. As the number of nodes increases, the cost of data usage will gradually increase;
  • Ownership issues.
These problems have led to the call for a decentralized business structure in the entire digital world.
In this context, in September 2009, Satoshi Nakamoto’s “a peer-to-peer electronic currency transaction mechanism” [17] appeared on the Internet, and the industry discovered blockchain technology in 2013. The world is in turmoil, especially in the financial sector.
As shown in Figure 1. Blockchain is a new application mode of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. In a narrow sense, blockchain is a chain data structure that sequentially combines data blocks according to time sequence and is cryptographically guaranteed to be an untameable and unforgeable distributed ledger. Blockchain technology uses blockchain data structures to verify and store data, the use of distributed node consensus algorithms to generate and update data, the use of cryptography to ensure the security of data transmission and access, and the use of automated scripts. A new distributed infrastructure and computing method for programming and manipulating data with smart contracts composed of code.
In recent years, blockchain technology has been widely used in various industries [18], and blockchain has established new advanced functions for the commercial and industrial world [19]. These capabilities help enhance, optimize, secure and simplify many existing business and industrial processes. With the gradual maturity of technology, blockchain technology has also been applied in the food delivery industry. Traditional food delivery platform companies have exposed many problems. Even if the division of responsibilities is clear, the processing results may not be executed. This phenomenon is caused by the concentration of power in traditional centralized food delivery platforms. Therefore, traditional food delivery platforms are also constantly transforming into blockchain scenarios.
According to the “Analysis Report on the Development of China’s Food Delivery Industry in the First Half of 2019” released by Trustdata [20], the growth rate of China’s food delivery industry slowed down in the first half of 2019. However, it still maintained a rapid growth rate. From 461.3 billion yuan to 603.5 billion yuan (Figure 2).
According to the 44th Statistical Report on China’s Internet Development by CNNIC, as of June 2019, the scale of online takeaway users in China reached 421 million, 15.16 million more than that at the end of 2018, accounting for about half of the overall scale of Internet users (Figure 3).
Bistroo [21] was established during the COVID-19 pandemic as a platform that combines blockchain and food delivery, providing direction for the rapid development of the food delivery ecosystem. It is a peer-to-peer marketplace for consumers to order food and beverages directly from restaurants and other food merchants, with restaurants able to communicate directly with consumers while providing customers with menus that can be customized to their preferences, including pricing and real-time updates. Notably, the platform’s customers reap enormous benefits, including attaching to and leveraging their existing payment system, paying 5% fewer transaction fees than rival platforms’ 15% fees. Moreover, released the platform token BIST. Regarding B2C advantages, customers of the platform can use BIST to pay for meals, providing more favorable prices than fiat currencies (Figure 4).
Eatzilla [22] platform is an online food delivery management solution that any entrepreneur can use to start their own online food delivery business. Eatzilla food delivery solution is not just another Ubereats clone script. It has all the basic features of popular online food delivery and ordering platforms. The Eaztilla food delivery solution runs on the Hyperledger Sawtooth blockchain to solve various real-world problems current online food delivery platforms face via encryption and support payments that you will not find in other Ubereats clone scripts.
Problem with the current system are as follows:
(1)
Food quality low
The main issue facing takeaways right now is food quality. Many friends have been diagnosed with food poisoning after ordering food online. This is because the person who eats the food does not know details such as when the food is prepared.
(2)
High discounts, high cost
When ordering takeout, the first thing that comes to mind is the discount. Companies are giving people more discounts than usual. Therefore, people are attracted to buy food from them. However, restaurants are heavily affected by these discounts. As restaurants promote discounts on a seasonal basis, restaurants face huge losses, for which restaurants increase unit prices and end-users bear high costs.
(3)
Order manipulation
In the case of food delivery, order manipulation is common. The customer gives the wrong address and gives completely false details. Sometimes, even the service company can eliminate orders that customers have already fulfilled.
(4)
Lack of transparency
One of the significant angles that makes your clients reconsider before requesting is the absence of straightforwardness. With food being one reason for all the illnesses, individuals are additional mindful about requesting food on the web.
Centralized food delivery platforms and blockchain-based food delivery platforms in the market environment are very different in function and data information processing. We investigate payment methods, reward activities, commission fees, advertising recommendation systems, data storage, management, and delivery for existing food delivery platforms. By collecting food delivery platforms with a large proportion of each country, compare the performance and degree of blockchain platforms and non-blockchain platforms in the above aspects.
As can be seen from Table 1, the blockchain-based food delivery platform has high advantages in commissions and management and is more credible. In the B2C food delivery platform environment, the distributed blockchain is less dependent on the server and can cope with high frequency. The accident server configuration requirements are high, and the cost is high. The server configuration and the accident rate can be effectively reduced based on the blockchain. Provide a more efficient takeaway platform environment.
This paper compares the recently proposed methods and models with the model proposed in this paper. The main comparison is divided into the following two aspects: rationale and benefits. By comparing the relevant blockchain application platforms, the comparison with the model proposed in this paper is analyzed. As shown in Table 2, Article 1 points out that the multi-chain blockchain architecture solves the problem of information collection and traceability in each client of the supply chain platform. Article 2 points out that the B2B blockchain platform solves the problem of online and offline food sales and distribution management. Article 3 points out the transparency and reliability of distributed blockchain solutions for supply chain platforms. Article 4 proposes to decentralize knowledge graph construction through smart contract crowdsourcing. Article 5, this paper points out the point-to-point blockchain smart food delivery service, which provides smart contract-centric smart recommendation services. This article focuses on smart contracts and builds the application functions of the food delivery platform. Others on the automatic processing and application of smart contracts [23,24,25] clarify the important position of smart contracts in decentralization.
This paper compares the recently proposed methods and models with the model proposed in this paper. The main comparison is divided into the following two aspects: rationale and benefits. By comparing the relevant blockchain application platforms, the comparison with the model proposed in this paper is analyzed. As shown in Table 1, Article 1 points out that the multi-chain blockchain architecture solves the problem of information collection and traceability in each client of the supply chain platform. Article 2 points out that the B2B blockchain platform solves the problem of online and offline food sales and distribution management. Article 3 points out the transparency and reliability of distributed blockchain solutions for supply chain platforms. Article 4 proposes to decentralize knowledge graph construction through smart contract crowdsourcing. Article 5, this paper points out the point-to-point blockchain smart food delivery service, which provides smart contract-centric smart recommendation services.

3. Designing a Peer-to-Peer Blockchain Food Delivery Platform

This paper proposes a blockchain-based take-out platform recommendation system, which only needs to provide a decentralized take-out ordering platform to connect restaurants and customers directly. The blockchain provides the whole service process, from the customer’s order to the receipt of the meal. We define the states of the three processes of order generation, meal preparation, and meal delivery, which use smart contracts to provide services and record the data information generated by each process. The design process and implementation process of the three stages will be described in detail below. Secondly, we added a recommendation system based on smart contracts and deep learning to the food delivery platform to improve user satisfaction. A recommendation system based on smart contracts creates smart contracts to enable users to participate in smart contracts (ratings, preferences, consumption history). Smart contracts can obtain user data with user authorization and input the data as samples to the recommendation algorithm (collaborative filtering, utility matrix, knowledge graph). The results are used as an output to recommend content to customers. The sample data based on smart contracts ensure that the data is authentic and effective without revealing customer privacy. As a smart contract participant, users can view the recommendation system model of the smart contract or upload a custom recommendation system model at any time and accurately recommend information to improve the user experience. The recommendation algorithm model based on deep learning inputs the data generated by the smart contract as sample data into the neural network to generate a recommendation model for higher-precision content recommendation.
This article deploys the food delivery platform on the blockchain. Figure 5 shows the architecture of the blockchain food delivery platform. The blockchain food delivery platform is divided into application, interface, and infrastructure layers in design principles. The Application Layer is mainly responsible for DAPP business functions, providing customer management, restaurant management, DeliverMan management, order management, evaluation management, and recommendation management. The Interface Layer provides an integrated API interface for the application layer to call and provides a user interface, a wallet interface, an order interface, a data query interface, an evaluation interface, a smart contract management interface, and a recommendation system interface in the Interface Layer. The Blockchain Core Layer provides operation block services through an SDK. Multiple modules are set up on the blockchain, such as identity management, authority, query, and smart contracts. The consensus service of the whole network is provided through the consensus algorithm, and other transactions are run through the event stream. The data information collection and recommendation model consensus in the recommendation system are released in the form of smart contracts, so the recommendation system integrates the recommendation service function through the interaction of the SDK and the blockchain. At the same time, it provides blockchain network data communication. Off-chain data is stored in IPFS and databases. The infrastructure layer provides a basic network operating environment and improves blockchain network performance through cluster and cloud server virtualization.

3.1. Infrastructure Layer

The infrastructure layer is to provide the basic network operating environment and hardware. The specific content includes virtual management, resource load control, load balancing, cloud management platform, and container cloud platform, which together provide a collaborative operating environment for the blockchain network because the content of the blockchain is hosted on a server that resides in a data center. While browsing the web or using applications, clients request content or data from application servers, commonly referred to as client-server architecture. Blockchain is the P2P network of computers that computes transactions, validates, and stores them in an ordered form in a shared ledger. This results in a distributed database that records all the data, transactions, and relevant information. Each computer in a P2P network is known as a node. Nodes are accountable for validating transactions, organizing them into blocks, broadcasting them to the blockchain network, and it keeps on. While reaching consensus, the nodes commit the block to the blockchain network and update their local ledger copy. The blockchain network can be divided into categories. It is a public blockchain, a private blockchain, and a consortium blockchain. This article uses the public chain blockchain for testing and development. Business application deployments formulate network preferences based on their business environment. The infrastructure layer of the infrastructure platform is the basic guarantee of the blockchain network architecture.

3.2. The Composition of the Core Layer of the Blockchain

The core layer of the blockchain consists of the data layer, the network layer, and the consensus layer, which are collectively referred to as the core layer of the blockchain in this paper, which conforms to the architecture model of this paper. The core layer of the blockchain in this paper consists of the blockchain event component and the recommendation system to form a complete core layer. The blockchain event component is responsible for event operations, API management, and SDK management of the blockchain in the core layer. The blockchain’s identity management, authority management, query management, and contract management are realized by integrating API and SDK. Identity management provides member services such as registration and login and information security management. The core service of the blockchain is the consensus service, which is the basic service that drives the underlying operation of the blockchain. It mainly includes the consensus mechanism, distributed ledger, P2P protocol network, and ledger storage. The four functions jointly drive the operation of the blockchain network.

3.2.1. Data Layer

The blockchain stores data through blocks, and each data node contains all the data. The data layer is mainly to solve the form in which these data are combined to form a meaningful block. The ledger storage in the blockchain is the process of data storage. When data is stored in data blocks, namely, blocks, blockchain data includes both block data and state data. The block data describes the records of each transaction that occurs on the blockchain. In contrast, the state data records the current state of each account and smart contract, and both block data and state data are used and stored by our blockchain nodes. A blockchain node is a program that allows multiple nodes to be linked through a network on our computers and virtual machines. Moreover, finally, form a complete blockchain network. The most common way of data storage of blockchain nodes is to store it in the middle of our disk. Our blockchain will not directly access our disk but through specific databases such as LevelDB, CouchDB, and MySQL. An independent and distributed database is used to operate our data. A specific data access model using a database as an intermediate medium is more friendly to blockchain nodes than direct disk access.
As shown in Figure 6, when blocks are stored, blocks are stored in the form of file blocks (blockfile_xxxx). The general file block size is 64M (hard-coded; changes need to be re-edged), and the maximum capacity of the ledger is 64 × 1,000,000. Multiple blocks can be generated for storage files, and the offset needs to be specified when querying. When querying data, the block index is first performed to associate the block’s attributes with the location, and the level DB storage is used to query the block through the block index. First, the block is quickly located. Then, the index key (block height, block hash, transaction hash) and index value (block file number, offset in the file, block data length) for file indexing. The state database in Figure 6 can be understood as the latest data on the blockchain [30]. It is constantly updated as the transaction volume increases. If it is lost, it can be synchronized with the blockchain. When the two are inconsistent, the blockchain file system is used. Data shall prevail.
The index of the historical transactions of specific data does not store any state value. Suppose the user needs to query the change history of a certain number. In that case, he can quickly find the block index of the transaction related to the changed data through the history state index. The storage process of the accounting node first saves the block file, appends the block, or creates a new file block, then updates the block index (invalid transactions will also be stored), updates the world state (invalid transactions will not be updated), and updates the historical state. The three are executed sequentially. From Chapter 1, it can be seen that the on-chain transaction process of the blockchain is divided into the following three steps: transaction simulation (read-write set (EWSet)), transaction sorting, and transaction verification (state update (update write set)). In the read-write set (EWSet) function process, the read set is used to read the submitted state key-value pairs; the write set is used to update, add, and delete marker key-value pairs; the version number is used to control the block height and transaction number. The transaction verification process is mainly to verify the transaction read-write set (as well as signatures and certificates) only related to the read set. The read set version number refers to the version number of the world state (including uncommitted pre-order transactions). The above process communicates with level DB/CouchDB and finally completes the ledger’s storage, reading, and writing (data).
In this article, according to the business logic process of takeaway, the important data of commodity, user, and order are stored in the block, and other data is stored in IPFS. As shown in Figure 6, the data in the block is encrypted by the hash encryption algorithm and stored in the block. The user verifies and parses the data information in the access blockchain through the transaction hash value. Due to the high storage cost on the chain, the general data is encrypted by the hash algorithm and stored in IPFS to obtain the IPFS data storage address and store it in the block storage area. In this article, the user’s private key is used to encrypt IPFS file data. Accessing IPFS data files requires access to be verified by a private key signature, ensuring the privacy and security of sensitive data.
This paper stores important text data (transaction objects, order prices, and order names) in the blockchain. General data (pictures, recommended models) are stored in IPFS to reduce the waste of block capacity. At the same time, the address of general data will also be stored in the block to ensure the integrity of the information when querying the order. Figure 7 shows the data classes that need to be stored when generating an order. According to the data generation process of the order, the orders are packaged and stored in the block in order. An order determines the order process by recording the transaction time because each process of the order (It is necessary to confirm the order status (transaction) when generating an order, accepting an order, dispatching an order, and completing an order. The process of submitting the order status is the process of transaction generation, so the process of confirming the order through the transaction time can store the data class and transaction generated by the order. The process of state is the process of ledger storage.

3.2.2. Network Layer

After the data is combined in order, it needs to be broadcast to other nodes. Since the blockchain does not have a centralized server, users need to exchange information point-to-point, mainly using P2P for information exchange. P2P is the abbreviation of peer-to-peer, also known as peer-to-peer technology. It is a peer-to-peer network with no central server and relies on user group nodes for information exchange. Unlike the traditional C/S central server structure, each user node in the P2P network is both a client and a server and can simultaneously serve as a server to provide other nodes. As shown in Figure 8.
Features of P2P network are as follows:
(1)
Scalability.
In a P2P network, users can join and leave the network. Moreover, with the addition of user nodes, the overall service capability of the system is also improved accordingly. For example, in a P2P download, the more users join, the more resources are provided in the P2P network, and the download speed will be faster and faster.
(2)
Robustness.
Since there is no centralized server in P2P, it is inherently resistant to attacks and has high fault tolerance. Even if a node in the network is attacked or offline, it will not affect the regular operation of the entire system because each node in the P2P network can act as a server.
(3)
High-cost performance.
The network using the P2P structure can effectively utilize a large number of scattered ordinary user nodes on the Internet. To achieve high-performance computing and mass storage, use idle CPU, bandwidth, and storage resources in these ordinary nodes.
(4)
Privacy protection.
In the P2P network, since the transmission of information is scattered among various nodes, it does not need to go through a central server. This reduces the risk of user privacy information being eavesdropped on and leaked.
(5)
Load balancing.
In the P2P network, resources are scattered and stored on multiple nodes, and each node can act as a server. When a node needs to obtain resources, it only needs to send a request to the adjacent node, which well realizes the load balancing of the entire network. The main functions of the P2P network are data distribution and transmission, data storage and retrieval, and distributed data processing. This paper applies the P2P protocol network to the decentralized blockchain.

3.2.3. Consensus Layer

Consensus mechanism in the blockchain network, different consensus algorithms are used due to different application scenarios. At present, there are the following four main types [31] of consensus mechanisms in the blockchain: proof of work (pow), proof of stake (pos), delegated proof of stake (Dpos), and verification pool consensus (pool).
(1)
Proof of work (pow)
Proof of work (POW): It can be simply understood as proof that a certain amount of work has been performed. By looking at the results of the work, you will know that the specified amount of work has been performed. The most used blockchain consensus algorithm is POW. Both Bitcoin and Ethereum are POW-based consensus mechanisms.
Advantages: Completely decentralized, nodes can enter and exit freely, avoiding the cost of establishing and maintaining a centralized credit institution. As long as the computing power of the network disruptors does not exceed 50% of the total computing power of the entire network, the transaction status of the network can be agreed upon, and historical records cannot be tampered with. The more computing power is invested, the greater the probability of obtaining the bookkeeping right, and the more likely it is to generate new block rewards.
Disadvantages: At present, Bitcoin mining causes a lot of waste of computing power and energy. The incentive mechanism of mining also results in a high concentration of mining computing power. The settlement cycle is long, and a maximum of seven transactions are settled per second, which is not suitable for commercial applications.
(2)
Proof of stake (pos)
Proof of stake (POS): The number and duration of holding Tokens (tokens) determine your probability of obtaining bookkeeping, similar to the dividend system of stocks. Obtain more dividends. The token is equivalent to the rights and interests of the blockchain system.
Advantages: Reduce the resource waste of the PoW mechanism. The speed of operation is accelerated, which can also be understood as an upgraded version of proof of work.
Disadvantages: Nodes with a longer coin age have a greater chance of obtaining the right to bookkeeping, which is likely to lead to the Matthew effect.
(3)
Delegated Proof of Stake (Dpos)
Delegated proof of stake (DPOS): it is a more professional solution derived from POS. It refers to people who have Tokens to vote for fixed nodes and elect a number of agents who are responsible for verification and recording. Account. Unlike POW and POS, the entire network can participate in the bookkeeping competition, and the bookkeeping node of DPOS is determined within a certain period of time. In order to motivate more people to participate in the election, the system will generate a small number of tokens as a reward.
Advantages: Compared with pow, Dpos greatly improves the blockchain’s ability to process data, and can even achieve a second account receipt, while also greatly reducing the cost of maintaining blockchain network security.
Disadvantages: The degree of decentralization is weak, the node agent is artificially selected, the fairness is lower than that of POS, and it relies on the additional issuance of tokens to maintain the stability of the agent node.
(4)
Verification Pool Consensus (pool)
The verification pool consensus mechanism Pool is a consensus mechanism based on traditional distributed consensus technology and a data verification mechanism that is currently widely used in the industry chain. Advantages: Second-level consensus verification can be achieved without relying on tokens. Disadvantages: The degree of decentralization is weak, and it is more suitable for a multi-center business model with multi-party participation.
In this article, we choose to deploy the public chain Fantom test network as the development network. The Fantom Foundation team aims to introduce a more scalable, secure, and decentralized infrastructure through Fantom. So Fantom is a scalable, decentralized smart contract platform that leverages the PoS model to secure the network using its proprietary Lachesis consensus mechanism, on top of which multiple other blockchain layers can be supported. This consensus engine can process up to 10,000 transactions per second, regardless of the execution speed of confirmed transactions. The Lachesis protocol allows the network to achieve consensus using asynchronous Byzantine fault-tolerance (aBFT). In other words, it is similar to a network that employs Byzantine fault-tolerance, where even if one-third of the nodes are malicious, the network can still be trusted to validate and produce blocks in the correct order and time.

3.2.4. Contract Layer

The contract layer mainly refers to various script codes, algorithm mechanisms, and smart contracts. A smart contract is a piece of code stored on the blockchain. They can be triggered by exchanges on the blockchain. After being triggered, this code can read data from the blockchain or write data to the blockchain. In this way, the program algorithm is used to replace people to arbitrate and execute contracts [32]. Smart contract management based on blockchain technology includes the following five aspects: contract construction, contract operation, contract upgrade, contract abolition, and contract audit.
(1)
Contract construction includes writing code, compiling, deploying, and instantiating, and writing code is written in computer language. Contract code, compilation, and deployment is the process of converting the contract code into a format executable by the runtime environment and deploying it to the blockchain network nodes. Contract construction must meet the following: The smart contract code writing should comply with normative requirements such as code writing specifications, logic requirements, security requirements, confidentiality requirements, etc.; the compilation entity of the smart contract should be verified, and the content of the strategy and signature should be written; the content of the smart contract should be the hash value is written to the blockchain ledger;
(2)
Contract operation includes contract triggering and contract execution. Contract triggering is the process of invoking a contract and entering into contract execution. Contract triggering can be divided into direct invocation, inter-contract invocation, and oracle invocation. Contract execution is the process of executing smart contract logic. The contract operation must meet the following requirements: The operation carrier, such as a virtual machine, container, etc., should be provided to ensure that the smart contract operating environment is isolated from the outside world, and the blockchain system cannot be modified by calling the smart contract; for smart contracts that interact with external data of the blockchain system, The influence of external data is limited to the scope of the smart contract and should not affect the overall operation of the blockchain system. When an error occurs in the operation of the smart contract, the smart contract should be provided with the function of suspending the execution or restarting;
(3)
The contract upgrade must meet the following: the contract upgrade should be supported, and the contract should be repaired and functionally improved; the client should initiate an interface call and submit it to the blockchain system, and it will take effect after the nodes reach a consensus; the contract upgrade operation should be recorded in the block. In the chain system, it conforms to the transaction requirements in the blockchain and follows the process of transaction execution; the historical version of the contract should be retained in the blockchain system and should no longer be executed;
(4)
Contract abolition must meet the following: it should support the abolition of deployed smart contracts; it should carry out permission access control; it should be submitted to the blockchain system in the form of interface calls; it will take effect after the nodes reach a consensus; the contract abolition version should continue to remain in the area. In the blockchain, it should no longer be executed;
(5)
Contract audits should include design and business logic security audits, source code security audits, compilation environment audits, privacy audits, confidentiality audits, and emergency response audits.
The smart contract in this article is created according to the type of food delivery business. As shown in Figure 9, the Recommend Contract is used for recommendation information (such as products, advertisements, etc.) pushed by the recommendation system and authorized by the user; the Advertisement Contract is used for the recommendation of restaurant advertisements, and the restaurant pays the advertisement fee. The smart contract automatically executes the advertisement display and pushes the advertisement display event to the recommendation system to complete the advertisement recommendation. When the user selects a product, the Coupon Contract and Evaluation Contract are triggered to choose whether to use coupons and participate in the evaluation. The restaurant and the user build the product status life cycle through the Commodity Contract, create an order through the Order Contract, and call the Payment Contract to activate the payment status. The Token is temporarily stored in the Smart Contract; the Order Contract completes the contract life cycle by changing the order status. After the order is created, the restaurant makes meals, delivers meals, and activates the Delivery Contract. At this time, the restaurant, the Deliveryman, and the user participate in the Delivery Contract together; the user receives the confirmation of the meal in the received state; the life cycle of the Delivery Contract ends; the Order Contract determines whether the Compensation Contract is activated abnormally. If the order is normally paid for the temporarily stored Token, the restaurant and Deliveryman will receive the fee, and if the order is abnormal, the Compensation Contract will be executed. Evaluation Contract legally collects user evaluation information and private information by issuing discount coupons to users and provides sample data sets for recommendation systems.
As shown in Figure 10, most of the food delivery businesses in this article are traded and recorded on the blockchain through smart contracts, which ensure the authenticity of the transaction and achieve the purpose of being unmodifiable. At the same time, when all the trigger conditions in the smart contract are met, the smart contract automatically executes the transaction. In the food delivery platform, all smart contracts are issued and managed by the platform, and users, restaurants, and couriers participate in the smart contracts as participants. As shown in Figure 9, the smart contracts all run in the model of Figure 10, and each smart contract executes events that automatically satisfy the conditions by its internal functions. For example, the participating users control the evaluation contract and obtain relevant information, and the obtained information provides the customer data set for the recommendation system below.
Smart contracts are usually issued by the project issuer (platform side). After the blockchain verifies the contract code, it is open and transparent in the blockchain browser for users to view. The smart contract will be stored in the block after the smart contract is successfully released, as shown in Figure 11. Functions are used in the smart contract to design response conditions, response rules, contract status, and contract values. When the smart contract is called, external data and events are input, and the response conditions determine the user’s authorization. The rule that triggers the response, the contract rule returns the corresponding contract value when the specified contract state is satisfied and outputs the result when the rule (function) is judged to satisfy the rule. For example, a Payment Contract temporarily stores the cost in the smart contract when the user pays the meal fee and delivery fee. The status of the smart contract keeps changing after the steps of picking up, delivering, and completing the order. After the completion of the order rule is triggered, the order process is completed, and the fee is paid to the restaurant and the delivery staff separately. Changes throughout the process are recorded in the blockchain and published to the blockchain after consensus verification.

3.3. Interface Layer and Application Layer Design

The realization of the function of the food delivery platform requires calling the API interface to operate the underlying blockchain network. In this article, the interface layer is used to integrate APIs such as account authentication, authority management, blockchain browser, wallet management, smart contracts, and data query. The account authentication function is used to realize the real-name authentication of take-out consumption in accordance with local laws and regulations, integrate the real-name authentication interface, and manage and identify the real-name authentication result and the registered address of the account through the blockchain identity management service. Permissions are controlled using EOS smart contracts [33] in permission management. Under normal circumstances, the smart contract is used to verify the user’s relevant permissions, order query, and transaction query. When the user queries the transaction history, the smart contract executes the verification procedure and calls the addresses of the contract participants for comparison.

3.3.1. Interface Layer

This section describes the operation authority of the data contract and the design of the smart contract interface function. The data contract access and verification process, that is, permission access control, obtains logical contracts and data contracts by decoupling business logic and business data. The data contract includes a first data contract and a second data contract; the first data contract is used to store the business data-id and the address of the second data contract; the second data contract is used to store the business data. Obtain the registration information of the registrant and generate the registrant authority module, and generate the registrant authority according to the registration information and the authority of the logic contract to access the data contract, where the registrant authority is the authority of the registrant to read and write business data. When the user accesses, the access information (private key) of the visitor is obtained, and according to the access information, it is determined whether the visitor has the registrant authority. If it has the registrant authority, the visitor is allowed to read and write business data. If the visitor does not have registrant authority, the visitor is prohibited from reading and writing business data.
As shown in Figure 12, the coupling relationship between the logic contract and the data contract generates the authority of the logic contract to access the data contract mainly includes the following: Firstly, obtaining the address of the logic contract, the address of the first data contract, the business data-id, and the address of the second data contract, according to The logical contract address and the first data contract address generate the first access authority, and the first access authority is the authority of the logical contract to access the first data contract; the second access authority is generated according to the first data contract address, the business data-id, and the second data contract address permission, and the second access permission is the permission of the first data contract to access the second data contract. So as to control the user’s permission to read and write the blockchain on the blockchain.
Smart contracts are described in Section 3.2.4. In this section, smart contracts are designed according to business function classifications. As shown in Figure 13, the order contract faces three processes and eight functions to control the contract. When the user places an order, first use the function getPayment() to create an order, and the restaurant accepts the order when it receives the order. The function acceptOrder() is used to complete the order acceptance on the chain. At this time, the function confirmIntention() is called to push the order message to the Deliveryman, and the Deliveryman accepts the order. When the restaurant is preparing the meal, after the preparation is completed, call function callSecondDeliveryman() to push the timestamp of meal preparation completion to the Deliveryman; Deliveryman clicks to pick up the meal to call function pickupOrder() and record the pickup time; the Deliveryman sends the meal to the customer’s location to call function deliveryOrder() delivers the order; when the delivery order status is completed, the smart contract automatically executes the function contestOrder() to check whether there is a timeout or a violation. If a problem occurs and the user agrees to cancel the order, the function cancelOrder() will be called to execute and complete the smart contract. The above process is automatically executed using smart contracts to complete the takeaway order process to improve user credibility.
As shown in Figure 14, smart contracts are deployed on each interface of the interface layer to ensure the decentralization of the blockchain food delivery platform. The food delivery platform creates smart contracts when publishing items (reviews, discounts, recommendations, advertisements) on the blockchain, and users participate in the smart project contracts. When a user participates in a smart contract, in addition to the project contract, they also need to participate in a storage contract, which is used to store user data information, such as evaluation information, information about the content they like, etc. When the user participating in the project meets the conditions of the smart contract, they execute the function addInformation() to store the data information in the blockchain. The food delivery platform queries the participants’ data information through the smart contract function readInformation(), which can be used as sample data in the recommendation system. All sample data are obtained with the user’s consent, and the user’s information is in the blockchain. Only the contract initiator and the user can query the data to avoid using information leakage.
As shown in Figure 15, after the meal delivery is completed, the order contract status changes to Completed Order, and the payment contract is triggered to pay the order fee to the restaurant and Deliveryman according to the contract. The function withdraw() in the payment contract automatically performs the withdrawal operation and withdraws the money (Token) temporarily saved by the smart contract into the account. The completed smart contract record provides a basic blockchain data query. The data query is different from the query by the blockchain browser. This query is used for user privacy queries within the scope of the user’s authority, such as purchase records, wallet balances, and favorites. Additionally, in other information inquiries, the blockchain take-out platform Token is used to reward users who participate in smart contracts, and the token is used as the payment currency of the take-out platform to support functions such as legal currency manifestation. In the client (user, restaurant, Deliveryman), the income will be stored in the electronic wallet, and the user can withdraw the amount at any time when the business conditions are met.
This section describes the interface layer’s blockchain data storage and smart contract implementation. The interface layer provides an API interface for the application layer to implement function calls. In the blockchain, the client’s mainstream is DAPP [34]. It runs directly on the blockchain and communicates directly with the blockchain RPC [35] interface as a decentralized client. By introducing web3.js [36] plugins to operate smart contracts on blocks. web3.js is a Javascript library provided by Ethereum. It encapsulates the JSON RPC API of Ethereum. It provides a series of Javascript objects and functions for interacting with the blockchain, including viewing network status, viewing local accounts, viewing transactions and districts blocks, sending transactions, compiling/deploying smart contracts, and calling smart contracts, the most important of which is the API for interacting with smart contracts. The web3.js integrated application interface is provided to the application layer to call and implement functions.

3.3.2. Application Layer Design

The application layer integrates the business function requirements through the interface layer to integrate the API to realize the operation of the blockchain. In the previous section, the takeaway blockchain function was integrated into the smart contract in the form of a smart contract, and the smart contract was operated through the blockchain interface. This section describes in detail the distribution of client functions of the food delivery platform. In the traditional sense, the takeaway blockchain has occupied the vast majority of the market, and the industrialization link has been basically perfected. The traditional market divides food delivery into three client-side clients, providing customers with take-out ordering services; merchant-side applications for restaurants; customers and restaurants are connected through DeliveryPartner to form a complete industrial chain. This paper designs the industrial chain without changing the existing market environment, replaces the traditional centralized food delivery platform with the blockchain application platform, and redefines the food delivery platform through functional integration. This article does not change the layout of the traditional food delivery platform in the application layer. There are also Clients, Merchant clients, and DeliveryPartner clients to achieve rapid deblocking and neutralization deployment.
As shown in Figure 16, this article designs the architecture based on the business functions of the takeaway blockchain, showing the interaction between business requirements and the blockchain. A decentralized application (DAPP) runs on the blockchain and interacts through an interface. In the blockchain, DAPP communicates directly with the network without the need to communicate through the central server, achieving the characteristics of decentralization. This article divides the DAPP into the following four terminals: the user terminal, the merchant terminal, the DeliveryPartner terminal, and the management terminal. The user terminal provides reservation, evaluation, and recommendation functions. The merchant client confirms the order function. Delivery Partner client delivery order function. The management terminal manages and queries order information and deals with order-related issues. The three terminals interact with the smart contract in the blockchain through the interface. The platform releases the smart contract, and the user, restaurant, and DeliveryPartner participate in the smart contract as participants.
Blockchain delivery system framework deployed in the application layer, the underlying blockchain provides trading contracts and intelligence services, business functions in the application layer classification according to the business model. The client is used to manage delivery platform management system, and management systems to provide the order management, delivery management, appraisal management, payment management, business management, member management, Smart contract management, and other functions. The whole process tracking the function of the order is provided between the three clients, and the order status is saved in the blockchain. The client’s wallet function (Token) provides exchange with fiat currency. At the same time, customers’ evaluation scores of merchants and deliverymen will also provide data sets for the recommendation system below. The evaluation and scoring function of the deliveryman is used as the evaluation standard of reward and punishment. In this paper, the application layer design adopts the traditional delivery platform model to provide better business docking for implementation; the existing market business can be directly transplanted to the block-based delivery platform.
As shown in Figure 17, when the user in the blockchain network sends the request transaction from the client to the blockchain interface, the client will construct a valid transaction through the API and SDK, and the transaction includes the following key information:
  • Send transaction: Send an order request, including the account address. The request also includes product information, delivery address, etc., and sends the transaction to the node after signing;
  • Receiving address: The receiving address in this article is a smart contract. First, the transaction signature is verified, and then the smart contract is called to execute the contracted event. The contract transmits the order information to the merchant and broadcasts it to the entire network;
  • Consensus node: The broadcasted transaction information enters the consensus node for transaction sorting and packaging. The transaction is executed, the consensus is carried out among multiple nodes, and then the consensus block is broadcast;
  • Store transaction: Each node verifies the transaction through the consensus node and stores the transaction information;
  • In addition to the active triggering of the transaction in the takeaway platform by the client, the smart contract will also trigger the smart contract event transaction after the end of its life cycle.

3.4. Platform Architecture Function Sequence Diagram

The functional functions of the blockchain food delivery platform execute events and operate the blockchain network, and the data is transmitted in the data layer architecture. Formatted data classes are passed between functions, and data classes are passed according to business processes. This section describes the sequence diagram and data class transfer for the registration and login process. At the same time, it describes the transfer relationship of data classes from order generation to the delivery process.
The authenticity of the user needs to be verified when logging in to the blockchain food delivery platform, as shown in Figure 18.
  • After the login verifies the verification, the user logs in with the account and password and authenticates with the database. If the authentication succeeds, the verification result is returned, and the login is successful;
  • When the authentication fails during login, obtain the mobile phone verification code, and send it to the user to verify the account’s security. When verifying the mobile phone number, call a third-party authentication system to verify the authenticity of the identity information;
  • When the identity is real and valid, enter the received mobile phone verification code into the verification interface, compare and verify the verification code with the data of the third-party system, write the verification successfully into the session, and return the verification success and other information.
Users need to go through two verifications during the initial registration process. When registering an account for the first time, they need to associate the user wallet with authorizing the wallet to the blockchain takeaway platform, which is the user account. Verify the relationship between the wallet and the account and bind the wallet to the blockchain through an encryption algorithm. Real-name authentication of the user account is performed again, and user authentication can be realized by calling a third-party interface. From this, the user account, identity information, and wallet information are associated with the blockchain’s smart contract (this step is used to implement national regulatory requirements).
It can be seen from Figure 19 that the user needs to perform identity information verification when logging in. The process in the model class is shown in Figure 16. When the user logs in, the LoginActivity Class is called to generate the login structure (page) LoginFragment and start indexing related information. The LoginFragment Class calls LoginViewModel to obtain the login component structure. LoginViewModel Class aggregates a variety of verification interfaces based on third-party verification interfaces, application interfaces based on blockchain wallets, and account password generation interfaces based on blockchain platform systems. It can be seen that the information of the LoginFragment Class structure is obtained by calling other classes and forming its structure information. Finally, the LoginFragment Class information body is sent to PHPAsyncTask Class for system account password verification, and the verification result is returned to the front-end verification page.
The restaurant’s menu information is presented to the user in the blockchain take-out platform; the user selects the dish to join the shopping mall process using the model class to demonstrate the process. When the user generates an order, first obtain the merchant category information; as shown in Figure 20, the merchant category is classified according to the attributes of the dishes, which is represented by the ItemCategories Class, which includes the category name, merchant name, ID, and category list of dishes. The model class contains the function getItemCounts():int for operating the merchant account; the function getSectionForPosition(int):int for obtaining the restaurant location; the function getSectionInCategoryList(int): ItemCategory for obtaining the menu category. The ItemCategory class operates the merchant menu category and displays it on the client page. The Item class contains the ID of the dish, the name of the dish, the price, the quantity in stock, and the description of the dish. Find dishes through the Get method (in this article, the dish information data is stored under the chain), and repeatedly add (read) dishes to the shopping cart to generate the ShoppingFragment Class.
As shown in Figure 21, the Itemcategories Class obtains data from the ShoppingViewmodel. First, the ShoppingModelInterface Class is loaded to load the data information through the interface data template. The ShoppingViewmodel Class controls the ShoppingFragment Class to obtain and create data classes and page information. Itemcategories Class obtains data details and loads the detailed shopping cart item information list from the meta side through the DBCHelper Class. Itemcategories Class generates Itemcategories order classes through the control and acquisition process of data classes.
As shown in Figure 22, The dishes are added to the shopping cart one by one, and the dishes are added to generate an ItemInOrderList Class. The ItemInOrderList Class contains the names, quantities, and index values of all the user dishes. The getTotalPrice() function is used to package the prices of all the dishes to generate an order. It can be seen from this that the ItemInOrderList Class is integrated through the user’s active operation to obtain the information of the related model classes. ShoppingFragment Class interacts with smart contracts through the interface layer and generates smart contracts to create takeaway orders.
As shown in Figure 23, after the takeaway order is created, the smart contract will request the order information. The order class performs a series of activities based on the rules. First, create CreateFragment, then generate the OrderFragment class structure. OrderFragment is used to create order information, view information, and generate a data template class. The OrderFragment obtains the JsonOrder class of data information by obtaining data (packaging the order into JSON format).
As shown in Figure 24, OrderFagment obtains the AddAddressActivity class and generates an AddressList containing order address information. At the same time, the time status of the order is obtained through the Deliver-TimePickerActivity class, and the TimeList class is generated. Dependent data model classes are added to OrderFragment. The ItemList<T> is finally generated after the status of the order changes, and it contains all the information from generation to delivery. Data information After the smart contract is verified through the interface, the payment function in the contract is executed. Key data information is stored in the blockchain, and general information is stored in the off-chain IPFS. Use URLs to link general information to important information. When performing a read operation, the order information is displayed in its entirety.

4. Design of Deep Learning Recommendation System Based on Smart Contract

Recently, recommender systems have been classified as a subfield of machine learning, and it is a direction that is partial to engineering and has great commercial value in the industry. It is widely used in Internet enterprise services that provide toC products and provide users with accurate, personalized services through recommendation systems. Recommendation systems generate personalized recommendation results for users through recommendation algorithms, and recommendation algorithms rely on data input to build algorithm models. The first half of this article explains the blockchain-based architecture and operating principles and processes of the food delivery platform. In this chapter, a recommendation system based on user content is designed for the blockchain food delivery platform so that the blockchain food delivery platform recommends to customers more in line with their own satisfaction. Based on the restaurant rating and meal rating recommendation content, the restaurant and user rating information are collected through the smart contracts in the previous chapters, and a sample data set is created using Matrix Factorization in the collaborative filtering model to perform dimensionality reduction matrix decomposition of the data. Design and build neural network models and train and evaluate neural network models to obtain high-precision models for deployment. The overall architecture of the deep learning recommendation system is shown in Figure 25. Based on the model framework, after deep learning training and evaluation, participants (users) vote to obtain the recommended model. This process is verified by smart contracts to obtain the model with the highest number of votes. In this paper, the recommender system is deployed off-chain, and the trained and evaluated models are also stored off-chain. The recommendation system collects user feature information under an open and transparent smart contract and periodically updates the recommendation model algorithm.

4.1. Sample Data Collection and Algorithm Preprocessing

The premise of the deep learning recommendation system is to realize that the recommendation function needs a sample data set. The user characteristics are analyzed and proposed according to the sample data information. Through neural network training, a recommendation model is generated. Then, according to the user’s operation behavior on the product (DAPP), the user’s interest preference is guessed, and finally, a personalized recommendation is made to the user. In the recommendation process, four parts may generate data, including the user itself, the restaurant menu, the user’s operation behavior, and the scene (context) where the user is located, as shown in Figure 26.
(1)
User behavior data
This article uses DAPP to initiate a series of smart contract activities on the user interface. The content of smart contract activities is to record such as browsing, clicking, playing, purchasing, searching, favorites, forwarding, adding to shopping carts, and even sliding and staying at a certain location all operations. Users can participate in smart contracts and receive smart contract rewards (coupons, points). On the one hand, collect user information legally to provide users with better content recommendations. On the other hand, providing smart contract participation rewards makes it a virtuous circle.
(2)
User attribute data
Users initially register using the blockchain takeout platform and fill in relevant user attribute data such as age, gender, region, education, family composition, and occupation. These data are generally stable (such as gender) or slowly changing (such as age), and regional information can be personalized to recommend content that conforms to the user’s regional characteristics.
(3)
Marked physical property data
The most important thing in the recommendation system is the items to be recommended. In this article, the recommended items are restaurants and dishes. The restaurant itself contains many features and attributes, such as a Chinese restaurant, a Korean restaurant, an Indian restaurant, and a Western restaurant. Through the user’s operation behavior on the restaurant and dishes, we can assign the features of the restaurant dishes to the user according to a certain weight, and these features construct the user’s interest preference.
(4)
Context data
Contextual data is a general term for the environmental characteristics and status of the user when operating the restaurant and dishes, such as the user’s geographic location, the current time, the current weather, the user’s mood at the time, the location of the restaurant where the user is located, and so on. This contextual data is very important to the user’s decision-making. For example, for products based on geographic location services, recommendations for restaurants to users must be near the user’s location or the location specified by the user.
According to the above-mentioned collection of user feature information, a user feature information class is generated, such as in Table 3.
As shown in Figure 27 and Figure 28, after obtaining the data set through the smart contract, the data set is indexed and preprocessed through the code, mapping akeed_order_id and customer_id to make the training data set and test training set by marking and filtering the required data labels.
Briefly explaining some columns as follows:
  • akeed_order_id: Unique customer ID, used in train_locations and train_orders;
  • vendor_rating: The ratings are rated by customers who use the vendor (restaurant);
  • vendor_id: vendor’s (restaurant) unique id;
  • customer_id: customer’s unique id.
The intelligence is suitable for collecting user feature information and cleaning and filtering the feature information data. This paper uses the matrix decomposition algorithm based on collaborative filtering to reduce the data dimension. As shown in Figure 29, the restaurant ratings are divided into evaluation grades in the restaurant rating data set. It can be seen from the figure that the restaurant ratings are distributed between 4.2 and 4.5.
The order sample training data set is preprocessed by code, and the sample data set in Figure 30 is obtained after selecting the required sample labels and filtering. Then, through the matrix decomposition of the collaborative filtering algorithm, the training data set is decomposed to reduce the dimension to generate the product of the two matrices. So far, the processing of the training sample data set is completed, the data set is used as input data to enter the deep learning model, and the optimal model is obtained by repeated training.

4.2. Implementation of Neural Network Model

Most of the mainstream recommendation algorithms in the recommender system are matrix factorization algorithms based on collaborative filtering. The matrix factorization algorithm is also used in this paper, which is widely used because of its outstanding results in the Netflix Prize [37] recommendation system competition. Taking the user-item rating matrix as an example, matrix decomposition predicts the missing values in the rating matrix and then recommends it to the user in a certain way based on the predicted value. Common matrix factorization methods include basic matrix factorization (basic MF), regularized matrix factorization (Regularized MF), and probability-based matrix factorization (PMF). Specifically, the model decomposes a user-item interaction matrix (e.g., a rating matrix) into a product of two low-rank matrices, thereby capturing the low-rank structure of user-item interactions. To transform user data into data features for input to neural network processing, so let R R m * n Denote interaction matrix musers, and n items and value R denote explicit ratings. The user-item interaction will be decomposed into a user latent matrix P R m * k and an item latent matrix Q R n * k Where k m , n , is the latent factor size. Let P u denote u th row P and q i denote i th row Q. Forgiven item i, the element of q i measures the extent to which the item possesses restaurant type and attribute characteristics. For a given user u, the element of P u measures the user’s interest in the corresponding feature of the restaurant. These latent factors may either measure the apparent dimensions mentioned in these examples or be completely unexplainable. The predicted viewership can be estimated as follows:
R ^ = P Q T
R ^ R m * n is the predicted rating matrix with the same shape as R. A major problem with this prediction rule is the inability to model user-item bias. For example, some users give higher ratings, or certain items always obtain lower ratings due to poor quality. These deviations are common in practical applications. To capture these biases, user-specific and project-specific bias terms are introduced. Specifically, the predicted rating for the item i given by user u is calculated by the following:
R ^ u i = p u q i T + b u + b i
Then, we train the matrix factorization model by minimizing the mean squared error between predicted rating scores and real rating scores. The objective function is defined as follows:
argmin ( P , Q , b ) ( u , i ) k R u i R ^ u i 2 + λ ( P F 2 + Q F 2 + b u 2 + b i 2 )
where λ represents the regularization rate. The regularization term λ ( P F 2 + Q F 2 + b u 2 + b i 2 ) is used to avoid overfitting by penalizing the magnitude of the parameters. This (u, i) pair of R u i is known to be stored in the set K = { ( u , i ) R u i   is   known } . The model parameters can be learned by optimization algorithms such as stochastic gradient descent and Adam.
A visual illustration of the matrix factorization model is as follows:
As shown in Figure 31, the data set is decomposed into a product of two sub-matrices, and the high-dimensional user-item rating matrix is decomposed into two low-dimensional user factor matrices and an evaluation score factor matrices. Usually, the number of hidden factors in the selection of k is much lower than the number of user and restaurant ratings. The decomposition of the large matrix into two small matrices is the mapping of users and ratings on the k-dimensional latent factor space. This method is a kind of “Dimension Reduction”. At the same time, the representation of users and ratings is transformed into the distribution position in this k-dimensional space. The closer the distance between the restaurant’s rating and the user, the more likely the user likes the restaurant. The degree of positive and negative is more consistent.
The matrix factorization method maps the high-dimensional user-item rating matrix into two low-dimensional user and item matrices, which solves the problem of data sparsity. Using matrix factorization has the following advantages:
  • It is relatively easy to program and implement, and the stochastic gradient descent method can train the model in sequence. Relatively low time and space complexity, high-dimensional matrix mapping saves storage space for two low-dimensional matrices, and the training process is time-consuming, but it can be performed offline; scoring prediction is generally calculated online, directly using the parameters obtained from offline training, which can be performed in real-time recommended;
  • The prediction accuracy is relatively high, and the accuracy rate is higher than that of domain-based collaborative filtering and content filtering;
  • Excellent scalability; it is easy to add other factors to the user feature vector and item feature vector, such as adding SVD++ with implicit feedback factors. The detailed implementation of this method can be found in the literature [38]. By adding time-dynamic time SVD++, this method will bias Both the part and the user’s interest are expressed as a function of time, which can well capture the user’s interest drift. For detailed implementation, please read the literature [39].
The deep learning recommendation system inputs the processed data set into the neural network, and the neural network finds the optimal solution function model according to the data set. As shown in Figure 32, the neural network consists of an input layer, a hidden layer, and an output layer. The hidden layer is also called the middle layer, and there are multiple layers inside the hidden layer for repeated backpropagation to find the optimal weight. Neural networks introduce the following two concepts of weights and neurons:
  • Neuron: Points representing input, intermediate values, and output values. For example, the small circles in the above figure represent different neurons;
  • Weight: When the neuron conducts, it is multiplied by a coefficient called the weight value. For example, the neurons in the input layer in the above figure are transmitted to the neurons in the middle layer. The neurons in the input layer need to be multiplied by a coefficient to reach the middle layer, namely, the following: middle layer = input layer × weight.
The matrix factorization algorithm in this paper is to predict restaurant ratings, and based on the size of the ratings, it indicates the degree of preference for restaurants. As shown in Figure 33, the training data has been processed by feature extraction. In this paper, the rating of a class of customers for the restaurant is extracted by feature extraction. The degree of liking the feature is used to push the restaurant that meets the feature to the customer through the recommendation system. The recommendation accuracy is continuously optimized through the loss function to generate the push model. Use the test data to verify the model’s accuracy to obtain the recommended results. Compare the results with the validation data to judge the model’s accuracy. This completes the entire stage from feature extraction to model output.
The characteristic of the neural network is the process of automatic learning by giving it input information and expected output information. In the process of model adjustment, the loss function continuously minimizes the loss function to reduce the output error. As shown in Figure 34, in designing a neural network, the hidden layer will perform mathematical operations on the processed data. The concepts of neurons and weights are mentioned above. Each connection between neurons is closely related to the weight (weight), which determines the importance of the input value, and the initial weights are randomly set. At the same time, each neuron has an activation function; the purpose is to “normalize” the output value of the neuron. The layers embedding, flattening, and dense are introduced in Figure 34. Embedding is a way to convert discrete variables into continuous vector representations. There are the following three main functions:
  • Find nearest neighbors in the embedding space, which is good for making recommendations based on user interests;
  • As input to supervised learning tasks;
  • Used to visualize the relationship between different discrete variables.

4.3. Model Training and Evaluation

In Section 4.1, the sample data set is divided into training and test sets and filtered and “cleaned” to generate the input data set. Section 4.2 uses matrix decomposition to classify the sample data and extract features by analyzing the recommendation algorithm and reducing the features’ dimensions. Processing, this section uses the Keras neural network in TensorFlow to generate a recommendation model to perform deep learning on the recommendation algorithm. The Keras neural network model provides training functions to train and process sample data. At the same time, the model is verified by RMSE (Root Mean Square Error) [40] to evaluate the model error. We implemented the RMSE (Root Mean Squared Error) metric, which is typically used to measure the difference between the ratings predicted by the model and the ratings observed (ground truth). RMSE is defined as follows:
R M S E = 1 | Τ | ( u , i ) T   ( R u i R ^ u i ) 2  
where T is the set of user and item (rating) pairs, you want to evaluate. |T| is the size of this set. We can use the RMSE function provided by the mx.metric. R u i is the predicted rating and R ^ u i is the true rating. The smaller the RMSE, the smaller the error, and the better the performance of the recommender system. Use the RMSE function as follows:
Electronics 11 01806 i001
Embed the sample dataset into the model using the Keras model as follows:
Electronics 11 01806 i002
Use the tensorflow.keras.layers method to pass the sample data into the hidden layer to set the network convolution layer, pooling layer, and fully connected layer, as follows:
Electronics 11 01806 i003
Next, we use a neural network for deep learning. Dense() represents a fully connected layer. The first parameter represents how many neurons there are, and activation represents the type of activation function. The number of neurons in the last layer must be the number of categories the user wants to classify because several neurons will output several results; here are four categories, and output their respective probabilities, as follows:
Electronics 11 01806 i004
Finally, compile the set model, and output the parameter status of each layer of the model through model.summary(), as follows:
Electronics 11 01806 i005
The compiled model is fitted with the test data set, and the optimal weight is found to obtain the optimal solution, as follows:
Electronics 11 01806 i006
In this paper, the training model sets the learning depth to 10 and adjusts the learning depth according to the downward trend of the loss function. The recommended model is generated from the training and test set data. As shown in Figure 35, the loss function value continues to drop to a minimum value of 0.3407.
The recommendation model after deep learning is used to verify the recommendation performance, and the test data set is used to compare the results of the recommendation model. The evaluation indicator uses RMSE to verify its recommendation performance and uses matplotlib.pyplot to visualize the evaluation and recommendation performance, as shown in Figure 36. The RMSE score drops rapidly; the RMSE The smaller the value, the better the recommendation system’s performance. The loss function also continues to decline, and the learning depth starts from the sixth time. The two lines of RMSE and LOSS gradually become parallel, indicating that the deep learning model is the optimal one.

4.4. Restaurant Recommendation Based on Recommendation Model

The recommendation model based on deep learning is obtained after training and validation. Define the recommendation model function to input the test training set into the recommendation model. In this paper, the input data is customer ID, the output data is the recommended restaurant ID set, restaurant rating, and predicted rating (in line with the customer’s preference), and the number of recommended restaurants is controlled by n_items. The mf_dl_recom_vendor_list() function internally calls the recommendation model and outputs the recommendation result.
Electronics 11 01806 i007
As shown in Figure 37, input different user IDs into the recommendation system to obtain the customer’s preference for five restaurants. The larger the value, the higher the preference, and the maximum value is 5. The output result compares mean_rating and predicted_rating. The restaurant rating mean_rating is quite different from the restaurant rating recommended (predicted) by the recommendation system. This shows that recommending restaurants according to the average scoring mechanism has a large degree of error in user satisfaction. Then recommend restaurants to customers based on the predicted_rating value. As can be seen from the figure, the score of customer_id = ‘Z7RQ368’ is as high as 4.9, and the five restaurants in the example are suitable for recommendation to customers. customer_id = ‘The five restaurants in U2OTA4O’s rating are suitable for recommendation to this customer.

5. Blockchain Platform Implementation Results

In this article, Ubuntu is used to build and test the ganache blockchain network, the wallet uses the MetaMask simulation account, and the off-chain data is stored in IPFS. As shown in Figure 38, start the blockchain system server, start the client, the restaurant, and the delivery, respectively. The client runs based on the blockchain network, and the decentralized application (DAPP) directly interacts and transmits data with the blockchain through web3.js. In this article, the client application is run by building a browser-based DAPP.

5.1. Web Version (For Customers)

As shown in Figure 39, it is a decentralized client. The home page is the restaurant list. The client restaurant list displays the name of the restaurant, the restaurant logo, the basic delivery fee of the restaurant, and the approximate production time of the restaurant dishes. The displayed restaurant list outputs the restaurants to the page in order according to the preference level output by the recommendation system. It mainly provides the following functions for customers:
  • See all restaurants and menu;
  • Make and pay for an order;
  • Monitor the order status (real-time).
As shown in Figure 40, first select a restaurant in the restaurant list to enter the restaurant menu details page. The details page displays the menu information for the restaurant, including the pictures of the dishes, the unit price of the dishes, and the description information for the dishes. Click the dish information to add the dish to the shopping cart for unified payment and settlement.
As shown in Figure 41, use the MetaMask demo account, click Connect to MetaMask to connect the account, display the account address and account balance, and display the details of the payment amount, that is, the details of the meal fee and delivery fee. After clicking Pay, call the MetaMask account for authorization and verification, and pay TOKEN to create an order. At this time, the order status is the restaurant’s pending order.

5.2. Web Version (For Restaurants)

Figure 42, restaurant-oriented client. After the customer generates an order, the order information is sent to the restaurant. The restaurant first connects and verifies the account, the latest order information appears under the account, the customer clicks to accept the order, and the order information is pushed to the delivery staff. At this time, the order status is pending pickup. A restaurant order contains information and the price of the item, as well as when the order was created and when the order status was updated. The main functions are as follows:
  • Register user;
  • Register menu items;
  • Accept orders in real-time.

5.3. Web Version (For DeliveryMan)

Provide the following key functions for the Deliveryman:
  • See the available orders for delivery
  • Pick an order (real-time)
In Figure 43, the delivery person needs to verify the account and pay some gas fees when accepting the order. When the delivery person delivers the meal to the customer, the order smart contract is completed, the contract status changes, and the fees temporarily stored in the smart contract are paid to the restaurant and the dispatcher to complete the entire order process.

6. Performance Evaluation

This section evaluates the system performance of our case study. We use Hyperledger Caliper [41], an open-source blockchain benchmark tool designed to measure the performance of different blockchain implementations. To demonstrate the efficiency and importance of the designed solution, we conducted an experiment comparing the performance between the public chain architecture and the proposed takeaway blockchain architecture. We explore the differences between these two architectures by evaluating average network latency and transaction throughput. Network latency represents the time it takes to execute a transaction within the network. More precisely, network latency includes the time from when a transaction is submitted to when it is broadcast and validated after consensus is reached. Transaction throughput represents the number of valid transactions submitted by the blockchain in a given time, measured in transactions per second (tps).
The key metrics to measure blockchain network performance include the following:
  • Blockchain node indicators (number of blocks produced, number of transactions processed, processing time, completion time, etc.);
  • P2P system metrics (number of hit/miss requests, number of active users, data, and structure of P2P traffic, etc.);
  • System node indicators (CPU, memory, network, bandwidth, etc.) Among them, TPS can integrate the above indicators to measure the transaction rate of the blockchain network. It consists of T (the number of things) and S (seconds), called TPS (every transaction in seconds).
The P2P layer, as the middle layer of the peer-to-peer blockchain network, mainly handles block delivery and transactions (consensus) between nodes. When the number of validating nodes is small, they are localized, the user list is hardcoded, and everything is working fine and very fast, but there is a geographical distribution of the nodes’ validation, and there is packet loss in the network transmission. So P2P metrics can be inbound and outbound traffic, the number of successful/failed connections to users, the number of times previously cached chunks of data were returned, and the number of times the required chunk was found by further forwarding requests.
From the above, it can be seen that in the actual situation of the blockchain food delivery platform network, high-standard servers and network deployment networks are selected according to factors such as the number of users. In this paper, two parameters, TPS and transaction delay, are selected to evaluate the performance in the local environment. In this paper, we set different numbers of clients (N) to communicate with the blockchain (transactions M) and measure the communication delay (TH). By adjusting and recording the parameters between the sending amount M and the number of transaction clients N, the transaction rate TPS and network delay are obtained for performance evaluation.
In this lab, we modified the script provided by Hyperledger Caliper to target a feature of our case study application. This function is used to create orders because it is called most frequently by user clients. We conducted twelve rounds of evaluation experiments at different send rates, from 100 tps to 600 tps. In the same test environment, we deployed the Ethereum network and Bitnet to perform the six rounds, the proposed P2P architecture performed the six rounds. To reduce the potential impact of network congestion and overload, multiple rounds of experiments were conducted. Figure 44 and Figure 45 show the average transaction throughput by the network for each block in different rounds of experiments, respectively.
From the performance evaluation results, it is obvious that with the increase in the sending rate, the transaction throughput under the Ethereum and Bitcoin networks shows a linear downward trend. However, for P2P architecture, it increases significantly. The proposed P2P architecture achieves higher throughput than Ethereum and Bitcoin in all rounds. At a sending rate of 100 tps, the maximum throughput of the Ethereum and Bitcoin network architectures is about 38.2 tps and 12.1 tps, respectively. For the P2P architecture, a send rate of about 410.3 tps was observed for 500 tps. For the network latency assessment, it is clear that the average latency in the Ethereum and Bitcoin network architectures increases significantly with the sending rate. In contrast, the increase in average latency in P2P architectures is low.
In Figure 46, network latency performance test results with increased transaction volume. Among the three network delays, the P2P network has a small increase in delay with the increase in transaction volume. There is a linear growth relationship between the Ethereum and Bitcoin networks in the test transaction volume increase delay.

7. Challenges and Difficulties

In the existing living environment, the peer-to-peer blockchain food delivery platform can solve a series of problems such as commission, trust, information transparency, and high efficiency, but there are still the following difficulties and challenges in the production environment:
  • Supervision is difficult: Blockchain technology can optimize the economic structure to a certain extent, but it brings huge challenges to the supervision of the food delivery market. Due to the decentralization and transparency of blockchain technology, some criminals have taken the opportunity to enter the food delivery market. At the same time, due to the application of blockchain technology, it is difficult to effectively supervise the food delivery market, resulting in market chaos;
  • Security issues: When the blockchain food delivery platform transmits data across chains, there is a high risk of data leakage. At the same time, with the rapid development of science and technology, even encrypted information faces cracking;
  • Efficiency and resource cost issues: With the development of society, data is also growing, blockchain technology has gradually been unable to meet the needs of large-scale data transactions, and the efficiency is relatively low. At the same time, with the continuous improvement of blockchain technology requirements, it is urgent to improve blockchain technology, but the cost of optimizing blockchain technology is very high;
  • No unified technical standard has been formed: At this stage, the blockchain is in the development stage, and there is no unified technical standard for blockchain technology in the world, which will easily lead to confusion and incompatibility in the process of applying blockchain technology.
For the challenges faced by the blockchain in the production application environment, there are some solutions to deal with the existing difficulties:
  • Supervision is difficult: When designing a blockchain take-out platform, a public chain + private chain (consortium chain) architecture solution is used to meet existing regulatory issues. In the future, I will use the multi-chain architecture for redeployment;
  • Security issues: When data is transmitted in the blockchain, a series of encryption algorithms are used to encrypt the data blocks and then transmit them across the chain;
  • Efficiency and cost issues: The peak transactions of the food delivery platform reach several million. In the existing blockchain technology, the consensus algorithm is continuously optimized, and the number of blockchain transactions continues to increase. Smart contracts, such as the Lightning Network, achieve millions to billions of transactions per second;
  • The formulation of unified standards hinders the development of blockchain to a large extent in the early stages of blockchain development. When blockchain technology achieves high-speed application, the formulation of unified standards can regulate blockchain application and market supervision.

8. Future Work

There are a lot of problems in the application of blockchain-based applications in the market environment, and some functions will always be given up in the conversion scenario to meet the scenario application in the market environment. In this paper, the application of blockchain in food delivery platforms also needs to enhance the performance of P2P transaction services. In the application of large-scale scenarios, blockchain needs to solve the problem of a high concurrency environment. In the future, I will use the form of multi-chain [30] architecture to improve the performance of blockchain transactions. At the same time, it improves the autonomy of the blockchain network and introduces the concept of a decentralized autonomous organization (DAO). Realize the complete autonomy of the blockchain food delivery platform and adapt to market demands.
The future plan of multi-chain architecture as follows:
  • Based on the idea of multi-chain collaboration, a new architecture model of “main chain + sub-chain” is proposed in the peer-to-peer food delivery platform. It is used to improve the processing ability and function expansion ability of large-scale takeout orders;
  • In the new architecture, the main chain is only used for order transaction processing, and the sub-chain handles payment transfer, evaluation, data collection, rewards, and other functions. Fraud proofs are then performed for these transactions in the sidechain using indexed Merkle trees and distributed auditing. Its advantages include high bandwidth for transactions, protection of transaction privacy, and integration with existing centralized business scenarios;
  • The model introduces cross-chain hash time lock technology, smart contract technology, and deep learning recommendation technology. The model aims to promote the point-to-point takeout blockchain without commissions, improve the degree of automation, open transaction information and smart contract based recommendation system to serve consumers and service providers with high precision, and realize the security and facilitation of the blockchain takeout platform from the information level;
  • Based on the autonomous smart contract automatic reward mechanism, a deep learning recommendation model is introduced to realize a high-precision and automatic recommendation system.
The blockchain is currently in the development stage, and there are various problems when it is applied to business scenarios based on public and private chains and alliance chains, which are determined by their characteristics. More research is needed in the future to improve blockchain transaction performance, blockchain scaling, and blockchain governance. Among them, the research on the blockchain consensus algorithm belongs to the core research direction of the core development of the blockchain. The existing Pow, Pos, Dpos, and PBFT algorithms have their own advantages but also have their own problems. At present, the blockchain system can only optimize two of the three goals of decentralization, high performance, and security at the same time. Finding the optimal solution for the three goals is the main research direction and technical challenge in the future.

9. Conclusions

With the continuous innovation and development of blockchain technology, the application of blockchain in the food delivery industry can trigger a revolution in the entire food delivery platform industry, but it is still in its early stages. In this paper, we propose a peer-to-peer blockchain food delivery intelligent platform to eliminate middlemen, enable peer-to-peer sales between restaurants and customers, and improve industry efficiency and trust. The introduction of recommendation systems into the intelligent platform recommends restaurants and menus to customers, increasing customer satisfaction and reducing consumer spending. The previous part of this paper describes the privacy and security challenges, features, and working philosophies of existing blockchain food delivery platforms and smart contract recommender systems and analyzes the limitations and open issues of existing applications. In the second half, a case study of the food delivery platform is implemented, and the application of the proposed smart contract-based recommendation system on the blockchain food delivery platform is realized, which realizes point-to-point food delivery service and eliminates middlemen. In the recommender system, we focus on how to handle user information and privacy and use smart contracts to improve user security and trust and collect user information in the form of participating smart contracts. Therefore, blockchain can significantly improve the efficiency of recommendation systems by ensuring the security, integrity, privacy, and accessibility of data, while peer-to-peer food delivery platform services can greatly reduce users’ consumption costs. Through comprehensive evaluation experiments and benchmark analysis, it is expounded that the designed takeaway platform architecture has the significance of improving the drawbacks of the existing takeaway platforms.

Author Contributions

L.Z.: literature search, figures, study design, data collection, data analysis, data interpretation, writing. D.K.: Monitor and provide methodological advice. All authors have read and agreed to the published version of the manuscript.

Funding

This research was supported by Energy Cloud R&D Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Science, ICT (2019M3F2A1073387), and this work was supported by Institute of Information and Communications Technology Planning and Evaluation (IITP) grant funded by the Korea government (MSIT) (2021-0-00188, Open source development and standardization for AI-enabled IoT platforms and interworking).

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. Hirschberg, C.; Rajko, A.; Schumacher, T.; Wrulich, M. The Changing Market for Food Delivery; McKinsey&Comapany: New York, NY, USA, 2016. [Google Scholar]
  2. Nofer, M.; Gomber, P.; Hinz, O.; Schiereck, D. Blockchain. Bus. Inf. Syst. Eng. 2017, 59, 183–187. [Google Scholar] [CrossRef]
  3. Zhang, H.; Sun, Y.; Zhao, M.; Chow, T.W.; Wu, Q.J. Bridging user interest to item content for recommender systems: An optimization model. IEEE Trans. Cybern. 2019, 50, 4268–4280. [Google Scholar] [CrossRef] [PubMed]
  4. Katarya, R. Reliable recommender system using improved collaborative filtering technique. Syst. Reliab. Manag. Solut. Technol. 2018, 113, 1556–6013. [Google Scholar]
  5. Gupta, G.; Katarya, R. Recommendation analysis on item-based and user-based collaborative filtering. In Proceedings of the 2019 International Conference on Smart Systems and Inventive Technology (ICSSIT), Tirunelveli, India, 27–29 November 2019. [Google Scholar]
  6. Kwilinski, A.; Volynets, R.; Berdnik, I.; Holovko, M.; Berzin, P. E-Commerce: Concept and Legal Regulation in Modern Economic Conditions. J. Leg. Ethical Regul. Issues 2019, 22, 1–6. [Google Scholar]
  7. Anandhan, A.; Shuib, L.; Ismail, M.A.; Mujtaba, G. Social media recommender systems: Review and open research issues. IEEE Access 2018, 6, 15608–15628. [Google Scholar] [CrossRef]
  8. Eirinaki, M.; Gao, J.; Varlamis, I.; Tserpes, K. Recommender systems for large-scale social networks: A review of challenges and solutions. Future Gener. Comput. Syst. 2018, 78, 413–418. [Google Scholar] [CrossRef]
  9. Wu, D.; Lu, J.; Zhang, G. A fuzzy tree matching-based personalized e-learning recommender system. IEEE Trans. Fuzzy Syst. 2015, 23, 2412–2426. [Google Scholar] [CrossRef]
  10. Chen, Y.; Zhou, M.; Zheng, Z.; Chen, D. Time-aware smart object recommendation in social internet of things. IEEE Internet Things J. 2019, 7, 2014–2027. [Google Scholar] [CrossRef]
  11. Himeur, Y.; Alsalemi, A.; Al-Kababji, A.; Bensaali, F.; Amira, A.; Sardianos, C. A survey of recommender systems for energy efficiency in buildings: Principles, challenges and prospects. Inf. Fusion 2021, 72, 1–21. [Google Scholar] [CrossRef]
  12. Deng, X.; Huangfu, F. Collaborative variational deep learning for healthcare recommendation. IEEE Access 2019, 7, 55679–55688. [Google Scholar] [CrossRef]
  13. Wei, P.; Xia, S.; Chen, R.; Qian, J.; Li, C.; Jiang, X. A deep-reinforcement-learning-Based recommender system for occupant-driven energy optimization in commercial buildings. IEEE Internet Things J. 2020, 7, 6402–6413. [Google Scholar] [CrossRef]
  14. Borràs, J.; Moreno, A.; Valls, A. Intelligent tourism recommender systems: A survey. Expert Syst. Appl. 2014, 41, 7370–7389. [Google Scholar] [CrossRef]
  15. Nguyen, H.T.; Almenningen, T.; Havig, M.; Schistad, H.; Kofod-Petersen, A.; Langseth, H.; Ramampiaro, H. Learning to rank for personalised fashion recommender systems via implicit feedback. In Mining Intelligence and Knowledge Exploration; Springer: Cham, Switzerland, 2014; pp. 51–61. [Google Scholar]
  16. Toledo, R.Y.; Ahmad, A.A.; Martinez, L. A food recommender system considering nutritional information and user preferences. IEEE Access 2019, 7, 96695–96711. [Google Scholar] [CrossRef]
  17. Nakamoto, S. Bitcoin: A peer-to-peer electronic cash system. Bitcoin. 2008. Available online: https://bitcoin.org/bitcoin.pdf4 (accessed on 2 April 2022).
  18. Al-Jaroodi, J.; Mohamed, N. Blockchain in industries: A. survey. IEEE Access 2019, 7, 36500–36515. [Google Scholar] [CrossRef]
  19. Monrat, A.A.; Schelén, O.; Andersson, K. A survey of blockchain from the perspectives of applications, challenges, and opportunities. IEEE Access 2019, 7, 117134–117151. [Google Scholar] [CrossRef]
  20. Available online: http://itrustdata.com/ (accessed on 2 April 2022).
  21. Available online: https://bistroo.io/ (accessed on 2 April 2022).
  22. Available online: https://eatzilla.info/ (accessed on 2 April 2022).
  23. Khan, A.A.; Shaikh, Z.A.; Belinskaja, L.; Baitenova, L.; Vlasova, Y.; Gerzelieva, Z.; Laghari, A.A.; Abro, A.A.; Barykin, S. A Blockchain and Metaheuristic-Enabled Distributed Architecture for Smart Agricultural Analysis and Ledger Preservation Solution: A Collaborative Approach. Appl. Sci. 2022, 12, 1487. [Google Scholar] [CrossRef]
  24. Khan, A.A.; Shaikh, Z.A.; Baitenova, L.; Mutaliyeva, L.; Moiseev, N.; Mikhaylov, A.; Laghari, A.A.; Idris, S.A.; Alshazly, H. QoS-Ledger: Smart Contracts and Metaheuristic for Secure Quality-of-Service and Cost-Efficient Scheduling of Medical-Data Processing. Electronics 2021, 10, 3083. [Google Scholar] [CrossRef]
  25. Khan, A.A.; Laghari, A.A.; Liu, D.S.; Shaikh, A.A.; Ma, D.A.; Wang, C.Y.; Wagan, A.A. EPS-Ledger: Blockchain Hyperledger Sawtooth-Enabled Distributed Power Systems Chain of Operation and Control Node Privacy and Security. Electronics 2021, 10, 2395. [Google Scholar] [CrossRef]
  26. Peng, X.; Zhang, X.; Wang, X.; Li, H.; Xu, J.; Zhao, Z. Multi-Chain Collaboration-Based Information Management and Control for the Rice Supply Chain. Agriculture 2022, 12, 689. [Google Scholar] [CrossRef]
  27. Jung, H. A Conceptual Model of a B2B Food Distribution Platform Based on Blockchain Consensus Mechanism. Int. J. Contents 2021, 17, 48–66. [Google Scholar]
  28. Baralla, G.; Ibba, S.; Marchesi, M.; Tonelli, R.; Missineo, S. A blockchain based system to ensure transparency and reliability in food supply chain. In Proceedings of the European Conference on Parallel Processing, Turin, Italy, 27–31 August 2018; pp. 379–391. [Google Scholar]
  29. Wang, S.; Huang, C.; Li, J.; Yuan, Y.; Wang, F.Y. Decentralized construction of knowledge graphs for deep recommender systems based on blockchain-powered smart contracts. IEEE Access 2019, 7, 136951–136961. [Google Scholar] [CrossRef]
  30. Zhang, L.; Hang, L.; Jin, W.; Kim, D. Interoperable Multi-Blockchain Platform Based on Integrated REST APIs for Reliable Tourism Management. Electronics 2021, 10, 2990. [Google Scholar] [CrossRef]
  31. Rahman, M.U. Scalable role-based access control using the eos blockchain. arXiv 2020, arXiv:2007.02163. [Google Scholar]
  32. Wessling, F.; Ehmke, C.; Hesenius, M.; Gruhn, V. How Much Blockchain Do You Need? Towards a Concept for Building Hybrid DApp Architectures. In Proceedings of the 2018 IEEE/ACM 1st International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB), Gothenburg, Sweden, 27 May–3 June 2018; pp. 44–47. [Google Scholar]
  33. Ko, K.; Lee, C.; Jeong, T.; Hong, J.W.-K. Design of RPC-based Blockchain Monitoring Agent. In Proceedings of the 2018 International Conference on Information and Communication Technology Convergence (ICTC), Jeju Island, Korea, 17–19 October 2018; pp. 1090–1095. [Google Scholar]
  34. Lee, W.-M. Using the Web3. js APIs. Beginning Ethereum Smart Contracts Programming; Apress: Berkeley, CA, USA, 2019; pp. 169–198. [Google Scholar]
  35. Koren, Y.; Bell, R.; Volinsky, C. Matrix factorization techniques for recommender systems. Computer 2009, 42, 30–37. [Google Scholar] [CrossRef]
  36. Koren, Y. Factorization meets the neighborhood: A multifaceted collaborative filtering model. In Proceedings of the 14th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, Las Vegas, NV, USA, 24–27 August 2008; pp. 426–434. [Google Scholar]
  37. Koren, Y. Collaborative filtering with temporal dynamics. In Proceedings of the 15th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, Paris, France, 28 June–1 July 2009; pp. 447–456. [Google Scholar]
  38. Gunawardana, A.; Shani, G. Evaluating recommender systems. In Recommender Systems Handbook; Springer: Boston, MA, USA, 2015; pp. 265–308. [Google Scholar]
  39. Choi, W.; Hong, J.W.-K. Performance Evaluation of Ethereum Private and Testnet Networks Using Hyperledger Caliper. In Proceedings of the 22nd Asia-Pacific Network Operations and Management Symposium (APNOMS), Daegu, Korea, 22–25 September 2020. [Google Scholar]
  40. Willmott, C.J.; Matsuura, K. Advantages of the mean absolute error (MAE) over the root mean square error (RMSE) in assessing average model performance. Clim. Res. 2005, 30, 79–82. [Google Scholar] [CrossRef]
  41. Ampel, B.; Patton, M.; Chen, H. Performance modeling of hyperledger sawtooth blockchain. In Proceedings of the 2019 IEEE International Conference on Intelligence and Security Informatics (ISI), Shenzhen, China, 1–3 July 2019. [Google Scholar]
Figure 1. The composition of the blockchain.
Figure 1. The composition of the blockchain.
Electronics 11 01806 g001
Figure 2. Changes in the scale of China’s food delivery industry from 2015 to 2019 (100 million Yuan).
Figure 2. Changes in the scale of China’s food delivery industry from 2015 to 2019 (100 million Yuan).
Electronics 11 01806 g002
Figure 3. Scale and utilization rate of online takeout users from 2016 to 2019.
Figure 3. Scale and utilization rate of online takeout users from 2016 to 2019.
Electronics 11 01806 g003
Figure 4. Bistroo Blockchain Operation Process.
Figure 4. Bistroo Blockchain Operation Process.
Electronics 11 01806 g004
Figure 5. Blockchain takeaway platform architecture plan.
Figure 5. Blockchain takeaway platform architecture plan.
Electronics 11 01806 g005
Figure 6. Data storage of blocks in blockchain and index connection between blocks.
Figure 6. Data storage of blocks in blockchain and index connection between blocks.
Electronics 11 01806 g006
Figure 7. The order data class generation process.
Figure 7. The order data class generation process.
Electronics 11 01806 g007
Figure 8. The principle of the central network structure to the P2P network structure.
Figure 8. The principle of the central network structure to the P2P network structure.
Electronics 11 01806 g008
Figure 9. Smart contracts in the blockchain network rely on each other to form a complete business process.
Figure 9. Smart contracts in the blockchain network rely on each other to form a complete business process.
Electronics 11 01806 g009
Figure 10. Smart contract participation model in food delivery platform.
Figure 10. Smart contract participation model in food delivery platform.
Electronics 11 01806 g010
Figure 11. Schematic diagram of smart contract operation.
Figure 11. Schematic diagram of smart contract operation.
Electronics 11 01806 g011
Figure 12. The picture shows the control process of user control permissions in smart contracts.
Figure 12. The picture shows the control process of user control permissions in smart contracts.
Electronics 11 01806 g012
Figure 13. Order contract function implementation.
Figure 13. Order contract function implementation.
Electronics 11 01806 g013
Figure 14. Data manipulation control function implementation.
Figure 14. Data manipulation control function implementation.
Electronics 11 01806 g014
Figure 15. The payment contract withdraws the Token in the smart contract.
Figure 15. The payment contract withdraws the Token in the smart contract.
Electronics 11 01806 g015
Figure 16. Application layer functional architecture diagram.
Figure 16. Application layer functional architecture diagram.
Electronics 11 01806 g016
Figure 17. Transactions are executed in the blockchain network.
Figure 17. Transactions are executed in the blockchain network.
Electronics 11 01806 g017
Figure 18. System login verification sequence diagram.
Figure 18. System login verification sequence diagram.
Electronics 11 01806 g018
Figure 19. System login verification class diagram.
Figure 19. System login verification class diagram.
Electronics 11 01806 g019
Figure 20. ItemCategories Class represents a list of categories including dishes and merchants.
Figure 20. ItemCategories Class represents a list of categories including dishes and merchants.
Electronics 11 01806 g020
Figure 21. Obtain shopping cart classification information and shopping class formation process.
Figure 21. Obtain shopping cart classification information and shopping class formation process.
Electronics 11 01806 g021
Figure 22. Generate product order information class.
Figure 22. Generate product order information class.
Electronics 11 01806 g022
Figure 23. User order class and delivery class relationship.
Figure 23. User order class and delivery class relationship.
Electronics 11 01806 g023
Figure 24. The interaction process between the order address and the delivery process.
Figure 24. The interaction process between the order address and the delivery process.
Electronics 11 01806 g024
Figure 25. Smart contract-based deep learning recommendation model.
Figure 25. Smart contract-based deep learning recommendation model.
Electronics 11 01806 g025
Figure 26. Recommendation algorithm data source.
Figure 26. Recommendation algorithm data source.
Electronics 11 01806 g026
Figure 27. Order dataset class sample data.
Figure 27. Order dataset class sample data.
Electronics 11 01806 g027
Figure 28. Sample order dataset.
Figure 28. Sample order dataset.
Electronics 11 01806 g028
Figure 29. Distribution map of restaurant rating dataset.
Figure 29. Distribution map of restaurant rating dataset.
Electronics 11 01806 g029
Figure 30. The processed order training dataset.
Figure 30. The processed order training dataset.
Electronics 11 01806 g030
Figure 31. Intuitive representation of the Principle of Matrix Decomposition.
Figure 31. Intuitive representation of the Principle of Matrix Decomposition.
Electronics 11 01806 g031
Figure 32. Schematic diagram of deep learning network structure.
Figure 32. Schematic diagram of deep learning network structure.
Electronics 11 01806 g032
Figure 33. Model-based recommender system.
Figure 33. Model-based recommender system.
Electronics 11 01806 g033
Figure 34. Schematic diagram based on matrix decomposition.
Figure 34. Schematic diagram based on matrix decomposition.
Electronics 11 01806 g034
Figure 35. Recommendation model deep learning process.
Figure 35. Recommendation model deep learning process.
Electronics 11 01806 g035
Figure 36. Performance evaluation of recommendation system based on RMSE and LOSS.
Figure 36. Performance evaluation of recommendation system based on RMSE and LOSS.
Electronics 11 01806 g036
Figure 37. Recommend 5 restaurants for customer ratings.
Figure 37. Recommend 5 restaurants for customer ratings.
Electronics 11 01806 g037
Figure 38. Start the server and client systems.
Figure 38. Start the server and client systems.
Electronics 11 01806 g038
Figure 39. Client demo part in DAPP (Restaurant list).
Figure 39. Client demo part in DAPP (Restaurant list).
Electronics 11 01806 g039
Figure 40. Client demo part in DAPP (Restaurant menu).
Figure 40. Client demo part in DAPP (Restaurant menu).
Electronics 11 01806 g040
Figure 41. Client demo part in DAPP (Payment order).
Figure 41. Client demo part in DAPP (Payment order).
Electronics 11 01806 g041
Figure 42. Restaurant client demo part in DAPP (Accept order).
Figure 42. Restaurant client demo part in DAPP (Accept order).
Electronics 11 01806 g042
Figure 43. Restaurant client demo part in DAPP (Delivery order).
Figure 43. Restaurant client demo part in DAPP (Delivery order).
Electronics 11 01806 g043
Figure 44. Comparison of transaction volume and throughput in P2P architecture.
Figure 44. Comparison of transaction volume and throughput in P2P architecture.
Electronics 11 01806 g044
Figure 45. Comparison of transaction volume and throughput in ETH and BTC architecture.
Figure 45. Comparison of transaction volume and throughput in ETH and BTC architecture.
Electronics 11 01806 g045
Figure 46. Transaction delay comparison of three architectures.
Figure 46. Transaction delay comparison of three architectures.
Electronics 11 01806 g046
Table 1. Comparison of the status of blockchain food delivery platforms.
Table 1. Comparison of the status of blockchain food delivery platforms.
TypeBistrooBaeminTakeaway.comEatzillaMeituan
Crypto PaymentYNNYN
User Data RewardYNNYN
User Revie RewardNYNYN
Platform Fees < 5%YNNYN
Merchant Advertising SystemNYYNY
Real Time Store ManagementYYYYY
Direct PaymentYNNYN
Managed DeliveriesNNNYY
Server DependenceLowHighHighLowHigh
Table 2. A Comparison of Platform-Based Blockchain Approaches.
Table 2. A Comparison of Platform-Based Blockchain Approaches.
NumberCategoryResearch ContentSummaryBenefits
1 [26]Multi-Chain Collaboration-Based Information Management and Control for the Rice Supply ChainThe research realizes credible information collection and traceability through supply chain solutions based on multi-chain blockchain.Multi-terminal information collectionReliability
2 [27]A Conceptual Model of a B2B Food Distribution Platform Based on Blockchain Consensus MechanismProvide a B2B food distribution blockchain platform based on DAPP, and establish a distribution management platform that combines online and offlineBlockchain Food Distribution PlatformNo commission
3 [28]A Blockchain-Based System to Ensure Transparency and Reliability in Food Supply ChainCreate transparency and reliability of supply chain platforms by studying the distributed nature of blockchainSupply Chain PlatformNo commission
4 [29]Decentralized Construction of Knowledge Graphs for Deep Recommender Systems Based on Blockchain-Powered Smart Contractsa novel decentralized knowledge graph construction method using crowdsourcing, and the business logic of crowdsourcing is implemented by blockchain-powered smart contracts to guarantee transparency, integrity, and suitability.Crowdsourced Decentralized Knowledge GraphTransparency, Integrity
5A Peer-to-Peer Smart Food Delivery Platform Based on Smart ContractProvide a smart food delivery platform by providing peer-to-peer service and crowdsourcing collectionSmart food delivery platform powered by blockchain smart contractsNo commissions, Transparency, Integrity
Table 3. A summary of the types of data information used by the recommender system.
Table 3. A summary of the types of data information used by the recommender system.
InformationDescribe
Restaurant PropertiesDescriptive information about restaurants (their characteristics). Examples include type, location, kind of menu, etc.
Menu PropertiesDescriptive information about the menus (i.e., their characteristics). Examples include sour, sweet, bitter, and spicy.
Restaurant RatingClear user feedback in the form of ratings. It can be scalar or binary.
Implicit User PreferencesImplicitly derived information related to user selection. Such as clicks, tags, and comments.
Recommended FeedbackThe user’s reaction to the recommendation. It is expressed as accept/reject values, positive or negative labels, etc. It can be used to define (implicit and explicit) user preferences.
User behavior informationImplicit data is recorded during user interaction with the wider system.
Contextual InformationInformation on the background of the proposal. Such as time, date, location, user status, etc.
Consumption HistoryA list of content items previously purchased or consumed by the user.
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Share and Cite

MDPI and ACS Style

Zhang, L.; Kim, D. A Peer-to-Peer Smart Food Delivery Platform Based on Smart Contract. Electronics 2022, 11, 1806. https://doi.org/10.3390/electronics11121806

AMA Style

Zhang L, Kim D. A Peer-to-Peer Smart Food Delivery Platform Based on Smart Contract. Electronics. 2022; 11(12):1806. https://doi.org/10.3390/electronics11121806

Chicago/Turabian Style

Zhang, Linchao, and Dohyeun Kim. 2022. "A Peer-to-Peer Smart Food Delivery Platform Based on Smart Contract" Electronics 11, no. 12: 1806. https://doi.org/10.3390/electronics11121806

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop