# Towards Blockchain-Based Federated Machine Learning: Smart Contract for Model Inference
## 5 Discussion
One potential solution would be to use a compact text-based representation of the ML model file rather than adapting the structure for each specific model. The introduction of a more complex ML model would incur longer model inference runtimes with a relatively smaller communication overhead. Therefore, the marginal differences between alternatives would diminish, even more, thus justifying the choice of oracle for the implementation of the ML model inference logic. In the context of this research, we consider federated learning in a broader perspective than traditional approaches concerned with collecting the ML model updates and integrating them into a global shared model. The blockchain-based network in our case would be used for collective sharing of a small sample of data and models trained on the remaining privately held data. The upload of new unseen data would trigger inference for all the previously uploaded ML models (testing use case) and the upload of the new ML model would trigger its inference for all the previously uploaded data (validation use case). Results of the model inference are then agreed upon by the consensus of network peers and saved permanently in the ledger as a triple of _{ML model ID; data row ID; prediction}_, ensuring that for each possible combination of a shared model and data instance, the recorded model output exists as a prediction verified by the network. Various scenarios to achieve federated learning could co-exist and we could: (a) Upload the traditional ML model (i.e., created using the Python library _scikit-learn_); (b) upload the online ML model (i.e., created using the Python library _creme_); (c) take the existing online ML model from the ledger, train it on individual data, and upload it as a model's new version; (d) propose the meta-model or ML ensemble as a set of weights for the fusion of pre-selected shared models (usual candidates being a few best traditional ML models) through weighted averaging of model-wise predictions. The blockchain network being a back-end, all other tasks of monitoring shared models through tracking of their accuracy by various metrics (log-loss, Kappa, AUC, RMSE, etc.) depending on the supervised ML task (usually, classification or regression) would be fundamental front-end use cases. The envisaged solution encompasses all possible FL scenarios (a-d), supports a wide range of ML models implemented in various libraries and languages (Python, R, MATLAB, Java, Rust, Go, etc. ), and features an intuitive graphical user interface in the form of a client application, which would help monitor how the ledger evolves by tracking all the uploaded data and models (performance metrics need to be recalculated after the new data are uploaded). Additionally, the solution could help peers create any chosen model offline on private data without many hurdles. However, this would need additional API endpoints for model training, bundled alongside the model inference oracle service. Concerns over user data privacy are becoming increasingly important all over the world. This shift in data security also challenges the way ML models are trained and demands techniques to train ML models without the need to share user data or disclose it to a centralized server for processing. Concerns regarding private data protection are serious, especially in such sectors as healthcare or finance. We speculate that the need for privacy-preserving scenarios of ML will continue to grow in demand. While we concentrate on security and immutability aspects of ML, the blockchain technology already provides reliable solutions to log transaction history into the immutable ledger and trace data and model evolution with consistent and verified performance evaluation reached through network consensus.