# Enabling Horizontal Collaboration in Logistics Through Secure Multi-Party Computation
## 4 Toward an MPC-Based Solution for the CFDP
### Description of Our Solution  
This subsection discusses our MPC solution to the CTN described in the previous sections in a way that is as agnostic as possible of the MPC protocol (and software) that can be used to instantiate and implement it. We will therefore only assume that an MPC solution is available that can turn secret values \(x\) into \"scrambled\" values \([x]\); for simplicity, one can think of a secret-sharing process as described in Section 2.1, where \([x]=(x_{1},\ldots,x_{n})\) is the collection of shares. It is assumed that sum- and multiplication gates can be securely evaluated on scrambled values, and that a value \(y\) can be reconstructed from its scrambled version \([y]\) if all parties holding shares of \(y\) cooperate. Moreover, we also assume that a scrambled value \([x]\) can be reconstructed either publicly, meaning that all MPC parties will obtain the value of \(x\), or to a single party, meaning that other parties will obtain no information whatsoever on \(x\); this is a standard property of many MPC protocols. The first step consists of scrambling the data related to orders and trucks; this means that the owner of each order Order \(=\) (orderID, (origin, dest), VOL, \(\bot\)) will ensure that all data (except for the haulier value, which is unassigned at this point) is scrambled, hence obtaining \([\textsc{Order}]=([\textsc{orderID}],([\textsc{origin}],[\textsc{dest}]),[ \textsc{vol}])\). Similarly, each haulier will scramble the truck data, and also initialize a \"destination\" variable dest to the unassigned value \(\bot\), hence obtaining \([\textsc{Truck}]=([\textsc{haulierID}],[\textsc{position}],[\textsc{dest}],[ \textsc{capacity}])\); notice that there is no need to scramble (or share in any other way) the truck identifier. Finally, the map data is assumed to be public. In the following we now describe the main steps of our solution; the interested reader can refer to our implementation ([[https://github.com/ait-crypto/MUPOL-MPC](https://github.com/ait-crypto/MUPOL-MPC)]([https://github.com/ait-crypto/MUPOL-MPC](https://github.com/ait-crypto/MUPOL-MPC)) (accessed on 30 June 2025)) for additional implementation-specific details. We assume that a number of fundamental building blocks are available in the MPC framework used:  
* A secure non-exclusive OR subroutine that, on input two scrambled bits \([x],[y]\), outputs \([x\lor y]\). For simplicity, we denote this OR operation on scrambled values with \(\lor\)* A secure-equality sub-routine, i.e., an MPC sub-routine eq that takes as input two scrambled integers \([x],[y]\) and outputs a scrambled bit \([b]\) where \(b=1\) if \(x=y\), and 0 otherwise. * A secure comparison sub-routine, i.e., an MPC sub-routine greater_eq that takes as input two scrambled integers \([x],[y]\) and outputs a scrambled bit \([b]\) where \(b=1\) if \(x\geq y\), and 0 otherwise. * A secure if-else subroutine, i.e., an MPC sub-routine if_else that takes as input a scrambled bit \([b]\) and two scrambled values \([x],[y]\), and outputs \([x]\) if \(b=1\) and \([y]\) if \(b=0\). * A secure sorting sub-routine, i.e., an MPC sub-routine sort that takes a list of scrambled values \(L:=\left(\left[x^{(1)}\right],\ldots,\left[x^{(\ell)}\right]\right)\) as input, with \(x^{(i)}\in\mathbb{N}\) for all \(i\), and outputs a permutation \(\left(\left[x^{(i_{1})}\right],\ldots,\left[x^{(i_{\ell})}\right]\right)\) of \(L\) where \(x^{(i_{j})}\leq x^{(i_{j+1})}\) for all \(j\). Note that these basic functionalities are common to most modern generic MPC frameworks such as MPyC or MP-SPDZ [41]. Our solution now consists of two core components:  
fill_truck. The sub-routine fill_truck (Sub-routine 1) takes as input an order and a truck and checks whether the order can be processed by this truck.