# Towards Blockchain-Based Federated Machine Learning: Smart Contract for Model Inference
## 5 Discussion  
Our implementation is partially related to [7] as they use similar deployment principles and the Hyperledger Fabric network. Authors of [7] implement the model validation using chaincode and do not employ the oracle service. Even though ML can be completed without the oracle services, we believe that these services hold potential to improve the ecosystem of ML on private blockchains, since they unlock the flexibility to use programming languages which are not supported by Hyperledger Fabric. Communication with real-world API from the chaincode is a well-known source of failure in decentralized blockchain applications, and recently some solutions emerged, such as Band Protocol [39] or Hyperledger Avalon [40]. Hyperledger Avalon differs from our proposed solution by allowing many different blockchain technologies, such as Ethereum, Hyperledger Fabric, or Hyperledger Sawtooth, to use various oracles. These oracle components are trusted and centralized, whereas our solution deploys an oracle service instance for each peer existing on the blockchain network. Having oracle service implementation on each participating node eliminates the need to access trusted real-world information outside the network. Expecting identical computation results (in our case, predictions from the ML model) regardless of the node is sufficient. These node-based oracle instances do not degrade the network security level [41] and allow reducing the communication latency. The services for model inference in the Hyperledger Fabric infrastructure could also be deployed by some orchestration entity existing in each organization. The entity would manage updates and would ensure that the organization's peers use the same version of the oracle service. Any mismatch in versions could lead to a failure state in which peers would not be able to reach consensus. Some standard procedures should be provided for new peers joining the network and peers rejoining the network, such as updating and setting up of the oracle service. During the development process, we explored more than one development environment and discovered that the performance of the model inference depends on the peer's storage type, as it impacts the state database performance. Consequently, the hard disk drive storage used during the development performed way slower compared to the solid-state drive used in the reported experiments. A drawback of our approach is that benchmarking was executed in a virtual environment and not on a network of physical computers. Even though experiments were conducted on a single virtual server using Docker containers for network simulation, the explored architecture is mostly restricted to communication between the smart contract and oracle service over a local connection (the oracle service is running on a localhost). Thus, in a more realistic scenario, additional network latency would be introduced only to maintain that the blockchain network is synchronized, irrespective of the choice between oracle service and chaincode implementations. We assume performance to be the most important factor for choosing between the oracle and chaincode solution. The blockchain architecture provides additional properties, such as scalability, privacy, auditability, decentralization, etc. In addition to performance, the implemented solution's scalability was partially assessed by benchmarking network configurations of various sizes. The other properties, such as privacy, auditability, or decentralization, were not experimentally assessed since these properties are inherent to the Hyperledger Fabric platform and are not directly affected by the alternatives compared. The performed experiments demonstrated that an increase in the dataset size results in diminishing differences between implementation alternatives, and we assume that a similar tendency would hold when switching from a simple to a more complex ML model. For expanding experiments to cover more models, slight modifications of model data structure and smart contract execution logic would be needed.