- : Ms Word, Ms Word Format
- : 70 Pages
- : ₦3,000 | $25 | ₵60 | Ksh 2720
- : 1-5 Chapters
- Click to DOWNLOAD Materials
BLOCKCHAIN SMART CONTRACTS IN MEGACITY LOGISTICS
Abstract
Megacities are becoming a major focus of the global economy, with almost 70% of the world population expected to live in megacities by the year 2050. Logistics is the lifeblood of megacities and retailers need to find efficient and less expensive logistics systems.
This thesis proposes a system of blockchain peer-to-peer smart contracts built with Hyperledger, to build a megacity grocery supply chain where retailers, suppliers, and logistics providers can bid directly for contracts, analyze market trends, trace product flow for food safety, and reduce costs by cutting out the middlemen. A blockchain can supplement or take the place of centralized fourth party logistics providers and reduce the layers of middlemen in the supply chain by connecting suppliers, retailers, and Third Party Logistics Providers (3PLs) directly. The blockchain also provides a distributed ledger that all participants would have a copy of and can contribute to without repudiation.
The decentralization inherent in the blockchain can allow smaller, independent contractors to be more competitive, increase efficiency by reducing the layers of middlemen, and reduce the costs of technology adoption for access to information. Smaller suppliers can be aggregated and matched to retailers through volume orders without a middleman. Logistics providers could be crowdsourced individual contractors that could be called upon anytime for small or rush deliveries, much like how rides can already be hailed on sharing economies such as Uber and Lyft.
In terms of traceability, the cost of sharing data between all participants could be significantly reduced, food safety issues can be mitigated as soon as they are detected, blame would be less likely to fall on the wrong party, and counterfeit products would be impeded by their lack of provenance on the blockchain. Megacities that have to cope with reduced warehouse space, greater demand for direct/fresh delivery will need improvements like these to sustain their growth.
Contents
List of Figures ix
List of Abbreviations xi
List of Terminology xiii
Acknowledgments xv
Chapter 1
Introduction 1
1.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Summary of Work and Contributions . . . . . . . . . . . . . . . . . 2
1.2.1 Key Possibilities . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Limitations of the Blockchain . . . . . . . . . . . . . . . . . 4
1.3 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Chapter 2
Problem Definition 7
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 The Procurement Problem . . . . . . . . . . . . . . . . . . . 8
2.1.2 The Multiple Levels of Logistics Providers . . . . . . . . . . 10
2.1.3 The Paperwork Problem . . . . . . . . . . . . . . . . . . . . 11
2.2 The Applicability of the Blockchain . . . . . . . . . . . . . . . . . . 12
2.2.1 Choosing the Type of Blockchain for the Problem . . . . . . 12
2.2.2 Relevance of the Blockchain to the Supply Chain . . . . . . 13
2.2.3 Applying Permissionless and Permissioned Blockchains to
the Supply Chain . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.4 Infrastructure Needs and Costs of the Blockchain . . . . . . 15
2.3 The Blockchain and Smart Contracts . . . . . . . . . . . . . . . . . 17
2.3.1 Three Combined Applications of Permissionless and Permissioned Blockchains . . . . . . . . . . . . . . . . . . . . . 18
Chapter 3
Background 21
3.1 Supply Chain Theory . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.1 Megacity Logistics . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.2 Types of Supply Chain Inefficiencies . . . . . . . . . . . . . 22
3.1.3 Logistics Provider Models . . . . . . . . . . . . . . . . . . . 22
3.1.4 Distributed and Collaborative Logistics Planning and Replanning under Uncertainty . . . . . . . . . . . . . . . . . . 24 3.1.4.1 The Procurement Problem . . . . . . . . . . . . . . 24
3.1.4.2 Satapathy’s Research Objectives . . . . . . . . . . 26
3.1.4.3 Types of Supply Chains . . . . . . . . . . . . . . . 27
3.1.4.4 Master and Servant Problem Solving Model . . . . 28
3.1.4.5 Workflow . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 A Sharing Economy for the Supply Chain with eHarvestHub . . . . 31
3.2.1 The Current State of Supply Chain Middlemen . . . . . . . 32
3.2.2 Sources of Markups and Inefficiency . . . . . . . . . . . . . . 33
3.3 Foundational Concepts of the Blockchain . . . . . . . . . . . . . . . 34
3.3.1 Bitcoin: A Peer-to-Peer Electronic Cash System . . . . . . . 36
3.3.1.1 The Byzantine Generals’ Problem . . . . . . . . . . 37
3.3.1.2 The Distributed Ledger and the Double Spending
Problem . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1.3 The Proof-of-Work Algorithm . . . . . . . . . . . . 39
3.3.1.4 Unspent Transaction Outputs . . . . . . . . . . . . 42
3.3.1.5 Merkle Trees and Simplified Payment Verification . 42
3.3.1.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . 43
3.3.2 Smart Contracts . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.3 The Bitcoin Blockchain as a State Transition System . . . . 45
3.3.4 Applications of Alternative Blockchain State Transition Func-
tions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.4.1 Independent Blockchain . . . . . . . . . . . . . . . 47
3.3.4.2 Colored Coins and Metacoins . . . . . . . . . . . . 49
3.3.5 The Ethereum Blockchain . . . . . . . . . . . . . . . . . . . 50
3.3.5.1 Smart Contracts: Arbitrary State Transition Func-
tions . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.5.2 Ethereum Mining Algorithm . . . . . . . . . . . . . 52
3.3.5.3 Ethereum in Practice . . . . . . . . . . . . . . . . . 53
3.3.6 Permissioned/Consortium Blockchain Methodology . . . . . 54
3.3.6.1 Hyperledger Sawtooth . . . . . . . . . . . . . . . . 56
3.3.6.2 Sawtooth Consensus Algorithms . . . . . . . . . . 57
3.3.7 Application Paradigms in the Blockchain . . . . . . . . . . . 58
3.3.7.1 Characteristics of the Blockchain . . . . . . . . . . 58
3.3.7.2 Generic Application Patterns . . . . . . . . . . . . 59
3.3.8 Security and Practicality Concerns . . . . . . . . . . . . . . 60
3.3.8.1 The Blockchain Approach to Ledger Security . . . 61
3.3.8.2 Smart Contract Bugs and Oversights . . . . . . . . 62
3.3.8.3 Reliance on Network Conditions and Health . . . . 64
Chapter 4 Related Work 67
4.1 Literature Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.2 Formal Papers and Theses . . . . . . . . . . . . . . . . . . . . . . . 69
4.2.1 Blockchain in Megacity Logistics . . . . . . . . . . . . . . . 69
4.2.2 Aiming for Supply Chain Transparency: Exploring the Potential of Blockchains . . . . . . . . . . . . . . . . . . . . . . 70
4.2.3 The Supply Chain has No Clothes . . . . . . . . . . . . . . . 71
4.2.3.1 Achieving Transparency and Traceability in the
Supply Chain . . . . . . . . . . . . . . . . . . . . . 72
4.2.4 Distributed Ledger for Supply Chains . . . . . . . . . . . . . 73
4.3 General and Informal Knowledge . . . . . . . . . . . . . . . . . . . 74
4.4 Smart Contract Applications . . . . . . . . . . . . . . . . . . . . . . 74
4.4.1 Initial Coin Offerings: Tokens that do Things . . . . . . . . 75
4.4.1.1 World Food Program: Cryptovoucher Case Study . 77 4.4.2 Hyperledger: Seafood Supply Chain Traceability . . . . . . . 79
Chapter 5 Methodology 80
5.1 Marketplace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.2 Logistics Matchmaking . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.3 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.3.1 Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.3.1.1 Build-to-Order Products . . . . . . . . . . . . . . . 86
5.3.1.2 Build-to-Plan Products . . . . . . . . . . . . . . . 87
5.3.2 Order Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.3.3 Geography . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.3.4 Transportation Costs . . . . . . . . . . . . . . . . . . . . . . 89
5.3.5 Additional Modules . . . . . . . . . . . . . . . . . . . . . . . 89
5.4 Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.4.1 Geography and Time . . . . . . . . . . . . . . . . . . . . . . 91
5.5 Modeled Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.6 Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.7 Computations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Chapter 6 Implementation 97
6.1 Balancing Data Confidentiality and Public Traceability . . . . . . . 98
6.2 Hyperledger Composer Overview . . . . . . . . . . . . . . . . . . . 99
6.2.1 Business Network Archive . . . . . . . . . . . . . . . . . . . 100
6.2.2 Hyperledger Business Network Templates . . . . . . . . . . . 101
6.3 Model Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.3.1 Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.3.2 Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.4 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.4.1 Product Marketplace . . . . . . . . . . . . . . . . . . . . . . 102
6.4.2 Shipping Inquiry . . . . . . . . . . . . . . . . . . . . . . . . 103
6.4.3 Logistics: Shipping Ceremony . . . . . . . . . . . . . . . . . 104
6.5 Product Bidding Transactions . . . . . . . . . . . . . . . . . . . . . 105
6.5.1 createProduct Create a Product . . . . . . . . . . . . . . . 105
6.5.2 Offer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.5.3 CloseBidding . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.6 Contract Bidding Transactions . . . . . . . . . . . . . . . . . . . . . 106
6.6.1 createContract Create a Contract for a SOLD Product . . 106
6.6.2 Bid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.6.3 CloseInquiry: Execute the Contract . . . . . . . . . . . . . 107
6.7 Shipment Transactions . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.7.1 CreateShipment Begin a Shipment for a Contract that is READY_FOR_PICKUP . . . . . . . . . . . . . . . . . . . . . . . 108
6.7.2 Dock: Shipper Informs Possessor of Arrival . . . . . . . . . . 108
6.7.3 HandOff: Change Product Possession to Shipper . . . . . . . 108
6.7.4 PickUp: Confirm Product Possession and Move Out . . . . . 109
6.7.5 Arrive: Record Shipper Arrival at Retailer . . . . . . . . . 109
6.7.6 TemperatureReading: Record Temperature Reading (Shipper) 109
6.7.7 ShipmentReceived: Record Shipment Reciept (Retailer) . . 110 6.8 Access Control Rules . . . . . . . . . . . . . . . 110
Chapter 7 Results and Conclusions 112
7.1 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.1.1 Food Traceability . . . . . . . . . . . . . . . . . . . . . . . . 112
7.1.2 eHarvestHub: A Marketplace to connect Grocers, Truckers, Farmers Directly . . . . . . . . . . . . . . . . . . . . . . . . 113
7.1.2.1 Future Expansions for eHarvestHub . . . . . . . . 114
7.1.3 Value-added Products: A Story Told by the Blockchain . . . 115
7.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.3 Future Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.3.1 Possible Expansions of this Implementation . . . . . . . . . 118
7.3.1.1 eHarvestHub Collaboration . . . . . . . . . . . . . 118
7.3.1.2 Broadcast a Shopping List with IoT Fridges . . . . 118
7.3.1.3 The Blockchain as a Data Source . . . . . . . . . . 118
7.3.2 The Unified Theory of Acceptance and Use of Technology . 119 7.3.3 Ontology Driven Supply Chain Provenance . . . . . . . . . . 122
Appendix A Implementation Model Definitions 124
A.1 Product Negotiation Assets . . . . . . . . . . . . . . . . . . . . . . 124
A.2 Perishable Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Appendix B Additional Online Sources 132
B.1 Videos Watched . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
B.1.1 Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
B.1.2 Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
B.1.3 Hyperledger . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
B.1.4 Blockchain Overview Videos . . . . . . . . . . . . . . . . . . 133
B.1.5 Development . . . . . . . . . . . . . . . . . . . . . . . . . . 133
B.2 Organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
B.3 Foundational Papers . . . . . . . . . . . . . . . . . . . . . . . . . . 134
B.4 Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
B.5 Overview Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 135
B.6 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
B.7 Tutorials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
B.8 Code Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
B.9 Courses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Bibliography 138
List of Figures
| 2.1 | The procurement problem as defined by Satapathy (Satapathy 1999). | 9 |
| 2.2 | Flowchart based on info from GSA and Johansson’s 2018 thesis for deciding which type of blockchain to use. (Herman 2018), (Johansson | |
| 2018) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | 12 | |
| 2.3 | The methodology applied by this thesis to use the blockchain to | |
| solve the procurement problem. . . . . . . . . . . . . . . . . . . . . | 14 | |
| 3.1 | The procurement problem as defined by Satapathy (Satapathy 1999). | 25 |
| 3.2 | Master and Servant Agent Interaction as defined by Satapathy | |
| (Satapathy 1999). . . . . . . . . . . . . . . . . . . . . . . . . . . . . | 29 | |
| 3.3 | A fundamental concept of cryptography is given as the top bullet, and the fundamental concepts of the blockchain that it helps explain | |
| is given as the subbullets (Johansson 2018, p. 9). . . . . . . . . . . | 35 | |
| 3.4 | A transaction on a block of a blockchain’s distributed ledger (Limited | |
| 2018). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 | ||
3.5 The Merkle Tree as implemented in the blockchain. Where root[i+1] .signature = hash(concatenate(root[i] .toString(),block[i] .toString())) (Limited
| 2018). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6 The state transition function of Bitcoin in pseudocode (Buterin, |
44 |
| Wood, et al. 2018). . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7 An example of a Domain Name digital asset in the Ethereum Serpent |
45 |
| language (Buterin, Wood, et al. 2018): . . . . . . . . . . . . . . . .
3.8 A smart contract as arbitrary state transition code embedded in a |
49 |
| block on the blockchain (Limited 2018). . . . . . . . . . . . . . . . .
5.1 How a Marketplace can aggregate volume from small suppliers without a middleman. Credits to Alvaro Ramirez of eHarvestHub |
50 |
| for assisting with this diagram. . . . . . . . . . . . . . . . . . . . . | 82 |
5.2 How Logistics Providers can be matched to retailers without a middleman. Credits to Alvaro Ramirez of eHarvestHub for assisting
with this diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.3 How Logistics Providers handle and report the delivery on the blockchain. Assistance by Alvaro Ramirez. . . . . . . . . . . . . . . 85
5.4 A possible idealized city grid for the scenario. . . . . . . . . . . . . 88
5.5 What type of smart contracts could be created and which agents interact with each other using them. . . . . . . . . . . . . . . . . . 96
6.1 Hyperledger Composer Playground Development Environment (Hyperledger Foundation 2018[c] ). . . . . . . . . . . . . . . . . . . . . . 99 6.2 Hyperledger Composer Playground Business Networks (Hyperledger
Foundation 2018[c] ). . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7.1 The TOVE Ontology in simple form. (Kim and Laskowski 2016) . . 123 7.2 An example of a TRU trace in a Coffee Supply Chain. (Kim and
Laskowski 2016) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
List of Abbreviations
1PL First Party Logistics Provider. 22,
2PL Second Party Logistics Provider.
3PL Third Party Logistics Provider. iii, 1, 2, 5, 23–25,
4PL Fourth Party Logistics Provider. 1, 2, 5, 23,
AI Artificial Intelligence.
API Application Programming Interface.
ASIC Application-Specific Integrated Circuit. 52, 53,
BTO Build-to-Order. 86,
BTP Build-to-Plan. 87,
CPU Central Processing Unit. 52, 53,
CRVR Collaborative Robust Vehicle Route.
DAO Decentralized Anonymous Organization.
DApp Decentralized Application.
DNS Domain Name System. 47, 48,
ERC Ethereum Request for Comment.
EVM Ethereum Virtual Machine. 50, 53,
GPU Graphics Processing Unit. 52,
ICO Initial Coin Offering. 67, 75–77, IPO Initial Public Offering. 75, 76, IT Information Technology.
KQML Knowledge Query and Manipulation Language.
LC Late Customization.
P2P Peer-to-Peer.
PDP Stochiastic Pickup and Delivery Problem.
PoW Proof-of-Work.
RAM Random Access Memory. 53, REST Representational State Transfer.
RFID Radio-Frequency Identification Tag.
SHA Secure Hash Algorithm. 40, 52,
SPV Simplified Payment Verification. 43, 49,
TOVE Toronto Virtual Enterprise project. x, 122, 123, TX Transaction.
UML Unified Modeling Language.
UTAUT Unified Theory of Use and Acceptance of Technology.
UTXO Unconfirmed Transaction Output. 42, 45–47, 58,
List of Terminology
Bitcoin The definitive cryptocurrency as developed by Satoshi Nakamoto (Nakamoto 2008), and the distributed ledger technology described in its whitepaper became known as the blockchain. 35
blockchain A specific type of distributed ledger technology, that uses algorithms on nodes in peer-to-peer networks to reach distributed consensus on a ledger without a trusted third-party. 26
contract As defined in our implementation, a shipping smart contract between a supplier, shipper, and retailer to handoff, transport, and deliver the product for the retailer.. 102
cryptocurrency “A purely peer-to-peer version of electronic cash (that) would allow online payments to be sent directly from one party to another without going through a financial institution” (Nakamoto 2008). 35, 60
distributed ledger A database that is maintained by many participants or across many locations. Consensus is typically guided by a centralized leader or trusted third-party, but the blockchain is an exception.. 26
Ethereum A secure decentralized generalized transaction ledger “that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third-party interference” (Buterin, Wood, et al. 2018). 35, 36
IP address A string identifying a computer on a network that utilizes the Internet
Protocol (IP). 47, 48
logistics provider Transports items between suppliers and retailers (and if necessary, return them to sender). Also referred to variously as Shippers, Transporters, and Third Party Logistics Providers, since although there can be first or second party logistics providers employed by the retailer, this thesis aims to link Third Party Logistics Providers directly to retailers.. 102
permissioned blockchain A specific type of blockchain which enforces settings that restrict which nodes observe, participate, or mine, and what type of the ledger data they can access. Such settings can either be decided up through vote by participating nodes, or by central directive from a single party (likely the code developers). Examples are Hyperledger, JP Morgan’s Quorum, World Food Program’s private Ethereum chain. 35, 55–57, 66
permissionless blockchain A specific type of blockchain which enforces no restriction on participating nodes/miners, and the ledger data they can access. Example are Bitcoin, Ethereum, and most other cryptocurrencies. 55, 58
private permissioned blockchain A specific type of permissioned blockchain with some or all ledger data only verifiable to some or all participating individuals.. 77
product A product to be sold by a supplier to a retailer.. 102
public permissioned blockchain A specific type of permissioned blockchain with some or all ledger data verifiable to the public.. 79
retailer Purchases and receives products, for eventual sale to end customers. Although this process is how this thesis currently conceives of the purchaser, the retailer themselves could possibly be bypassed as the last middleman if customers become comfortable enough buying directly from suppliers.. 102
shipment A derivative asset of the shipping contract, generated when the shipper moves to pick up the product from the supplier. There could possibly be multiple shipments to various different locations, return shipments, or cancelled and renegotiated shipments.. 102
supplier Produces/Procures/Supplies the product for retailers. Could be farmers, food packers, or manufacturers.. 102
Chapter 1
Introduction
Seventy percent of the world population is expected to live in megacities by 2050. Logistics is the lifeblood of megacities, making a modern lifestyle possible, but the increase in population density demands increased efficiency, less waste, and lower costs to ensure the sustainability of this growth (MIT Megacity Logistics Lab 2018). Most grocery stores in megacities depend on multiple Third Party Logistics Providers (3PLs) which trade with suppliers or other 3PLs. However, retailers prefer to deal with a single accountable agent. Thus a centralized Fourth Party Logistics Provider (4PL) (typically the developer of the IT information system) is empowered to manage and audit the activities of the 3PLs.
1.1 Problem
In the procurement problem, a retailer wants a product. Knowing that demand exists, the supplier announces product availability and provides a price quote on the market (Satapathy 1999). The total cost to the retailer is the product price plus the estimated shipping cost.
If the retailer does not agree on the supplier’s price, they begin a negotiation process, where they make an offer or counteroffer several times until they convergence on price. The supplier and retailer agree to the final price, and a contract is signed.
In the current supply chain, negotiations to solve the procurement problem unfortunately do not tend to occur directly between suppliers (farmers), what we will call “independent logistics providers” (truckers), and retailers (grocery stores). Most retailers depend on multiple large Third Party Logistics Providers (3PLs) which trade with suppliers or other 3PLs. However, retailers prefer to deal with a single accountable agent. Thus a centralized Fourth Party Logistics Provider (4PL) (typically the developer of the IT information system) is empowered to negotiate with, audit, and coordinate the supply chain.
Unfortunately, the 4PL forms an additional layer of bureaucracy as a result, and tends to collude with 3PLs against the retailers by exploiting information asymmetry against the retailer (Polim, Hu, and Kumara 2017). The layers of middlemen in the supply chain also incur tremendous costs, inefficiency and waste (Ramirez 2017). Retailers and in turn, end customers pay large markups to middlemen that aggregate supply. If middlemen are ever pressured by retailers to lower costs, costs are eventually pushed down to the farmers and truckers doing the actual work, reducing their growth. And the layers of middlemen in general brings an increased risk of factors that can go wrong, with every transport needed, more warehouses to store in, all adds up to longer lead time and greater risk of spoilage/depreciation (Ramirez 2017).
1.2 Summary of Work and Contributions
This thesis proposes a blockchain peer-to-peer smart contract system for a megacity grocery supply chain where retailers, suppliers, and logistics providers can bid directly for contracts, analyze market trends, trace product flow for food safety, and reduce costs by cutting layers. Although existing centralized systems work well within organizations that provide complete vertical integration in their supply chain, data transfer between incompatible systems tends to be conducted through paperwork or spreadsheets, which is subject to inefficiencies and nearsightedness.
A blockchain can supplement or take the place of centralized fourth party logistics providers and reduce the layers of middlemen in the supply chain by connecting suppliers, retailers, and 3PL directly. The blockchain also provides a distributed ledger that all participants would have a copy of and can contribute to without repudiation. The blockchain makes a peer-to-peer contract system feasible, although it works best when there are multiple groups that have competing interests and need to have a balance of power to ensure trustworthiness. The competing interests of multiple logistics providers and multiple retailers would reduce the chance of collusion especially with more participants.
The main question explored is, “Can we use the blockchain to create a sharing economy for supply chain logistics and contract negotiation, linking retailers, logistics providers, and suppliers directly?” A sharing economy is found in transformative albeit centralized IT examples such as Airbnb and Uber.
Related work on the subject does exist of which important insights are described in Chapter 4, but this thesis differs whereby existing distributed solutions to the procurement problem as described by Satapathy 1999 and Ramirez 2017 are applied to develop a possible methodology for building a blockchain implementation. This methodology simplifies the core components of this blockchain supply chain, but can be extended with modules to fit the needs of more complex megacities.
The implementation explored in this thesis implements both the negotiation and logistics components of the methodology. Due to time limitations, not all aspects of the methodology described previously could be fully explored in this blockchain implementation, such as volume orders, inventory management, logistics provider tracking, or physical IoT devices.
This thesis simply aims to provide a basic code structure using Hyperledger, to show that it is possible for blockchain smart contracts to be applied to the procurement problem. It is left to future researchers and developers to explore further possibilities, test results, or solutions.
1.2.1 Key Possibilities
Supply chain data could be segregated into public transactions for all to view: such as logistics availability, food traceability, and shipment tracking. Some transactions can remain private to participants and authorized observers: such as nearby transporter pricing and price negotiation between suppliers and retailers. Such transactions can still leave behind a hash fingerprint on the public blockchain attesting that an agreement was reached and that there is a legitimate order for logistics providers to depend on, without including price data irrelevant to logistics providers.
Retailers and Suppliers would be able to see directly what the market has paid for transport and supply, and be aware of upcoming shortages. Retailers and Suppliers are incentivized through the ability to make volume orders to aggregate demand, instead of using the additional transport layers of a middleman. The retailer negotiates with one supplier and after accepting a price, makes a volume order to all other suppliers to see if that fits their minimum price. This process can be conducted in a permissioned blockchain, with only matching suppliers negotiating on demand to retailers.
Logistics providers are incentivized by gaining access to the transaction rates retailer purchases so they can match demand as soon as a shortage appears. This process can be conducted in a public blockchain. Smaller logistics providers would no longer have to depend on the whims of a broker, who can be jealously monopolistic with their relations with truckers, and also withholds cost savings from the retailers for their own gain.
From a traceability standpoint, the cost of sharing and querying data between all participants is significantly reduced, food safety issues can be pinpointed and mitigated as soon as they are detected, blame would be less likely to fall on the wrong party, counterfeit products would be impeded by their lack of provenance on the blockchain.
1.2.2 Limitations of the Blockchain
The blockchain still retains some limitations and considerations to be aware of. For one, although technology significantly extends the analysis capabilities of regulators and participants, the data generated is only as good as the people who check on them. Signatures, licensing, and second opinions form the basis of regulation, with paperwork and bureaucracy utilized to ensure compliance and provenance. And it is people that generate these certifications (of visual inspections, sensor) with their honor, livelihood, and reputations on the line. The blockchain allows these attestations to be recorded in an immutable, distributed ledger, but organizations and regulators must continue to maintain the trustworthiness of those signatures and the data. Another consideration that the smart contract code on the blockchain only has jurisdiction over the data in its ledger. Either people have to actually act on the information, incentives, and contracts given, or IoT devices certified by people would have to be set up to take real-world action upon receipt of a blockchain transaction. The blockchain should not be seen as a transcendental technology in bureaucracies, but as the next stage of a gradual evolution in ledgers with real-world enforcement.
The decentralization inherent in the blockchain can allow smaller, independent contractors to be more competitive, increase efficiency by reducing the layers of middlemen, and reduce the costs for them to adopt technology and get access to information (Ramirez 2017). Smaller suppliers can be aggregated and matched to retailers through volume orders without a middleman (Ramirez 2017). Logistics providers could be crowdsourced individual contractors that could be called upon anytime for small or rush deliveries, much like how rides can already be hailed on sharing economies such as Uber and Lyft. Megacities that have to cope with reduced warehouse space, greater demand for direct/fresh delivery will need improvements like these to sustain their growth (Polim, Hu, and Kumara 2017).
1.3 Thesis Outline
Chapter 2 discusses the Problem Definition of this thesis. The chapter starts with a brief introduction of existing information asymmetry between 3PLs and 4PLs. The existence of these layers of middlemen adds complexity, cost, and inefficiencies to the underlying procurement problem. Existing methods developed for eCommerce are applied to tackle the Procurement Problem in the supply chain with direct negotiations or volume orders. The chapter also considers the relevance of the blockchain to the procurement problem, and if so what form it could take. It continues with a discussion on how the potential utilization of blockchains and smart contracts can enforce a more securely and transparently track of contract bidding in a decentralized digital economy. It also considers what form such a blockchain could take.
Chapter 3 provides an in-depth analysis of the Theoretical Background of the procurement problem, the layers of middlemen, the blockchain, and smart contracts.
Chapter 4 explores related work that explores various areas of the issue of
blockchains in the supply chain, as well as the applicability of permissioned blockchain systems in the enterprise in general. The aim is to pick out and synthesize many insights developed by these papers into this thesis, to push the field further.
Chapter 5 considers the methodology of the procurement problem in this thesis, describing the entities involved and the scenario. This methodology is somewhat idealized but provides a good setup for future supply chain implementations to be built upon.
Chapter 6 describes the implementation of our solution to the procurement problem using a proof-of-concept developed with Hyperledger. This implementation does not fully implement the methodology described due to time constraints, but as a proof-of-concept shows that further development is very feasible in terms of
software.
Chapter 7 discusses the case studies that the implementation produced could apply towards, as well as future work worth exploring and a conclusion.
Appendix A contains Hyperledger model code that describe the assets, transactions, and participants involved in our implementation. Additional source code can be found at https://github.com/lvw5264/hyperledger-megacity.
Appendix B contains useful additional online links and videos that provide background knowledge regarding the blockchain.
BLOCKCHAIN SMART CONTRACTS IN MEGACITY LOGISTICS
