# Towards Blockchain-Based Federated Machine Learning: Smart Contract for Model Inference
## 3 Methods
### Smart Contract Implementation Details  
In our model inference prototype, two types of stakeholders exist (Figure 2). The data owner (A1) can upload evaluation data (UC1) to the prototype application, which is used for new model validation and testing of already existing models. The model owner (A2) can upload the model (UC3), which once validated is committed to the blockchain. Additionally, Hyperledger Fabric (A3) participates in all use cases (UC1-4), as an external network, which is responsible for transaction recording. Either type of user acts as a participant during the data or model upload processes, and only after the majority of participants approve the transaction, it is committed to the blockchain. In the model inference solution, federated learning participants can contribute their data and off-chain computed machine learning models for evaluation using the chaincode, which is responsible for the data and model storage. Figure 1: The utilized blockchain architecture: Unified modelling language (UML) component diagram. Chaincode Shim API provides access to data stored in the chaincode state database. Figure 2: The main functionality of the blockchain-based model inference application: UML use case diagram. The data upload procedure (UC1) starts as the user provides a data file. The data file is then checked for the.csv data file format and whether the provided data columns are of the expected format and correspond to the outlined data structure. If the provided file is valid, the data is inserted into the Hyperledger's data storage by recording each data row. After the evaluation data are uploaded, the models already committed to the blockchain are tested (UC2). Since the model is already uploaded, it is safe to assume that the model during this process gets tested, as the possibility that the model was trained on the newly uploaded data is quite low. After the testing, the ML model results are appended according to the new model inference computations for newly inserted data records. The model upload procedure (UC3) starts in the same way, but rather than a data file, a user is asked to provide the ML model file. It is important to note, that the ML model is trained by the model owner and is not included in the scope of the model inference prototype application. The submitted file contains logistic regression coefficients, these again are checked whether the data are of an appropriate format and structure. Afterwards, an ML model validation process is initiated (UC4). We present chaincode specification fragments of the ML model validation process in more detail. The provided class and sequence diagrams (Figures 3 and 4) describe the essential parts which should be recorded in the smart contract execution code. The class diagram (Figure 3) outlines the smart contract functions, their parameters, and types. The classes that participate in the smart contract execution are presented as lifelines in the sequence diagram (Figure 4). Using the behaviour and the structure recorded in these diagrams, a source code can be produced which would facilitate the process of development. Several specification patterns are described in UML diagrams (Figures 3 and 4) and were used to produce the source code (Figure 5) for this federated learning solution. 1 funcvalidateModel(stubshim.ChaincodeStubInterface,modelModel)pb.Response{
2 vardata[]DataWrapper
3 dataJson,err:=getValidationData(stub)
4 iferr!=nil{
5 returnshim.Error(err.Error())
6}
7 json.Unmarshal((dataJson),&data)
8 varpredictions[]float64
9 fori:=0;i<len(data);i++{
10 prediction:=calculatePrediction(data[i],model)
11 predictions=append(predictions,prediction)
12}
13 initResults(stub,model,predictions)
14 returnshim.Success(nil)
15}  
Model validation (Figure 2 UC4) begins after the model is uploaded to the blockchain (Figure 2--UC3). Once the _validateModel_ function is called, a new instance of the DataWrapper array is created.