# SESCF: A Secure and Efficient Supply Chain Framework via Blockchain-Based Smart Contracts

Authors: Menghui Lou; Xiaolei Dong; Zhenfu Cao; Jiachen Shen
Journal: Security and Communication Networks
 (2021)

---

## Abstract

The demands for the fairness, security, and efficiency of the supply chain have grown significantly due to the rise of globalization. However, some problems of the information flow, logistics, and capital flow in the supply chain remain a challenge, such as the information asymmetry between upstream and downstream, substandard quality of goods, difficulty in traceability, and default of payment. Therefore, this paper proposes a blockchain-based supply chain framework (SESCF), which solves the supply chain problems securely and efficiently. First, the use of blockchain and smart contracts ensures the information symmetry in the supply chain system. Second, the radio frequency identification (RFID) provides a unique identity of goods, which helps in real-time quality monitoring. Additionally, the immutability and distributed storage of the blockchain play an important role in tracking the origin of goods. Third, the efficient payment channel is used to solve the problem of payment defaults. Furthermore, simulations of smart contracts along with the security analyses are presented in this paper. We also implement a blockchain-based supply chain system (SescfDapp), which is built upon a Consortium blockchain. Large-scale experiments and detailed analysis prove the feasibility and efficiency of our proposed system.


---

## Body

## 1. Introduction

In recent years, with the deepening of the global division of labor, the supply chain of modern enterprises has been continuously extended, resulting in the fragmentation, complexity, geographical dispersion, and other characteristics, which has brought great challenges to supply chain management [1–3]. The supply chain’s operations not only affect the core enterprise’s interests but also affect the whole supply chain and the relevant enterprises’ interests, which makes it increasingly important to propose a fair, secure, and efficient supply chain system [4–6]. Information flow, logistics, and capital flow are the three lifebloods of the supply chain. Information flow directs logistics, and logistics drives capital flow. However, in actual work, situations such as inadequate information flow, low logistics efficiency, and constant capital flow often occur. First, due to asymmetric and delayed information in the upstream and downstream, it is difficult for enterprises to control the flow of goods in real time. There is also the risk that information will be tampered to cause fraud, which will lead to a sharp increase in costs and a significant decrease in efficiency. Additionally, the modern supply chain encompasses all aspects of the production and distribution of goods, from raw materials to finished products delivered to consumers. However, the supply chain involves a vast range and weak supervision which has led buyers to lack a reliable way to verify the authenticity of goods. Therefore, the global counterfeit market is hugely flooded. A report released by the European Union states that the global market value of counterfeit trade is as high as more than 400 billion US dollars. About 5% of all goods imported into EU countries are fake and shoddy products over $100 billion [7], and monitoring the development of goods and efficient logistics management in the goods supply chain is critical to ensure goods quality. Meanwhile, the existing supply chain management systems have weak constraints and on-chain enterprises have a large operating space, resulting in the final cash settlement between the supplier and the buyer being highly dependent on the contractual spirit of the two parties, especially when multiparty transactions and multilevel transactions are involved. The above issues become more challenging when there is a lack of transparency and mutual trust in the current supply chain systems.Blockchain technology is a feasible way to solve the above issues; in other words, blockchain and supply chain are a natural pair [8–10]. First of all, the structure of the blockchain is a kind of time-series data that can store information, which is similar to the form of goods circulation in the supply chain. Secondly, the relatively low frequency of information updates in the supply chain avoids the shortcomings of current blockchain technology in terms of processing performance. Every transaction information on the blockchain, such as transaction parties, transaction time, and transaction content, will be recorded on a block and stored on the distributed ledger of each node on the chain, which ensures the integrity, reliability, and high transparency of the information. According to [11], for a variety of use cases in capital markets, distributed ledger technology (DLT) has the potential to reduce transaction latency, operational risk, process friction, liquidity requirements, and more. As mentioned in the 2018 China’s Blockchain Industry White Paper [12], blockchain technology has begun to be implemented in many areas of the real economy. The report introduces blockchain applications in the real economy from areas including goods traceability, copyright, and supply chain application scenarios. However, there are still many significant challenges when implementing blockchain-based systems in the real world.It is very challenging to propose an efficient system to ensure the fairness and security of the information flow, logistics, and capital flow of the supply chain at the same time, as the supply chain is fragmented, complicated, and geographically dispersed. Additionally, the feasibility and implementation of such a system remain to be solved. Therefore, in this paper, we propose a blockchain-based framework (SESCF) to ensure the fairness and security of the supply chain system efficiently. First, the use of blockchain and smart contracts in the supply chain enables information to be disclosed between upstream and downstream enterprises, since blockchain is a distributed ledger, that is, the information on the blockchain is recorded and shared by various participants at the same time. Besides, the radio frequency identification (RFID) provides a unique identity of each goods, which helps to monitor quality and trace the origin of the goods in real time [13, 14]. Simultaneously, we take advantage of the payment channel to solve the problem of payment defaults [15–18]. Here, SESCF allows the two parties in the transaction to put a certain amount of coins into the payment channel. Once a default or timeout occurs, the smart contract will be triggered to ensure the security of the coins of both parties. In our design, blockchain and smart contracts enable the verification of information, goods, and money, while they travel in the supply chain. We assume that honest users run a bug-free system, and smart contracts must be executed correctly. The contributions can be summarized as follows:(1)
As far as we know, this is the first efficient supply chain framework based on blockchain, which guarantees the fairness and security of the information flow, logistics, and capital flow. Meanwhile, the corresponding smart contracts are given in this paper.(2)
We have improved the efficiency of the supply chain by separating goods transactions and capital transactions, specifically, placing goods transactions on the chain and, conversely, putting capital transactions off the chain by opening payment channels.(3)
We run smart contracts in a simulation environment and evaluate the gas cost on the Ethereum network, and the experimental results proved the feasibility of our proposed solution. On this basis, we establish an efficient blockchain-based systemSescfDapp. Furthermore, we also conduct a detailed vulnerability assessment of SESCF and discuss how the system remains secure against malicious attacks.The remainder of this paper is organized as follows. Section2 discusses related work. Section 3 introduces the background techniques and related knowledge. Section 4 proposes a secure and efficient blockchain-based framework. Section 5 describes the implementation details. Section 6 shows the experimental results of our proposed system. Section 7 analyses the security of smart contracts in this work. Finally, Section 8 concludes this paper and proposes directions for future work.


## 2. Related Work

The blockchain was born in the Bitcoin system [19], and now more and more industries are proposing their blockchain solutions. Azaria et al. [20] proposed a decentralized system MedRec that uses blockchain processing EMRs. Zhang and Deng [21] proposed a secure billing protocol during taxi rides. Passengers and drivers use publicly verifiable two-party blockchains to agree on taxi ride fees. Biswas and Muthukkumarasamy [22] applied blockchain to smart cities and integrated blockchain with smart devices to provide a secure communication platform for smart cities.Furthermore, blockchain has been introduced in supply chain areas to make the chain more transparent, authentic, and trustworthy. A lot of research has been done to ensure the security and integrity of the supply chain [23, 24]. A shared, consensus-based, and immutable ledger helps track the origin and transformations undergone in the supply chain. The blockchain will create a formal registry to track the possession of goods throughout the supply chain.In the current research work, most researchers are committed to using blockchain technology and Internet of Things (IoT) devices to achieve transparency and traceability in the supply chain [4, 14, 25–30]. Bocek et al. [30] proposed that blockchain can be used in various physical fields and took the pharmaceutical supply chain as an example to introduce in detail how to use blockchain in the supply chain. To achieve fair transactions between producers and suppliers, Alahmadi and Lin [4] proposed a blockchain-based supply chain management system, which uses tamper-proof features of blockchain to make fair trade of goods. In [28], Marc Pilkington proposed that blockchain provides a groundbreaking method that can recreate transparency and establish new relationships with consumer products. To overcome the excessive addition of preservatives and harmful chemicals in the wine production process, Biswas et al. [26] proposed a blockchain-based wine supply chain traceability system to track counterfeit wine in the supply chain. In particular, there are many studies [14, 25, 27, 29] combined with the development of RFID and blockchain technology to establish a supply chain traceability system. Tian [25] proposed a novel agro-food supply chain traceability system and assessed the advantages and disadvantages of the system in the article. Toyoda et al. [27] proposed a product ownership management system (POMS) that attaches RFID to goods, which can be utilized to trace counterfeit products in the post supply chain system. Cui et al. [29] implemented a traceability system for the electronic parts supply chain based on the blockchain, tracing each chip in a nondestructive manner. Mondal et al. [14] proposed a blockchain-based food supply chain traceability system, combined with RFID and blockchain to build a complete system architecture to ensure the transparency of food in the supply chain system.


## 3. Background Techniques

In this section, we first introduce the technologies used in this paper, which contain blockchain, smart contract, RFID, and payment channel. Besides, we give brief analyses on how these technologies are used in SESCF and how effective they are.


### 3.1. Blockchain

Blockchain is a new application model of computer technology, such as distributed data storage, point-to-point transmission, consensus mechanisms, and encryption algorithms [9, 31]. In short, it is a list of records that are linked by cryptographic techniques. Unlike centralized databases, it is a decentralized transaction and data management technology and is in an ideal state for a low trust (or trustless) exchange system, that is, information in this system does not rely on the third party. Moreover, it utilizes peer-to-peer networks to perform peer-to-peer verification on items and distributes transaction details in the ledger. As the underlying technology of Bitcoin, blockchain has been a hot topic in the field of security and finance.According to the degree of network centralization, blockchain is divided into three types: (i) Public blockchain. People around the world can read data, send transactions, and “mine” in Public blockchain. Thereby, Public blockchain is also considered to be a completely decentralized existence, as no organization or institution is able to control it. As we know, Bitcoin and Ethereum are typical Public blockchain [19, 32]. (ii) Consortium blockchain: several organizations or institutions jointly participate in management in Consortium blockchain. It should be noted that, unlike the Public blockchain, only organizations in it have permission to access data. (iii) Private blockchain: an organization or institution controls the write right in Private blockchain, and nodes participating in it will be strictly restricted.In this paper, we implement an evaluation system for SESCF, which is built upon a Consortium blockchain. If a node wants to join SESCF, it needs to apply to Certification Authority (CA). After the node passes the CA verification successfully, it can join SESCF. Each node in SESCF has the power to compete for mining, and a certification composed of multiple entities can effectively prevent problems such as illegal transactions. If a transaction entity attempts to tamper with transaction records alone or with other transaction entities, other entities may prove their misconduct based on their transaction records and remove them from SESCF.


### 3.2. Smart Contract

Smart contract, as one of the Turing-complete programming languages, was first proposed by Nick Szabo in 1994 [31]. It is digital, and the protocol is enforced using encrypted code. In other words, smart contract is a computer protocol designed to facilitate, verify, and enforce negotiation digitally. Therefore, smart contract can perform reliable transactions without third parties, and these transactions are trackable and irreversible. In addition, smart contract cannot be tampered with because it has been stored and recorded on the blockchain. If anyone wants to tamper with it, he must tamper with the entire blockchain’s ledger, which is costly.Usually, an ordinary contract hinders the development of the supply chain because it takes much labour. What is more, due to the supply chain being highly open, theft, loss, and fraud are quite common. Fortunately, smart contract overcomes these shortcomings by providing parties with secure, transparent digital versions. Furthermore, it can automate tasks and transactions and even restrict behavior based on rules stored in code.


### 3.3. Radio Frequency Identification

Internet of Things (IoT), or “Internet of Everything,” is a huge network formed by combining various information sensing devices with the Internet. There are some IoT-based tracking and tracing infrastructures, such as electronic article surveillance (EAS), radio frequency identification (RFID), and QR codes, which are primarily targeted for automatic package-level tracking [33]. Among the IoT devices mentioned above, RFID is low load and small, so we use RFID to solve the problems in supply chain logistics [13, 17, 34–38]. Sensor data and RFID information from these devices can achieve near-real-time asset tracking, monitoring, and alerting. More broadly, the data generated by these devices help produce actionable results, informs business intelligence, and helps businesses improve operations.Furthermore, since blockchain is a distributed system, it cannot directly sense the status of logistics, such as the temperature of food during transportation. Therefore, the application of blockchain to logistics must be completed in conjunction with IoT. In the actual production process, it is necessary to attach an RFID tag to each goods to store information, such as ID and product information. In particular, when transporting goods with high requirements on temperature and other conditions, such as fruits, medicines, and frozen foods, the real-time information of the RFID tag of the cargo box is read through the handheld terminal to ensure the validity of the goods. According to the goods specification information (including the inspection and quarantine information of agricultural goods) stored in RFID tags, the quality inspection can be performed on the goods. Besides, the RFID tags can be used as the carrier of anticounterfeiting traceability information.


### 3.4. Payment Channel

In the current blockchain applications, such as Bitcoin [19], a new block needs to be propagated to all nodes in the network immediately before the next block is generated. This will ensure the security of the Bitcoin system. Therefore, to meet this characteristic, Bitcoin uses the proof of work (POW) to control the rate of block production to one block in 10 minutes. Furthermore, to ensure the block’s propagation rate, the block size is also limited [39].Using the payment channel to achieve off-chain payment has become a promising approach to solve Bitcoin’s efficiency and scalability issues [15–18]. Both parties’ transactions in the payment channel do not have to be chained. In short, the payment channel is like a secure deposit box, where they lock coins into a deposit secured by a smart contract. After the transactions are completed, the channel is closed, and all transactions between them are submitted to the network. In this step, the two parties get back their own coins according to their status after the last transaction.


## 3.1. Blockchain

Blockchain is a new application model of computer technology, such as distributed data storage, point-to-point transmission, consensus mechanisms, and encryption algorithms [9, 31]. In short, it is a list of records that are linked by cryptographic techniques. Unlike centralized databases, it is a decentralized transaction and data management technology and is in an ideal state for a low trust (or trustless) exchange system, that is, information in this system does not rely on the third party. Moreover, it utilizes peer-to-peer networks to perform peer-to-peer verification on items and distributes transaction details in the ledger. As the underlying technology of Bitcoin, blockchain has been a hot topic in the field of security and finance.According to the degree of network centralization, blockchain is divided into three types: (i) Public blockchain. People around the world can read data, send transactions, and “mine” in Public blockchain. Thereby, Public blockchain is also considered to be a completely decentralized existence, as no organization or institution is able to control it. As we know, Bitcoin and Ethereum are typical Public blockchain [19, 32]. (ii) Consortium blockchain: several organizations or institutions jointly participate in management in Consortium blockchain. It should be noted that, unlike the Public blockchain, only organizations in it have permission to access data. (iii) Private blockchain: an organization or institution controls the write right in Private blockchain, and nodes participating in it will be strictly restricted.In this paper, we implement an evaluation system for SESCF, which is built upon a Consortium blockchain. If a node wants to join SESCF, it needs to apply to Certification Authority (CA). After the node passes the CA verification successfully, it can join SESCF. Each node in SESCF has the power to compete for mining, and a certification composed of multiple entities can effectively prevent problems such as illegal transactions. If a transaction entity attempts to tamper with transaction records alone or with other transaction entities, other entities may prove their misconduct based on their transaction records and remove them from SESCF.


## 3.2. Smart Contract

Smart contract, as one of the Turing-complete programming languages, was first proposed by Nick Szabo in 1994 [31]. It is digital, and the protocol is enforced using encrypted code. In other words, smart contract is a computer protocol designed to facilitate, verify, and enforce negotiation digitally. Therefore, smart contract can perform reliable transactions without third parties, and these transactions are trackable and irreversible. In addition, smart contract cannot be tampered with because it has been stored and recorded on the blockchain. If anyone wants to tamper with it, he must tamper with the entire blockchain’s ledger, which is costly.Usually, an ordinary contract hinders the development of the supply chain because it takes much labour. What is more, due to the supply chain being highly open, theft, loss, and fraud are quite common. Fortunately, smart contract overcomes these shortcomings by providing parties with secure, transparent digital versions. Furthermore, it can automate tasks and transactions and even restrict behavior based on rules stored in code.


## 3.3. Radio Frequency Identification

Internet of Things (IoT), or “Internet of Everything,” is a huge network formed by combining various information sensing devices with the Internet. There are some IoT-based tracking and tracing infrastructures, such as electronic article surveillance (EAS), radio frequency identification (RFID), and QR codes, which are primarily targeted for automatic package-level tracking [33]. Among the IoT devices mentioned above, RFID is low load and small, so we use RFID to solve the problems in supply chain logistics [13, 17, 34–38]. Sensor data and RFID information from these devices can achieve near-real-time asset tracking, monitoring, and alerting. More broadly, the data generated by these devices help produce actionable results, informs business intelligence, and helps businesses improve operations.Furthermore, since blockchain is a distributed system, it cannot directly sense the status of logistics, such as the temperature of food during transportation. Therefore, the application of blockchain to logistics must be completed in conjunction with IoT. In the actual production process, it is necessary to attach an RFID tag to each goods to store information, such as ID and product information. In particular, when transporting goods with high requirements on temperature and other conditions, such as fruits, medicines, and frozen foods, the real-time information of the RFID tag of the cargo box is read through the handheld terminal to ensure the validity of the goods. According to the goods specification information (including the inspection and quarantine information of agricultural goods) stored in RFID tags, the quality inspection can be performed on the goods. Besides, the RFID tags can be used as the carrier of anticounterfeiting traceability information.


## 3.4. Payment Channel

In the current blockchain applications, such as Bitcoin [19], a new block needs to be propagated to all nodes in the network immediately before the next block is generated. This will ensure the security of the Bitcoin system. Therefore, to meet this characteristic, Bitcoin uses the proof of work (POW) to control the rate of block production to one block in 10 minutes. Furthermore, to ensure the block’s propagation rate, the block size is also limited [39].Using the payment channel to achieve off-chain payment has become a promising approach to solve Bitcoin’s efficiency and scalability issues [15–18]. Both parties’ transactions in the payment channel do not have to be chained. In short, the payment channel is like a secure deposit box, where they lock coins into a deposit secured by a smart contract. After the transactions are completed, the channel is closed, and all transactions between them are submitted to the network. In this step, the two parties get back their own coins according to their status after the last transaction.


## 4. SESCF

In this section, we first introduce the secure and efficient blockchain-based supply chain framework (SESCF), which solves the existing problems in the information flow, logistics, and capital flow. Immediately afterward, we provide the process of generating transactions in SESCF.


### 4.1. Blockchain-Based System Model

Figure1 illustrates a general overview of the system architecture to solve the existing problems of information flow, logistics, and capital flow. Our system introduces a competitive bidding mechanism to ensure the transparency of information between entities in SESCF. In addition, payment channels are used to allow the security of coins of these entities. The proposed system model follows a layered architecture and is divided into three layers. The first layer is the user layer that handles the offline transportation between entities of SESCF. These interactions involve goods along with RFID tags that store goods information. The second layer, i.e., the transaction layer, handles the online transactions of SESCF, including (i) trading event, in which the goods demander firstly publishes an order demand, then the goods suppliers bid based on it, and finally, the goods demander chooses the winning bidder to conduct the transaction, (ii) payment event, in which two parties conduct capital transactions by opening a payment channel, and (iii) delivery event, which is inspecting goods information when receiving the goods using the information stored in RFID. The third layer is the blockchain layer that stores transactions and data. Also, it tracks the source of the problematic goods involved in SESCF. It is worth noting that the blockchain layer enforces strict access control strategies to prevent unauthorized reading and writing of data.Figure 1
Blockchain-based supply chain model.SESCF only allows registered users to perform specific transactions. If a node wants to join SESCF, it needs to be authenticated by Certificate Authority first. That is, Certificate Authority is responsible for registering the identity of all entities in SESCF. In addition, each function is allowed to be performed by specific entities. The entities are described as follows:Supplier, Producer, Retailer, and Certificate Authority.Supplier (S). Suppliers are the enterprises that supply various required resources to producers and their competitors, which include the provision of raw materials, equipment, energy, and labor.Producer (P). Producers are the enterprises that supply goods to retailers. They use raw materials or components to make a series of daily consumer goods through relatively automated machinery and production processes. When P and S reach a demand agreement, P will apply to open an off-chain channel with S.Retailer (R). Retailers are the enterprises whose sales are mainly from retail, that is to say, retailers sell goods directly to the end consumers. Compared with producers, they are in the final stage of goods circulation. Similarly, when R and P reach a demand agreement, R will apply to open an off-chain channel with P.Certificate Authority (CA). Certification Authority is an organization that issues digital certificates. Furthermore, as a trusted third party in e-commerce transactions, it is responsible for checking the legality of public keys in the public-key system.In the following paper, since the scenario between retailers and producers is similar to that between producers and suppliers, we only take the raw material transaction between suppliers and producers as an example. In addition, the system model is divided into three parts: information flow, logistics, and capital flow.


### 4.2. Information Flow

In goods circulation, the flow of all information is called information flow. Moreover, information sharing helps improve the efficiency of the system. However, due to the information asymmetry of upstream and downstream caused by factors such as time, space, and technology, the traditional supply chain information system is distributed in the hands of various participants. So far, no platform can gather all goods information with complete trust. Therefore, we propose to use blockchain to solve the problems of the information flow. Here, the information flow mainly refers to supply and demand information.Each participating entity has a pair of public and private keys and participates by invoking functions within the smart contract. To address the opacity of supply and demand information between upstream and downstream, a competitive bidding method is introduced in SESCF. Figure2 outlines the sequence flow for a scenario where the goods demander, i.e., producer, and the goods suppliers, i.e., suppliers, complete the trading event by invoking the smart contract. When P needs a batch of raw materials, he executes the SendTender TP,S1,…,SN,Ttender function to release the tender announcement to S1,…,SN, i.e., N suppliers in SESCF. Here, Ttender is a demand order for raw materials signed with P’s private key, and its format is shown in (1). Then, the event RequestedSendTender is invoked and is made available to all active participants (i.e., P and S1,…,SN). S1,…,SN execute the SendBidS1,…,SN,P,eprice,Ttender function to send bid price before the deadline for bidding, where the attribute eprice refers to the bid price encrypted with P’s public key. It is worth noting that if entities do not participate in this bid, there is no need to send bid price. Once the bid deadline is reached, P uses his private key to decrypt S1, eprice, …, SN.eprice to get, price, …, SN.price, and then, the ComputeWinBidder (P, S1, price, …, SN·price, Ttender) function is executed to choose the supplier with the lowest bid price as Swin, i.e., the winning bidder. The RequestedComputeWinBidder event triggers the smart contract, which then automatically executes InformLetterofAcceptance (P, S1, …, SN, Swin, Ttender) to notify the participating entities of the winning bidder. After P and Swin reach an agreement through the event RequestedInformLetterofAcceptance, Swin signs Ttender with his private key and executes the BroadcastTender (Swin, P, Ttender) function to broadcast this transaction. The event RequestedBroadcastTender is activated to notify the interacting entities of this transaction (i.e., P and Swin) at that specific time point:(1)Ttender=OnameOsizeQspecNummaxTxtypePDLDT1T2T3,where Oname represents the order name of the tender, specifically, it means the raw materials required by P. Osize refers to the order quantity of the tender, which represents the number of raw materials required by P. Qspec refers to the quality specifications of the goods and Nummax refers to the maximum number of substandard goods. Txtype refers to the type of transaction, and it should be noted that Txtype is txptos in Ttender, which refers to the transaction sent by P to S. PD refers to the deposit, which is part of the price that P needs to pay to S in advance. LD represents liquidated damages, which is the amount payable to P if S does not deliver before the delivery deadline. The three times in Ttender represent three deadlines: T1 is the deadline for bidding, T2 is the deadline for computing Swin, and T3 is the deadline for delivery.Figure 2
Sequence diagram showing interactions between suppliers, smart contract, and producer to address the opacity of supply and demand.


### 4.3. Logistics

Logistics is the process of integrating the functions of transportation, storage, and distribution from the supplier to the receiver. Because the structure of the supply chain is extremely complex, there are many counterfeit goods, and it is a very time-consuming and challenging task to track goods in the logistics. Therefore, in SESCF, we mainly solve the problems of substandard quality and traceability in logistics.Figure3 represents the message sequence diagram for quality inspection. That is, perform quality inspection when the goods are delivered, and refuse to accept them if the quality is unqualified. Following the offline delivery from Swin to P, the function SendDelivery (Swin, P, Tdelivery) is executed and the event RequestedDelivery is activated. Here the parameter Tdelivery is a delivery note signed with the private key of Swin, and its format is shown in (2). After receiving the goods offline, P calls the function InspectGoods (P, Swin, RFIDInfo, Qspec, Nummax) to inspect the quality, and the parameters RFIDInfo represents the goods information that is stored in the RFID. The RequestedInspectGoods event triggers the smart contract to automatically execute SendFlag (P, Swin, count, flag) to notify the inspection result, where the attribute count indicates the total number of unqualified goods, and flag indicates whether it has passed the test, i.e., true or false. If flag is true, P signs Tdelivery with his private key and executes BroadcastDelivery (P, Swin, Tdelivery) to broadcast this transaction. Otherwise, P returns the goods to Swin.Figure 3
Sequence diagram showing interactions betweenSupplierwin, smart contract, and producer to inspect the goods quality.On the other hand, although fakes often appear in our lives, tracking fakes in the supply chain is very troublesome. Therefore, Figure4 shows the message sequence diagram in which the user uses the smart contract to track the origin of goods. Once the user finds a fake, he first scans the RFID tag of it and passes Gid and id_set which are stored in the RFID as parameters to the function TraceGoods (user, Gid, id_set). By doing so, users can trace not only the producer of the fake but also the suppliers who provide raw materials for the fake. The RequestedTraceGoods event triggers the smart contract to query transactions in the blockchain, and then, the query results are returned to the user through the function SendTraceResult (user, tx_set), where tx_set is the transaction set.(2)Tdelivery=ExhashTxtypeTxGoods,where EXhash represents the hash value of the related tender transaction. Txtype refers to the type of transaction, and Txtype is txstop in Tdelivery, which refers to the transaction sent by S to P. Tx is the delivery order, and Goods specifically refers to the content of the RFID tag. Moreover, the RFID tag contains Gid (goods id), id_set (the raw material id set of goods), goods name, origin, source, production date, goods specification information (including expiration date), etc. It should be noted that each Gid is unique in our system. For agricultural goods, Qspec refers to the inspection and quarantine information. Especially for goods with timeliness, such as meat and fruits, special attention should be paid to the expiration date.Figure 4
Sequence diagram showing interactions between user and smart contract to track the origin of goods.


### 4.4. Capital Flow

Capital flow is the process of currency circulation. The efficiency and dynamic optimization of upstream and downstream capital operations are directly related to the operation quality of corporate capital circulation. However, payment defaults are common problems in the supply chain. To solve payment defaults, we consider opening a payment channel on both sides of the transaction. Moreover, placing capital transactions off-chain reduces the waste of on-chain resources.Figure5 outlines the sequence flow for a scenario where the producer and the winning bidder pay the deposit, balance, and liquidated damages in the payment channel. Following Swin broadcasts Ttender, the function OpenChannel (P, Swin, Ttender, timelock) is executed to apply for opening a payment channel between P and Swin, where timelock refers to the active time of the channel. After the channel is successfully opened, P and Swin first sign it with their private keys through the event RequestedOpenChannel and then put some coins from the wallet into it by executing the functions InputCoins (P, coin, Channel) and InputCoins (Swin, coin, Channel). In particular, in the multisignature address controlled by both parties, P is required to store not less than the price of the order, and Swin is required to store not less than LD. Now, P executes the function PayDeposit (P, Swin, PD, Channel) to pay the deposit to Swin. If Swin delivers on time, PayBalance (P, Swin, balance, Channel) is executed by P to pay the balance. Otherwise, Swin executes PayLiquidatedDamages (Swin, P, LD, Channel) to pay the liquidated damages. In particular, if Swin delivers before the deadline, both P and Swin can execute the function CloseChannel (P, Swin, Ttender, Channel) to apply for closing the payment channel in advance. The event RequestedCloseChannel is activated to notify the interacting entities that the channel is closed successfully, and P and Swin will get back their respective coins according to the status of the last transaction. Unlike digital currencies such as Bitcoin, the form of payment transaction Tpay is shown in the following equation:(3)Tpay=ExhashTxinTxoutTxtypeTxcount.Figure 5
Sequence diagram showing interactions betweenSupplierwin, smart contract, and producer to pay deposit, balance, and liquidated damages.EXhash represents the hash value of the associated tender transaction. Txin is the input address, and Txout is the output address. Txtype is the type of payment transaction, and we determine it based on the increase or decrease of P’s coins and Swin’s coins after the channel is closed: (i) if P’s coins increase and Swin’s coins decrease, it means that Swin did not deliver on time, and Swin pays P the liquidated damage, and then Txtype is LD; (ii) if P’s coins decrease and Swin’s coins increase, it means that S delivered on time, and P pays Swin the price of the goods, and then Txtype is the price of the goods. Txcount is the amount of Tpay.


## 4.1. Blockchain-Based System Model

Figure1 illustrates a general overview of the system architecture to solve the existing problems of information flow, logistics, and capital flow. Our system introduces a competitive bidding mechanism to ensure the transparency of information between entities in SESCF. In addition, payment channels are used to allow the security of coins of these entities. The proposed system model follows a layered architecture and is divided into three layers. The first layer is the user layer that handles the offline transportation between entities of SESCF. These interactions involve goods along with RFID tags that store goods information. The second layer, i.e., the transaction layer, handles the online transactions of SESCF, including (i) trading event, in which the goods demander firstly publishes an order demand, then the goods suppliers bid based on it, and finally, the goods demander chooses the winning bidder to conduct the transaction, (ii) payment event, in which two parties conduct capital transactions by opening a payment channel, and (iii) delivery event, which is inspecting goods information when receiving the goods using the information stored in RFID. The third layer is the blockchain layer that stores transactions and data. Also, it tracks the source of the problematic goods involved in SESCF. It is worth noting that the blockchain layer enforces strict access control strategies to prevent unauthorized reading and writing of data.Figure 1
Blockchain-based supply chain model.SESCF only allows registered users to perform specific transactions. If a node wants to join SESCF, it needs to be authenticated by Certificate Authority first. That is, Certificate Authority is responsible for registering the identity of all entities in SESCF. In addition, each function is allowed to be performed by specific entities. The entities are described as follows:Supplier, Producer, Retailer, and Certificate Authority.Supplier (S). Suppliers are the enterprises that supply various required resources to producers and their competitors, which include the provision of raw materials, equipment, energy, and labor.Producer (P). Producers are the enterprises that supply goods to retailers. They use raw materials or components to make a series of daily consumer goods through relatively automated machinery and production processes. When P and S reach a demand agreement, P will apply to open an off-chain channel with S.Retailer (R). Retailers are the enterprises whose sales are mainly from retail, that is to say, retailers sell goods directly to the end consumers. Compared with producers, they are in the final stage of goods circulation. Similarly, when R and P reach a demand agreement, R will apply to open an off-chain channel with P.Certificate Authority (CA). Certification Authority is an organization that issues digital certificates. Furthermore, as a trusted third party in e-commerce transactions, it is responsible for checking the legality of public keys in the public-key system.In the following paper, since the scenario between retailers and producers is similar to that between producers and suppliers, we only take the raw material transaction between suppliers and producers as an example. In addition, the system model is divided into three parts: information flow, logistics, and capital flow.


## 4.2. Information Flow

In goods circulation, the flow of all information is called information flow. Moreover, information sharing helps improve the efficiency of the system. However, due to the information asymmetry of upstream and downstream caused by factors such as time, space, and technology, the traditional supply chain information system is distributed in the hands of various participants. So far, no platform can gather all goods information with complete trust. Therefore, we propose to use blockchain to solve the problems of the information flow. Here, the information flow mainly refers to supply and demand information.Each participating entity has a pair of public and private keys and participates by invoking functions within the smart contract. To address the opacity of supply and demand information between upstream and downstream, a competitive bidding method is introduced in SESCF. Figure2 outlines the sequence flow for a scenario where the goods demander, i.e., producer, and the goods suppliers, i.e., suppliers, complete the trading event by invoking the smart contract. When P needs a batch of raw materials, he executes the SendTender TP,S1,…,SN,Ttender function to release the tender announcement to S1,…,SN, i.e., N suppliers in SESCF. Here, Ttender is a demand order for raw materials signed with P’s private key, and its format is shown in (1). Then, the event RequestedSendTender is invoked and is made available to all active participants (i.e., P and S1,…,SN). S1,…,SN execute the SendBidS1,…,SN,P,eprice,Ttender function to send bid price before the deadline for bidding, where the attribute eprice refers to the bid price encrypted with P’s public key. It is worth noting that if entities do not participate in this bid, there is no need to send bid price. Once the bid deadline is reached, P uses his private key to decrypt S1, eprice, …, SN.eprice to get, price, …, SN.price, and then, the ComputeWinBidder (P, S1, price, …, SN·price, Ttender) function is executed to choose the supplier with the lowest bid price as Swin, i.e., the winning bidder. The RequestedComputeWinBidder event triggers the smart contract, which then automatically executes InformLetterofAcceptance (P, S1, …, SN, Swin, Ttender) to notify the participating entities of the winning bidder. After P and Swin reach an agreement through the event RequestedInformLetterofAcceptance, Swin signs Ttender with his private key and executes the BroadcastTender (Swin, P, Ttender) function to broadcast this transaction. The event RequestedBroadcastTender is activated to notify the interacting entities of this transaction (i.e., P and Swin) at that specific time point:(1)Ttender=OnameOsizeQspecNummaxTxtypePDLDT1T2T3,where Oname represents the order name of the tender, specifically, it means the raw materials required by P. Osize refers to the order quantity of the tender, which represents the number of raw materials required by P. Qspec refers to the quality specifications of the goods and Nummax refers to the maximum number of substandard goods. Txtype refers to the type of transaction, and it should be noted that Txtype is txptos in Ttender, which refers to the transaction sent by P to S. PD refers to the deposit, which is part of the price that P needs to pay to S in advance. LD represents liquidated damages, which is the amount payable to P if S does not deliver before the delivery deadline. The three times in Ttender represent three deadlines: T1 is the deadline for bidding, T2 is the deadline for computing Swin, and T3 is the deadline for delivery.Figure 2
Sequence diagram showing interactions between suppliers, smart contract, and producer to address the opacity of supply and demand.


## 4.3. Logistics

Logistics is the process of integrating the functions of transportation, storage, and distribution from the supplier to the receiver. Because the structure of the supply chain is extremely complex, there are many counterfeit goods, and it is a very time-consuming and challenging task to track goods in the logistics. Therefore, in SESCF, we mainly solve the problems of substandard quality and traceability in logistics.Figure3 represents the message sequence diagram for quality inspection. That is, perform quality inspection when the goods are delivered, and refuse to accept them if the quality is unqualified. Following the offline delivery from Swin to P, the function SendDelivery (Swin, P, Tdelivery) is executed and the event RequestedDelivery is activated. Here the parameter Tdelivery is a delivery note signed with the private key of Swin, and its format is shown in (2). After receiving the goods offline, P calls the function InspectGoods (P, Swin, RFIDInfo, Qspec, Nummax) to inspect the quality, and the parameters RFIDInfo represents the goods information that is stored in the RFID. The RequestedInspectGoods event triggers the smart contract to automatically execute SendFlag (P, Swin, count, flag) to notify the inspection result, where the attribute count indicates the total number of unqualified goods, and flag indicates whether it has passed the test, i.e., true or false. If flag is true, P signs Tdelivery with his private key and executes BroadcastDelivery (P, Swin, Tdelivery) to broadcast this transaction. Otherwise, P returns the goods to Swin.Figure 3
Sequence diagram showing interactions betweenSupplierwin, smart contract, and producer to inspect the goods quality.On the other hand, although fakes often appear in our lives, tracking fakes in the supply chain is very troublesome. Therefore, Figure4 shows the message sequence diagram in which the user uses the smart contract to track the origin of goods. Once the user finds a fake, he first scans the RFID tag of it and passes Gid and id_set which are stored in the RFID as parameters to the function TraceGoods (user, Gid, id_set). By doing so, users can trace not only the producer of the fake but also the suppliers who provide raw materials for the fake. The RequestedTraceGoods event triggers the smart contract to query transactions in the blockchain, and then, the query results are returned to the user through the function SendTraceResult (user, tx_set), where tx_set is the transaction set.(2)Tdelivery=ExhashTxtypeTxGoods,where EXhash represents the hash value of the related tender transaction. Txtype refers to the type of transaction, and Txtype is txstop in Tdelivery, which refers to the transaction sent by S to P. Tx is the delivery order, and Goods specifically refers to the content of the RFID tag. Moreover, the RFID tag contains Gid (goods id), id_set (the raw material id set of goods), goods name, origin, source, production date, goods specification information (including expiration date), etc. It should be noted that each Gid is unique in our system. For agricultural goods, Qspec refers to the inspection and quarantine information. Especially for goods with timeliness, such as meat and fruits, special attention should be paid to the expiration date.Figure 4
Sequence diagram showing interactions between user and smart contract to track the origin of goods.


## 4.4. Capital Flow

Capital flow is the process of currency circulation. The efficiency and dynamic optimization of upstream and downstream capital operations are directly related to the operation quality of corporate capital circulation. However, payment defaults are common problems in the supply chain. To solve payment defaults, we consider opening a payment channel on both sides of the transaction. Moreover, placing capital transactions off-chain reduces the waste of on-chain resources.Figure5 outlines the sequence flow for a scenario where the producer and the winning bidder pay the deposit, balance, and liquidated damages in the payment channel. Following Swin broadcasts Ttender, the function OpenChannel (P, Swin, Ttender, timelock) is executed to apply for opening a payment channel between P and Swin, where timelock refers to the active time of the channel. After the channel is successfully opened, P and Swin first sign it with their private keys through the event RequestedOpenChannel and then put some coins from the wallet into it by executing the functions InputCoins (P, coin, Channel) and InputCoins (Swin, coin, Channel). In particular, in the multisignature address controlled by both parties, P is required to store not less than the price of the order, and Swin is required to store not less than LD. Now, P executes the function PayDeposit (P, Swin, PD, Channel) to pay the deposit to Swin. If Swin delivers on time, PayBalance (P, Swin, balance, Channel) is executed by P to pay the balance. Otherwise, Swin executes PayLiquidatedDamages (Swin, P, LD, Channel) to pay the liquidated damages. In particular, if Swin delivers before the deadline, both P and Swin can execute the function CloseChannel (P, Swin, Ttender, Channel) to apply for closing the payment channel in advance. The event RequestedCloseChannel is activated to notify the interacting entities that the channel is closed successfully, and P and Swin will get back their respective coins according to the status of the last transaction. Unlike digital currencies such as Bitcoin, the form of payment transaction Tpay is shown in the following equation:(3)Tpay=ExhashTxinTxoutTxtypeTxcount.Figure 5
Sequence diagram showing interactions betweenSupplierwin, smart contract, and producer to pay deposit, balance, and liquidated damages.EXhash represents the hash value of the associated tender transaction. Txin is the input address, and Txout is the output address. Txtype is the type of payment transaction, and we determine it based on the increase or decrease of P’s coins and Swin’s coins after the channel is closed: (i) if P’s coins increase and Swin’s coins decrease, it means that Swin did not deliver on time, and Swin pays P the liquidated damage, and then Txtype is LD; (ii) if P’s coins decrease and Swin’s coins increase, it means that S delivered on time, and P pays Swin the price of the goods, and then Txtype is the price of the goods. Txcount is the amount of Tpay.


## 5. Implementation Details of SESCF

In this section, we implement SESCF from three parts: information flow, logistics, and capital flow. In particular, specific smart contracts for each part are given.


### 5.1. Information Flow

As discussed earlier, we propose to use a competitive bidding mechanism to ensure the symmetry of upstream and downstream supply and demand information. That is,P issues a tender announcement, then S1, …, SN bid, and finally, P chooses the lowest bidder as Swin. According to these processes, three primitives are defined: Tender, Bid, and Compute. The process is described in Algorithm 1.Tender. In the tender stage, P first sends Ttender signed with P’s private key sKP to the smart contract. Then, the smart contract forwards Ttender to S1, …, SN after receiving Ttender.Bid. In the bid stage, after receiving Ttender forwarded by the smart contract, S1, …, SN choose to bid or give up according to Ttender. If they choose to bid, they need to use P’s public key, i.e., pKP, and a random number r to encrypt the bid price and then use NIZK to compute a zero-knowledge proof π to prove that eprice is constructed correctly. It is worth noting that each user does not know others’ bids before committing to their own, so that the user’s bid is independent of others’. As long as P does not disclose the bid information, users’ bids remain private even after bidding. After receiving the message from S1, …, SN, the smart contract first determines the current time is less than T1, ensures that S1, …, SN conduct bidding exercises for the first time, and then verifies their commitments are correct. If verifications are passed, the smart contract automatically forwards their bid messages to P.Compute. In the compute stage, S1, …, SN first call for computing. If S1 (i∈1,…n) has not called for computing before T2, it means that it has abandoned the bid. Then, P decrypts their bids withsKP and compares them with the price cycle to select Swin (Swin∈S1,…,SN) with the lowest price. After that, the smart contract sends the message whether they are the winning bidder to S1, …, SN. Finally, Swin uses skS to sign and broadcast Ttender.Algorithm 1:Competitive bidding() for P and S1, …, SN.
(1)
tender: P inputs Ttender signed with sKP(2)
Smart contract forwardsTtender to S1, …, SN(3)
bid:S1, …, SN receive Ttender(4)
sample encryption randomnessr(5)
eprice := ENC (pkP, r, $price)(6)
π  := NIZK.prove((P, eprice), ($price, r))(7)
S1, …, SN send (eprice, π)(8)
Smart contract receives (eprice,π) from Si (i∈1,…N)(9)
assert current timeT<T1(10)
assert this is the first bid input(11)
assert NIZK.verify (Rcompute, π, (P, eprice))(12)
Smart contract sends (Si, eprice) to P(13)
store eprice,Ttender to use later in(14)
compute: on input (compute) as Supplier S1, …, SN(15)
assert current timeT1<T<T2(16)
P decrypts and stores($ price) := DEC(skP, eprice)(17)
if this is the last compute received then(18)
fori∈1,…,n such that Si has not called for compute(19)
$price := +∞(20)
end if(21)
winsupplier := −1(22)
bestprice: = +∞(23)
fori∈1,…,ndo(24)
ifSi.price < bestprice then(25)
bestprice :=Si.price(26)
Swin := Si(27)
end if(28)
end for(29)
store and outputSwin(30)
Swin signs Ttender with skS(31)
Swin broadcasts Ttender(32)
Relation (statement, witness)∈ Rcompute is defined as(33)
parse statement as (P.eprice)(34)
parse witness as ($price,r)(35)
assert eprice = ENC(pkP, r, $price)


### 5.2. Logistics

At the time of delivery, the buyer first scans the RFID and then usesRFIDInfo, Qspec, and Nummax as inputs to trigger the smart contract for quality inspection. We define a primitive to complete the quality inspection: Inspect. The process is described in Algorithm 2.Inspect. Swin first sends Tdelivery signed with skS to the smart contract before the latest delivery time T3, and the smart contract forwards Tdelivery to P. Then, after P receives the goods offline, he scans the RFID tags. Meanwhile, Qspec, Nummax, and RFIDInfo are passed as parameters to the smart contract for quality inspection. Specifically, the smart contract traverses the information of the goods and compares them with Qspec. There are two cases in the inspection result: (i) if the number of substandard goods is not greater than Nummax, then P will sign Tdelivery with skP and broadcast Tdelivery. (ii) If the number of substandard goods is greater than Nummax, the smart contract will notify P and Swin of the number of substandard goods, and P will return the goods to Swin offline.Algorithm 2:Inspect() for P and.Swin.
(1)
inspect:Swin inputs Tdelivery signed with skS(2)
assert current timeT < Exhash.T3(3)
N := Goods.count(4)
assertN = Exhash.Osize(5)
Smart contract forwardsTdelivery to P(6)
P scans and inputs the RFID tag of the goods(7)
P inputs (Qspec, Nummax)(8)
count := 0(9)
fori∈ [N] do(10)
compareGoodsi.information with Qspec(11)
if the quality of Goodsi is not up to standard then(12)
count++(13)
end if(14)
end for(15)
if count> Nummax then(16)
Smart contract sends count toP and Swin(17)
else(18)
P signs Tdelivery with skP(19)
P broadcasts Tdelivery(20)
end ifAlgorithm3 describes the process of tracking the origin of fakes in SESCF. Similarly, we define a primitive to complete the traceability: Trace.Trace. Using a unique Gid to identify the goods can achieve traceability. In Section 4.3, we have introduced Gid and id_set. Once a problem is found with the goods, the user can scan the RFID to obtain the unique Gid and id_set. The goods information contained in Tdelivery is stored on the blockchain so that users can locate the corresponding Tdelivery and further locate the supplier of the problem goods according to Gid and id_set.Algorithm 3:Trace() for user Ni.
(1)
trace:Ni scans the RFID tag of the goods(2)
Ni inputs Gid and id_set(3)
total := id_set.length +1(4)
num = 0(5)
for tx.Txtype = txstop and num = total do(6)
if Gid = tx.Goodsj.Gid or id_set.id =  tx.Goodsj.Gid then(7)
send tx toNi(8)
num++(9)
end if(10)
end for


### 5.3. Capital Flow

Algorithm4 describes the process of solving payment defaults in the supply chain. Specifically, after Swin broadcasts Ttender, a payment channel C < P, Swin> with a time lock of T3 is opened between P and Swin immediately. We define three primitives to complete the payment: Open channel, Payment, and Close channel. Here, txhash refers to Ttender’s hash value.Open channel. In the open channel stage, P releases the coins not less than the order price into the channel, and Swin releases the coins not less than LD into the channel. As well as, the time lock is set to T3. Finally, both parties use their private keys to sign the channel C < P, Swin>. The role of the time lock is to set the latest closing time of the channel. In simple terms, after T3, if C < P, Swin> is not closed yet, it will automatically close, at the same time, the coins in the channel are redistributed and submitted to the blockchain.Payment. In the payment stage, P pays SwinPD after the channel is opened. If Swin fails to deliver to P before T3, he will pay LD to P automatically through the smart contract at T3. On the contrary, if Swin successfully delivers to P before T3, P will pay Swin the balance through the smart contract.Close channel. After successful delivery beforeT3, P or Swin applies for closing the payment channel. If C < P, Swin> has not been closed at T3, it indicates that Swin failed to deliver before T3; then Swin pays LD to P. P and Swin sign off C < P, Swin> and submit the balance of their coins to the blockchain.Algorithm 4:Payment() for P and Swin.
(1)
open channel: P inputs (open, C < P, Swin>, Swin)(2)
Smart contract sends (C < P, Swin>, txhash) to Swin(3)
P inputs CoinP to C < P, Swin>(4)
P.account :=  CoinP(5)
assertCoinP> txhash.price(6)
Swin inputs CoinS to C < P, Swin>(7)
Swin.account := CoinS(8)
assertCoinS> txhash.LD(9)
t := tx.hash.T3(10)
P and Swin sign C < P, Swin>(11)
payment: after P and Swin sign the channel(12)
P pays txhash.PD to Swin(13)
P.account := P.account—txhash.PD(14)
Swin.account :=  Swin.account + txhash.PD(15)
ifSwin did not deliver the goods before tthen(16)
Swin pay txhash.LD to P(17)
P.account := P.account + txhash.LD(18)
Swin.account := Swin.account—txhash.LD(19)
else(20)
txhash.balance :=Swin.price—txhash.PD(21)
P pay txhash.balance to Swin(22)
P.account := P.account − txhash.balance(23)
Swin.account := Swin.account + txhash.balance(24)
end if(25)
P or Swin call to close channel(26)
close channel: on input (close, C < P, Swin>, txhash) from P and Swin(27)
P.wallet := P.wallet + P.account(28)
Swin.wallet := Swin.wallet + Swin.account(29)
P and Swin sign off


## 5.1. Information Flow

As discussed earlier, we propose to use a competitive bidding mechanism to ensure the symmetry of upstream and downstream supply and demand information. That is,P issues a tender announcement, then S1, …, SN bid, and finally, P chooses the lowest bidder as Swin. According to these processes, three primitives are defined: Tender, Bid, and Compute. The process is described in Algorithm 1.Tender. In the tender stage, P first sends Ttender signed with P’s private key sKP to the smart contract. Then, the smart contract forwards Ttender to S1, …, SN after receiving Ttender.Bid. In the bid stage, after receiving Ttender forwarded by the smart contract, S1, …, SN choose to bid or give up according to Ttender. If they choose to bid, they need to use P’s public key, i.e., pKP, and a random number r to encrypt the bid price and then use NIZK to compute a zero-knowledge proof π to prove that eprice is constructed correctly. It is worth noting that each user does not know others’ bids before committing to their own, so that the user’s bid is independent of others’. As long as P does not disclose the bid information, users’ bids remain private even after bidding. After receiving the message from S1, …, SN, the smart contract first determines the current time is less than T1, ensures that S1, …, SN conduct bidding exercises for the first time, and then verifies their commitments are correct. If verifications are passed, the smart contract automatically forwards their bid messages to P.Compute. In the compute stage, S1, …, SN first call for computing. If S1 (i∈1,…n) has not called for computing before T2, it means that it has abandoned the bid. Then, P decrypts their bids withsKP and compares them with the price cycle to select Swin (Swin∈S1,…,SN) with the lowest price. After that, the smart contract sends the message whether they are the winning bidder to S1, …, SN. Finally, Swin uses skS to sign and broadcast Ttender.Algorithm 1:Competitive bidding() for P and S1, …, SN.
(1)
tender: P inputs Ttender signed with sKP(2)
Smart contract forwardsTtender to S1, …, SN(3)
bid:S1, …, SN receive Ttender(4)
sample encryption randomnessr(5)
eprice := ENC (pkP, r, $price)(6)
π  := NIZK.prove((P, eprice), ($price, r))(7)
S1, …, SN send (eprice, π)(8)
Smart contract receives (eprice,π) from Si (i∈1,…N)(9)
assert current timeT<T1(10)
assert this is the first bid input(11)
assert NIZK.verify (Rcompute, π, (P, eprice))(12)
Smart contract sends (Si, eprice) to P(13)
store eprice,Ttender to use later in(14)
compute: on input (compute) as Supplier S1, …, SN(15)
assert current timeT1<T<T2(16)
P decrypts and stores($ price) := DEC(skP, eprice)(17)
if this is the last compute received then(18)
fori∈1,…,n such that Si has not called for compute(19)
$price := +∞(20)
end if(21)
winsupplier := −1(22)
bestprice: = +∞(23)
fori∈1,…,ndo(24)
ifSi.price < bestprice then(25)
bestprice :=Si.price(26)
Swin := Si(27)
end if(28)
end for(29)
store and outputSwin(30)
Swin signs Ttender with skS(31)
Swin broadcasts Ttender(32)
Relation (statement, witness)∈ Rcompute is defined as(33)
parse statement as (P.eprice)(34)
parse witness as ($price,r)(35)
assert eprice = ENC(pkP, r, $price)


## 5.2. Logistics

At the time of delivery, the buyer first scans the RFID and then usesRFIDInfo, Qspec, and Nummax as inputs to trigger the smart contract for quality inspection. We define a primitive to complete the quality inspection: Inspect. The process is described in Algorithm 2.Inspect. Swin first sends Tdelivery signed with skS to the smart contract before the latest delivery time T3, and the smart contract forwards Tdelivery to P. Then, after P receives the goods offline, he scans the RFID tags. Meanwhile, Qspec, Nummax, and RFIDInfo are passed as parameters to the smart contract for quality inspection. Specifically, the smart contract traverses the information of the goods and compares them with Qspec. There are two cases in the inspection result: (i) if the number of substandard goods is not greater than Nummax, then P will sign Tdelivery with skP and broadcast Tdelivery. (ii) If the number of substandard goods is greater than Nummax, the smart contract will notify P and Swin of the number of substandard goods, and P will return the goods to Swin offline.Algorithm 2:Inspect() for P and.Swin.
(1)
inspect:Swin inputs Tdelivery signed with skS(2)
assert current timeT < Exhash.T3(3)
N := Goods.count(4)
assertN = Exhash.Osize(5)
Smart contract forwardsTdelivery to P(6)
P scans and inputs the RFID tag of the goods(7)
P inputs (Qspec, Nummax)(8)
count := 0(9)
fori∈ [N] do(10)
compareGoodsi.information with Qspec(11)
if the quality of Goodsi is not up to standard then(12)
count++(13)
end if(14)
end for(15)
if count> Nummax then(16)
Smart contract sends count toP and Swin(17)
else(18)
P signs Tdelivery with skP(19)
P broadcasts Tdelivery(20)
end ifAlgorithm3 describes the process of tracking the origin of fakes in SESCF. Similarly, we define a primitive to complete the traceability: Trace.Trace. Using a unique Gid to identify the goods can achieve traceability. In Section 4.3, we have introduced Gid and id_set. Once a problem is found with the goods, the user can scan the RFID to obtain the unique Gid and id_set. The goods information contained in Tdelivery is stored on the blockchain so that users can locate the corresponding Tdelivery and further locate the supplier of the problem goods according to Gid and id_set.Algorithm 3:Trace() for user Ni.
(1)
trace:Ni scans the RFID tag of the goods(2)
Ni inputs Gid and id_set(3)
total := id_set.length +1(4)
num = 0(5)
for tx.Txtype = txstop and num = total do(6)
if Gid = tx.Goodsj.Gid or id_set.id =  tx.Goodsj.Gid then(7)
send tx toNi(8)
num++(9)
end if(10)
end for


## 5.3. Capital Flow

Algorithm4 describes the process of solving payment defaults in the supply chain. Specifically, after Swin broadcasts Ttender, a payment channel C < P, Swin> with a time lock of T3 is opened between P and Swin immediately. We define three primitives to complete the payment: Open channel, Payment, and Close channel. Here, txhash refers to Ttender’s hash value.Open channel. In the open channel stage, P releases the coins not less than the order price into the channel, and Swin releases the coins not less than LD into the channel. As well as, the time lock is set to T3. Finally, both parties use their private keys to sign the channel C < P, Swin>. The role of the time lock is to set the latest closing time of the channel. In simple terms, after T3, if C < P, Swin> is not closed yet, it will automatically close, at the same time, the coins in the channel are redistributed and submitted to the blockchain.Payment. In the payment stage, P pays SwinPD after the channel is opened. If Swin fails to deliver to P before T3, he will pay LD to P automatically through the smart contract at T3. On the contrary, if Swin successfully delivers to P before T3, P will pay Swin the balance through the smart contract.Close channel. After successful delivery beforeT3, P or Swin applies for closing the payment channel. If C < P, Swin> has not been closed at T3, it indicates that Swin failed to deliver before T3; then Swin pays LD to P. P and Swin sign off C < P, Swin> and submit the balance of their coins to the blockchain.Algorithm 4:Payment() for P and Swin.
(1)
open channel: P inputs (open, C < P, Swin>, Swin)(2)
Smart contract sends (C < P, Swin>, txhash) to Swin(3)
P inputs CoinP to C < P, Swin>(4)
P.account :=  CoinP(5)
assertCoinP> txhash.price(6)
Swin inputs CoinS to C < P, Swin>(7)
Swin.account := CoinS(8)
assertCoinS> txhash.LD(9)
t := tx.hash.T3(10)
P and Swin sign C < P, Swin>(11)
payment: after P and Swin sign the channel(12)
P pays txhash.PD to Swin(13)
P.account := P.account—txhash.PD(14)
Swin.account :=  Swin.account + txhash.PD(15)
ifSwin did not deliver the goods before tthen(16)
Swin pay txhash.LD to P(17)
P.account := P.account + txhash.LD(18)
Swin.account := Swin.account—txhash.LD(19)
else(20)
txhash.balance :=Swin.price—txhash.PD(21)
P pay txhash.balance to Swin(22)
P.account := P.account − txhash.balance(23)
Swin.account := Swin.account + txhash.balance(24)
end if(25)
P or Swin call to close channel(26)
close channel: on input (close, C < P, Swin>, txhash) from P and Swin(27)
P.wallet := P.wallet + P.account(28)
Swin.wallet := Swin.wallet + Swin.account(29)
P and Swin sign off


## 6. Evaluation

In this section, we first discuss the assumptions of SESCF and use simulation tools to prove the feasibility of the smart contracts. Then we implement an efficient blockchain-based supply chain system. Our system runs on the Windows operating system. Finally, we give a comparison between SESCF and the existing blockchain-based supply chain frameworks.


### 6.1. Simulation and Results

We test the smart contracts proposed in this paper in the simulation mode. Specifically, we use Remix, MetaMask, and Ganache to test the feasibility and performance of smart contracts. Remix is the official online integrated development environment (IDE) of Ethereum. The Solidity language can be used to complete the online development, compilation, testing, deployment, debugging, and interaction of Ethereum smart contracts in the web page. Ganache provides virtual users with a certain number of virtual cryptocurrencies. Through the visual interface, users can intuitively set various parameters, browse, and view accounts and transaction data. MetaMask is a Chrome plug-in, so it is very convenient to use it to complete transfer and other operations in the browser. The specifications of the system are as follows: Intel Core i7-10510U, 2.4 GHz processor, 16 GB RAM, and 500 GB storage.Ethereum stipulates two accounts: ordinary accounts and smart accounts. For ordinary transfer transactions, that is, calling ordinary accounts, the required gas is a fixed2.1×104. However, if users call smart accounts, the required gas is different because the complexity of the smart contracts is different. The more resources the transaction takes up, the more gas is required. Following are the performances we tested to evaluate the proposed solution: (i) the gas cost required to deploy smart contracts, (ii) the total amount of gas consumed by different numbers of nodes on the competitive bidding mechanism, (iii) the total amount of gas consumed by different quantities of goods when inspecting the quality of goods, and (iv) the total amount of gas consumed by different numbers of transactions when tracing goods.Figure6 shows the gas consumption of the four smart contracts deployed in SESCF. As we can see from the figure, the Competitive bidding() consumes the most gas and the Inspect() consumes the least gas. In Ethereum, gas needs to be converted into ETH for payment. Here, we set gas price = 1 Gwei = 10−9 Eth, and then, the total cost of deploying smart contracts is 7.69×10−3 Eth.Figure 6
The gas cost required to deploy smart contracts.In Figure7, the amount of gas consumed by different numbers of suppliers in the competitive bidding mechanism is shown. The competitive bidding mechanism consists of three functions, i.e., Tender(), Bid(), and Compute(). In SESCF, as the number of suppliers increases, the resources (calculation, memory, etc.) occupied during bidding also increase. It is obvious in the histogram that as the number of supplier nodes increases, the more gas is required to run the smart contract. In addition, the Bid() function consumes the maximum amount of gas for execution and transaction as compared to the other functions because the Bid() function not only needs to encrypt bids but also needs to calculate and verify π.Figure 7
The total amount of gas consumed by different numbers of nodes on the competitive bidding mechanism.In the delivery stage,P needs to perform quality inspection on the goods first. Figure 8 shows the amount of gas consumed by different numbers of goods in the Inspect() function. Through a large number of experiments, we have found that the gas consumption in the inspect phase is proportional to the number of goods, that is, as the number of goods increases, the more gas is required.Figure 8
The total amount of gas consumed by different numbers of goods when inspecting the quality of goods.To compare the number of transactions in SESCF with the amount of gas required for tracing goods, we add different numbers of transactions in SESCF for testing. The results are shown in Figure9. We stipulate in the smart contract Trace() that once the transactions are queried, it will stop running. Therefore, the gas consumed by the Trace() function is not only related to the number of transactions in SESCF but also related to the ID of the block where the goods is located. However, by drawing these histograms, we concluded that more transactions in SESCF will cost more than fewer transactions.Figure 9
The total amount of gas consumed by different numbers of transactions when tracing goods.


### 6.2. Construction and Results

The experimental results in the previous section show that the smart contracts we proposed are feasible. Next, we develop an efficient blockchain-based supply chain systemSescfDapp. SescfDapp runs on the Windows operating system, and it is implemented using the C++ language. Furthermore, we assume that no entity on the network has enough computing power to destroy more than half of the network nodes, and only registered entities can buy and sell goods in SescfDapp.First, the user runsSescfDapp and then enters the port number and selects the identity on the login interface. After the login is successful, SescfDapp automatically obtains the current user’s IP address and generates a pair of a public key and private key and initializes a wallet for the user. Next, SescfDapp sends the user’s IP address, port number, identity, and public key to the CA for verification. If the verification is successful, the system will receive a certificate binding IP address, port number, identity, and public key. But in our simplified supply chain system, the CA server verification step is omitted. Therefore, we consider the IP address, port number, and public key as certificates.After the user logs inSescfDapp, the home page displays the IP, port number, and identity of the user. Further, he can operate on the competitive bidding, inspect, trace, and payment pages. It is worth noting that nodes have only three different identities: supplier, producer, and retailer. Following are the running times of SescfDapp. We proved the efficiency of SescfDapp by analyzing them.Figure10 shows the time cost on the competitive bidding mechanism. We provide different numbers of nodes in SescfDapp and run multiple times to study the impact on bidding time cost. It is clearly visible from the graph that the Compute() function consumes the maximum amount of time cost for execution as compared to the Tender() function. This is because the Compute() function not only needs to broadcast the calculation result to Si but also needs to perform decryption and logically complex operations. The Tender() function only needs to broadcast Ttender to Si. Therefore, the time cost of Tender() is relatively low. When running the Bid() function, we found that the average running time of bidding for a user is 3.08×10−1 seconds. The execution time of the Bid() function mainly includes two parts: (i) the time for Si (i ∈1, …, N) to send eprice and π and the size of each proof π is 1.25 MB; (ii) the time for the smart contract to verify π.Figure 10
Time cost of tendering and computing.We first open a payment channel betweenP and Swin in SescfDapp and perform the payment operations. We observe that the channel can be opened between any two users in SescfDapp, and it only takes 4 ×10−2 seconds to make a payment operation on the path of P and Swin. This greatly reduces the overhead on the blockchain.In Figure11, the time cost on inspecting and tracing goods in the logistics phase is shown. We test the changes in the execution time of the Inspect() function as the number of goods increased, and the changes in the execution time of the Trace() function as the number of transactions increased. It is observed from experiments that the Inspect() function is less affected by the number of goods. When the number of goods reaches 106, the running time of Inspect() is only 1.99×10−1 seconds. However, the Trace() function is greatly affected by the number of transactions in the system. When the number of transactions is 1, the running time of Trace() is 10−3 seconds, but when the number of transactions is 106, its running time reaches 3.45 seconds.Figure 11
Time cost of inspecting and tracing goods.As time goes on, there will be more and more nodes inSescfDapp, resulting in more and more transactions. According to the experimental results, (i) the number of nodes affects the time cost of Tender() and Compute(), but when the number of nodes reaches the order of millions, the running time of Tender() is only 7.44 × 10−1 seconds and that of Compute() is 4.78 seconds, and (ii) the number of transactions affects the time cost of Trace(). When the number of transactions reaches the order of millions, it can be observed that the running time of Trace() is 3.45 seconds. The above time is sufficient for the provenance scenario.


### 6.3. Comparison

In Table1, we give a comparison between SESCF and the existing blockchain-based supply chain systems in terms of functionalities [14, 23, 25, 29]. Although current work uses blockchain to solve problems in the supply chain, most research work has focused on only one aspect of the supply chain. As we know, the supply chain is a complex system consisting of information flow, logistics, and capital flow. Therefore, we first proposed an efficient supply chain framework based on blockchain, which guarantees the fairness and security of the information flow, logistics, and capital flow of the supply chain at the same time. In addition, we compare the efficiency of SESCF and Scheme [23]. In comparison, we only consider primary operations with significant overhead and ignore operations with low complexity.Table 1
Functionality comparison.
FunctionalitySESCFMondal et al. [14]Zhang et al. [23]Tian et al. [25]Cui et al. [29]Symmetry of demand information✓✕✕✕✕Quality inspection✓✓✕✕✕Traceability✓✓✓✕✓Payment✓✕✕✕✕We implement Scheme [23] based on SescfDapp. Figure 12 indicates the evaluation of the quality inspection and traceability function in the experiment. As we can see, the quality inspection time of both schemes increases as the number of goods and SESCF achieves more optimized performance. Both two schemes must check whether the parameters of the goods meet the requirements of production indexes. Scheme [23] needs to verify the current node information first and then upload and package the goods information. Meanwhile, SESCF does not need to perform these operations.Figure 12
The performance comparison of the time cost of inspecting and tracing goods.It should be noted that the goods ID is unique in both schemes. For the traceability function, the difference between the two schemes is the way to search usingID. Scheme [23] needs to traverse all transactions, while SESCF sets a keyword total, that is, when the number of query results equals to total, the smart contract will terminate. As a result, SESCF is faster for the same number of transactions. The difference in their efficiency has become more and more evident as the number of transactions increases.


## 6.1. Simulation and Results

We test the smart contracts proposed in this paper in the simulation mode. Specifically, we use Remix, MetaMask, and Ganache to test the feasibility and performance of smart contracts. Remix is the official online integrated development environment (IDE) of Ethereum. The Solidity language can be used to complete the online development, compilation, testing, deployment, debugging, and interaction of Ethereum smart contracts in the web page. Ganache provides virtual users with a certain number of virtual cryptocurrencies. Through the visual interface, users can intuitively set various parameters, browse, and view accounts and transaction data. MetaMask is a Chrome plug-in, so it is very convenient to use it to complete transfer and other operations in the browser. The specifications of the system are as follows: Intel Core i7-10510U, 2.4 GHz processor, 16 GB RAM, and 500 GB storage.Ethereum stipulates two accounts: ordinary accounts and smart accounts. For ordinary transfer transactions, that is, calling ordinary accounts, the required gas is a fixed2.1×104. However, if users call smart accounts, the required gas is different because the complexity of the smart contracts is different. The more resources the transaction takes up, the more gas is required. Following are the performances we tested to evaluate the proposed solution: (i) the gas cost required to deploy smart contracts, (ii) the total amount of gas consumed by different numbers of nodes on the competitive bidding mechanism, (iii) the total amount of gas consumed by different quantities of goods when inspecting the quality of goods, and (iv) the total amount of gas consumed by different numbers of transactions when tracing goods.Figure6 shows the gas consumption of the four smart contracts deployed in SESCF. As we can see from the figure, the Competitive bidding() consumes the most gas and the Inspect() consumes the least gas. In Ethereum, gas needs to be converted into ETH for payment. Here, we set gas price = 1 Gwei = 10−9 Eth, and then, the total cost of deploying smart contracts is 7.69×10−3 Eth.Figure 6
The gas cost required to deploy smart contracts.In Figure7, the amount of gas consumed by different numbers of suppliers in the competitive bidding mechanism is shown. The competitive bidding mechanism consists of three functions, i.e., Tender(), Bid(), and Compute(). In SESCF, as the number of suppliers increases, the resources (calculation, memory, etc.) occupied during bidding also increase. It is obvious in the histogram that as the number of supplier nodes increases, the more gas is required to run the smart contract. In addition, the Bid() function consumes the maximum amount of gas for execution and transaction as compared to the other functions because the Bid() function not only needs to encrypt bids but also needs to calculate and verify π.Figure 7
The total amount of gas consumed by different numbers of nodes on the competitive bidding mechanism.In the delivery stage,P needs to perform quality inspection on the goods first. Figure 8 shows the amount of gas consumed by different numbers of goods in the Inspect() function. Through a large number of experiments, we have found that the gas consumption in the inspect phase is proportional to the number of goods, that is, as the number of goods increases, the more gas is required.Figure 8
The total amount of gas consumed by different numbers of goods when inspecting the quality of goods.To compare the number of transactions in SESCF with the amount of gas required for tracing goods, we add different numbers of transactions in SESCF for testing. The results are shown in Figure9. We stipulate in the smart contract Trace() that once the transactions are queried, it will stop running. Therefore, the gas consumed by the Trace() function is not only related to the number of transactions in SESCF but also related to the ID of the block where the goods is located. However, by drawing these histograms, we concluded that more transactions in SESCF will cost more than fewer transactions.Figure 9
The total amount of gas consumed by different numbers of transactions when tracing goods.


## 6.2. Construction and Results

The experimental results in the previous section show that the smart contracts we proposed are feasible. Next, we develop an efficient blockchain-based supply chain systemSescfDapp. SescfDapp runs on the Windows operating system, and it is implemented using the C++ language. Furthermore, we assume that no entity on the network has enough computing power to destroy more than half of the network nodes, and only registered entities can buy and sell goods in SescfDapp.First, the user runsSescfDapp and then enters the port number and selects the identity on the login interface. After the login is successful, SescfDapp automatically obtains the current user’s IP address and generates a pair of a public key and private key and initializes a wallet for the user. Next, SescfDapp sends the user’s IP address, port number, identity, and public key to the CA for verification. If the verification is successful, the system will receive a certificate binding IP address, port number, identity, and public key. But in our simplified supply chain system, the CA server verification step is omitted. Therefore, we consider the IP address, port number, and public key as certificates.After the user logs inSescfDapp, the home page displays the IP, port number, and identity of the user. Further, he can operate on the competitive bidding, inspect, trace, and payment pages. It is worth noting that nodes have only three different identities: supplier, producer, and retailer. Following are the running times of SescfDapp. We proved the efficiency of SescfDapp by analyzing them.Figure10 shows the time cost on the competitive bidding mechanism. We provide different numbers of nodes in SescfDapp and run multiple times to study the impact on bidding time cost. It is clearly visible from the graph that the Compute() function consumes the maximum amount of time cost for execution as compared to the Tender() function. This is because the Compute() function not only needs to broadcast the calculation result to Si but also needs to perform decryption and logically complex operations. The Tender() function only needs to broadcast Ttender to Si. Therefore, the time cost of Tender() is relatively low. When running the Bid() function, we found that the average running time of bidding for a user is 3.08×10−1 seconds. The execution time of the Bid() function mainly includes two parts: (i) the time for Si (i ∈1, …, N) to send eprice and π and the size of each proof π is 1.25 MB; (ii) the time for the smart contract to verify π.Figure 10
Time cost of tendering and computing.We first open a payment channel betweenP and Swin in SescfDapp and perform the payment operations. We observe that the channel can be opened between any two users in SescfDapp, and it only takes 4 ×10−2 seconds to make a payment operation on the path of P and Swin. This greatly reduces the overhead on the blockchain.In Figure11, the time cost on inspecting and tracing goods in the logistics phase is shown. We test the changes in the execution time of the Inspect() function as the number of goods increased, and the changes in the execution time of the Trace() function as the number of transactions increased. It is observed from experiments that the Inspect() function is less affected by the number of goods. When the number of goods reaches 106, the running time of Inspect() is only 1.99×10−1 seconds. However, the Trace() function is greatly affected by the number of transactions in the system. When the number of transactions is 1, the running time of Trace() is 10−3 seconds, but when the number of transactions is 106, its running time reaches 3.45 seconds.Figure 11
Time cost of inspecting and tracing goods.As time goes on, there will be more and more nodes inSescfDapp, resulting in more and more transactions. According to the experimental results, (i) the number of nodes affects the time cost of Tender() and Compute(), but when the number of nodes reaches the order of millions, the running time of Tender() is only 7.44 × 10−1 seconds and that of Compute() is 4.78 seconds, and (ii) the number of transactions affects the time cost of Trace(). When the number of transactions reaches the order of millions, it can be observed that the running time of Trace() is 3.45 seconds. The above time is sufficient for the provenance scenario.


## 6.3. Comparison

In Table1, we give a comparison between SESCF and the existing blockchain-based supply chain systems in terms of functionalities [14, 23, 25, 29]. Although current work uses blockchain to solve problems in the supply chain, most research work has focused on only one aspect of the supply chain. As we know, the supply chain is a complex system consisting of information flow, logistics, and capital flow. Therefore, we first proposed an efficient supply chain framework based on blockchain, which guarantees the fairness and security of the information flow, logistics, and capital flow of the supply chain at the same time. In addition, we compare the efficiency of SESCF and Scheme [23]. In comparison, we only consider primary operations with significant overhead and ignore operations with low complexity.Table 1
Functionality comparison.
FunctionalitySESCFMondal et al. [14]Zhang et al. [23]Tian et al. [25]Cui et al. [29]Symmetry of demand information✓✕✕✕✕Quality inspection✓✓✕✕✕Traceability✓✓✓✕✓Payment✓✕✕✕✕We implement Scheme [23] based on SescfDapp. Figure 12 indicates the evaluation of the quality inspection and traceability function in the experiment. As we can see, the quality inspection time of both schemes increases as the number of goods and SESCF achieves more optimized performance. Both two schemes must check whether the parameters of the goods meet the requirements of production indexes. Scheme [23] needs to verify the current node information first and then upload and package the goods information. Meanwhile, SESCF does not need to perform these operations.Figure 12
The performance comparison of the time cost of inspecting and tracing goods.It should be noted that the goods ID is unique in both schemes. For the traceability function, the difference between the two schemes is the way to search usingID. Scheme [23] needs to traverse all transactions, while SESCF sets a keyword total, that is, when the number of query results equals to total, the smart contract will terminate. As a result, SESCF is faster for the same number of transactions. The difference in their efficiency has become more and more evident as the number of transactions increases.


## 7. Security Analysis

In this section, we first introduce the vulnerability and security issues of smart contracts which allow malicious users to exploit smart contracts. Then, how SESCF is resilient against these attacks is proposed.


### 7.1. Vulnerability and Attack

As we all know, blockchain data are secure and immutable, and the enforceability of the code on smart contracts makes it impossible for accounts to be breached. Moreover, the use of smart contracts can update in real time and reduce human intervention to improve the efficiency of the supply chain. However, if there are security bugs in smart contracts, the adversary can manipulate the execution of smart contracts to gain profit. As a result, the security of the entire system will be undermined. Here, we introduce several vulnerabilities in smart contracts which are proposed in paper [40]: Transaction-Ordering Dependence (TOD), Timestamp Dependence, Mishandled Exceptions, and Reentrancy Vulnerability.Transaction-Ordering Dependence is a bug that may be exploited by malicious users. Usually, it takes some time for a transaction to be broadcasted and packaged in a block. Assume that an attacker A monitors the transaction of the corresponding contract in the network and then immediately sends a transaction to change the current contract status. By doing so, the later-released transaction may be ranked before the first-released transaction. For example, A submits a prize-winning quiz contract Cquiz and a transaction TXa that promises to give generous rewards, allowing other nodes to find the correct answer. After submitting Cquiz and TXa, A continues to monitor the network to see if anyone submits the transaction TXb with the correct answer. Once someone submits TXb, A immediately submits a transaction TXc that reduces the bonus before TXb is confirmed. Moreover, A provides a higher gas so that TXc is processed by the miner first. Finally, when the miner processes TXb, the bonus becomes extremely low, and A can get the correct answer almost for free.Ethereum stipulates that when a miner packs a new blockb1, if b1’s timestamp is greater than b0’s and the difference between the timestamps is less than 900 seconds, b1’s timestamp is also legal. Timestamp Dependence means that the execution of smart contract depends on the current block’s timestamp. Different timestamps will result in different execution results of the contract. Assuming the following scenario, there is a lottery contract Clottery that requires a value n to be calculated from the current timestamp and other variables which can be known beforehand. Moreover, Clottery indicates that participants with the same number as n will receive prizes. While mining a block, A tries different timestamps in advance to calculate n, so as to give prizes to the designated participants.In Ethereum, smart contractC1 can call another contract C2 through the send() command. If an exception is thrown in C2 (low battery or call stack limit exceeded, etc.), C2 is terminated. However, exceptions in C2 may not be propagated to C1. The above are Mishandled Exceptions. For example, A intentionally exceeds the depth limit of the call stack to attack smart contracts. It is stated that the implementation of the Ethereum Virtual Machine limits the depth of the call stack to 1024 frames. Moreover, if C1 calls C2, the depth of the call stack increases by one. So, A submits a smart contract Cstack and calls itself 1023 times and then sends the transaction to Bob. In doing so, A ensures that Bob’s call stack depth reaches 1024, which causes Bob to fail to send instructions.Reentrancy Vulnerability, just as its name implies, is that the adversary can repeatedly enter the smart contract. In Ethereum, smart contracts can call other external contracts’s codes. Consider the following contract that sends ETH to an external address. This function requires calling the code of the external contract. At this time, by hijacking external calls, A can repeatedly enter the transfer() function of the contract to transfer funds.


### 7.2. Security Proof

In terms of the four attack methods mentioned in Section7.1, this section proposes security theorems to prove that SESCF is secure and effective.Theorem 1.
SESCF does not rely on Transaction-Ordering.Proof.
In SESCF,P submitted Ttender and reached an agreement with Swin through a competition mechanism. The probability of reducing Swin’s contract rewards by releasing another transaction to change the current contract status is nearly impossible. On the one hand, Ttender is cosigned by P and Swin and broadcasted by Swin. On the other hand, once Ttender is broadcast, C < P, Swin > is opened immediately. P is required to release coins not less than Ttender.price, and Swin is required to release coins not less than Ttender.LD into C < P, Swin >. Furthermore, P and Swin will automatically pay Ttender.PD, Ttender.balance, and Ttender.LD according to Swin’s delivery status.Theorem 2.
SESCF does not rely on the timestamp of block.Proof.
In the competition mechanism,P selects the supplier with the lowest bid price as Swin by comparing S1.price, ⋯, SN.price. Consequently, there is no situation in which P selects a designated supplier for a transaction by continuously calculating the block’s timestamp. In addition, the bids of S1, …, SN are encrypted by pkP, so that the bids of S1, …, SN are independent of others’.Theorem 3.
SESCF does not cause Mishandled Exceptions and Reentrancy Vulnerability.Proof.
The exception in the callee’s contract is not propagated to the caller can cause Mishandled Exceptions. Besides, in Ethereum, when a contract calls another contract, the current transaction waits for the call to finish. This issue can lead to Reentrancy Vulnerability when a transaction makes use of the intermediate state of the caller. It is quite clear that these two bugs are caused by calls. In SESCF, Competitive bidding(), Inspect(), Trace(), and Payment() are independent of each other, i.e., there is no calling relationship between them.


## 7.1. Vulnerability and Attack

As we all know, blockchain data are secure and immutable, and the enforceability of the code on smart contracts makes it impossible for accounts to be breached. Moreover, the use of smart contracts can update in real time and reduce human intervention to improve the efficiency of the supply chain. However, if there are security bugs in smart contracts, the adversary can manipulate the execution of smart contracts to gain profit. As a result, the security of the entire system will be undermined. Here, we introduce several vulnerabilities in smart contracts which are proposed in paper [40]: Transaction-Ordering Dependence (TOD), Timestamp Dependence, Mishandled Exceptions, and Reentrancy Vulnerability.Transaction-Ordering Dependence is a bug that may be exploited by malicious users. Usually, it takes some time for a transaction to be broadcasted and packaged in a block. Assume that an attacker A monitors the transaction of the corresponding contract in the network and then immediately sends a transaction to change the current contract status. By doing so, the later-released transaction may be ranked before the first-released transaction. For example, A submits a prize-winning quiz contract Cquiz and a transaction TXa that promises to give generous rewards, allowing other nodes to find the correct answer. After submitting Cquiz and TXa, A continues to monitor the network to see if anyone submits the transaction TXb with the correct answer. Once someone submits TXb, A immediately submits a transaction TXc that reduces the bonus before TXb is confirmed. Moreover, A provides a higher gas so that TXc is processed by the miner first. Finally, when the miner processes TXb, the bonus becomes extremely low, and A can get the correct answer almost for free.Ethereum stipulates that when a miner packs a new blockb1, if b1’s timestamp is greater than b0’s and the difference between the timestamps is less than 900 seconds, b1’s timestamp is also legal. Timestamp Dependence means that the execution of smart contract depends on the current block’s timestamp. Different timestamps will result in different execution results of the contract. Assuming the following scenario, there is a lottery contract Clottery that requires a value n to be calculated from the current timestamp and other variables which can be known beforehand. Moreover, Clottery indicates that participants with the same number as n will receive prizes. While mining a block, A tries different timestamps in advance to calculate n, so as to give prizes to the designated participants.In Ethereum, smart contractC1 can call another contract C2 through the send() command. If an exception is thrown in C2 (low battery or call stack limit exceeded, etc.), C2 is terminated. However, exceptions in C2 may not be propagated to C1. The above are Mishandled Exceptions. For example, A intentionally exceeds the depth limit of the call stack to attack smart contracts. It is stated that the implementation of the Ethereum Virtual Machine limits the depth of the call stack to 1024 frames. Moreover, if C1 calls C2, the depth of the call stack increases by one. So, A submits a smart contract Cstack and calls itself 1023 times and then sends the transaction to Bob. In doing so, A ensures that Bob’s call stack depth reaches 1024, which causes Bob to fail to send instructions.Reentrancy Vulnerability, just as its name implies, is that the adversary can repeatedly enter the smart contract. In Ethereum, smart contracts can call other external contracts’s codes. Consider the following contract that sends ETH to an external address. This function requires calling the code of the external contract. At this time, by hijacking external calls, A can repeatedly enter the transfer() function of the contract to transfer funds.


## 7.2. Security Proof

In terms of the four attack methods mentioned in Section7.1, this section proposes security theorems to prove that SESCF is secure and effective.Theorem 1.
SESCF does not rely on Transaction-Ordering.Proof.
In SESCF,P submitted Ttender and reached an agreement with Swin through a competition mechanism. The probability of reducing Swin’s contract rewards by releasing another transaction to change the current contract status is nearly impossible. On the one hand, Ttender is cosigned by P and Swin and broadcasted by Swin. On the other hand, once Ttender is broadcast, C < P, Swin > is opened immediately. P is required to release coins not less than Ttender.price, and Swin is required to release coins not less than Ttender.LD into C < P, Swin >. Furthermore, P and Swin will automatically pay Ttender.PD, Ttender.balance, and Ttender.LD according to Swin’s delivery status.Theorem 2.
SESCF does not rely on the timestamp of block.Proof.
In the competition mechanism,P selects the supplier with the lowest bid price as Swin by comparing S1.price, ⋯, SN.price. Consequently, there is no situation in which P selects a designated supplier for a transaction by continuously calculating the block’s timestamp. In addition, the bids of S1, …, SN are encrypted by pkP, so that the bids of S1, …, SN are independent of others’.Theorem 3.
SESCF does not cause Mishandled Exceptions and Reentrancy Vulnerability.Proof.
The exception in the callee’s contract is not propagated to the caller can cause Mishandled Exceptions. Besides, in Ethereum, when a contract calls another contract, the current transaction waits for the call to finish. This issue can lead to Reentrancy Vulnerability when a transaction makes use of the intermediate state of the caller. It is quite clear that these two bugs are caused by calls. In SESCF, Competitive bidding(), Inspect(), Trace(), and Payment() are independent of each other, i.e., there is no calling relationship between them.


## 8. Conclusion

We proposed SESCF, a secure and efficient supply chain framework. As far as the authors’ knowledge, it is the first system to guarantee the fairness and security of information flow, logistics, and capital flow in the supply chain system simultaneously by exploiting blockchain. Due to space limitation, since the scenario between retailers and producers is similar to that between producers and suppliers, only the latter has been illustrated in this paper. Specifically, we provided the algorithm flow and discussed the smart contracts in detail. Moreover, simulation was performed, and the results showed that the deployment and execution of SESCF only requires a certain amount of gas, which indicates the feasibility of SESCF. Based on this, we developed an efficient blockchain-based supply chain systemSescfDapp. In the end, we evaluated SESCF and proved that it is robust and secure for entities acting maliciously.In this paper, we put multiple types of transactions in a single chain. In reality, this may reduce the search efficiency. It is an interesting problem how to extend our framework into a multichain structure, that is, we will consider putting different types of transactions on different side chains in the future. By doing so, not only the search efficiency but also the system throughput will be improved.



---

*Source: 8884478-2021-01-15.xml*