# Enabling Horizontal Collaboration in Logistics Through Secure Multi-Party Computation
## 5 Extensions and Future Directions
Certain legal obligations (e.g., maximum driving times and mandatory breaks) seems feasible at least on a conceptual level, e.g., by adding the pause times to nextAvailability if the variable exceeds the allowed continuous driving time, or setting nextAvailability\(\leftarrow\infty\) if the maximum driving time is reached, and only selecting trucks with sufficient available driving time for the next order. However, more complex extensions (e.g., requiring that trucks need to be back at their home base in the evening) to be realized in a privacy-preserving setting, while at the same time respecting the optimization goal defined in Equation (1), would be an interesting yet highly challenging research question. Orthogonal to the aforementioned functional extensions, further enhancements regarding the computational efficiency of the current approach could also be investigated. For instance, by simultaneously introducing multiple empty truck drives, the number of iterations of the MPC protocol could be reduced, thereby increasing efficiency. However,introducing multiple such drives at once might lead to a worse average usage factor as defined in Equation (1), and was thus omitted for a fairer comparison with [3]. Yet it might be interesting to precisely quantify the trade-off between the computational efficiency of the MPC solver and the quality of the obtained solution. As explained in Section 4.2, our current solution outputs the number of orders assigned to each haulier to allow for a detection of a systematic bias for or against a specific haulier. Yet, from a more research-oriented point of view, and in the spirit of verifiable MPC [30; 46; 47], it would be interesting to output a cryptographic proof together with the assigned orders, showing that the presented heuristic was properly executed by all nodes, and allowing for public verifiability and auditability of the computation, leveraging primitives such as zero-knowledge proofs of knowledge (ZK-Poks). However, such approaches typically come with significant computational overhead, negatively impacting their practical applicability. Investigating the feasibility and costs could thus be an interesting area for future research. Also related to auditability, yet in an orthogonal sense, the haulier contributing a specific order might have a legitimate interest in learning the executing haulier in case of a contract violation, e.g., because the order was not delivered on time. At the moment, this piece of information is not explicitly output to any entity. Two solutions could easily be integrated at minimal costs into our system. Firstly, the owner of an order receives an additional output indicating the executing haulier. Alternatively, the MPC nodes could locally store their shares of the final assignment of orders to hauliers, and simply reveal this information if some proof of misconduct is submitted by the owner of an order. While additional processes, e.g., clarifying which evidence of misconduct to accept, are needed in this case, it is quite straightforward to implement the computational adjustments needed to maintain an assignment of order identifiers to haulier IDs among the MPC. A final point that should be investigated in subsequent research for practical applicability is the issue of regulations on the protection of confidential data. The CFDP problem does not, per se, involve personal data, and legislation such as the GDPR is therefore out of scope; however, other, possibly sector-specific, regulations might need to be taken into account when using a solution like ours on actual company data.