add e-2-e example

applications/decentral_ml.md

@@ -187,7 +187,7 @@ Here are key publications in the field of decentralised federated machine learni
 | ------: | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | **0a.** | License                      | APACHE 2                                                                                                                                                                                                                     |
 | **0b.** | Documentation                | We will provide both a **Gitbook with basic tutorial** and **inline documentation** of the code that explains how a user can (for example) work with governance and stake against a model and how the client interface works. |
-| **0c.** | Testing and Testing Guide    | Comprehensive unit tests to ensure core functionality and robustness of code. Instructions on how to run the  tests will be included.                                                              |
+| **0c.** | Testing and End-to-end (e2e) Testing Guide    | Comprehensive unit tests to ensure core functionality and robustness of code. Instructions on how to run the  tests will be included. End-to-end federated learning test  using the MNIST dataset for classification                                                              |
 | **0d.** | Docker                       | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.                                                                                                                |  |  |  |
 | **0e.** | Robust Incentivisation Scheme                       | In response to the feedback received, we will implement a random role assignment mechanism as part of our example game logic. We also see the value in having some flexibility in role assignments, similar to the VBFL paper. This will be configurable using the strategy pattern, thereby addressing the "game theory" concerns. As in the VBFL paper, at every communication round, each device will be randomly appointed as one of the three roles defined as follows: (1) "Data Contributors" can occasionally take on the role of "machine learning worker," as described in the VBFL paper. (2) The role of "model validator" will be an extension of our existing validation processes. This role will employ advanced validation techniques like k-fold and stratified sampling to ensure the integrity and accuracy of model training. This role can be dynamically assigned as with the "machine leanring worker" and "blockchain miner" roles, adding an extra layer of robustness. (3) The "blockchain miner" role will be responsible for incorporating validated models into the blockchain.  |  |  |  |
 |      1. | Collective Economy      | We plan to establish governance mechanisms related to the selection and training of models, specifically for Data Annotators and Model Engineers.<br/><br/>For Model Engineers, we will implement the following logical methods:<br/><br/>1. listMasterModels: This method returns a report listing the modelGUID, modelName, usageType, usageTypeCost, and costTokenAccept.<br/> 2. getMasterModels(licenseUsage, quantityOfPaymentCoins): This method takes the type of usage and the payable amount for that usage, returning the master model. It operates on an element of trust, with users expected to pay the appropriate amount based on the associated licensing (MIT, Apache, etc. defined on-chain for the model). While we don't anticipate this being a problem for this grant, future releases may include more sophisticated whitelists or permissions.<br/> 3. listModelEngineers(modelGUID): This method returns a list of Model Engineer (ME) wallet addresses approved to call the collectiveApprovesModel method.<br/> 4. modelEngineerUpdate(modelGUID, model, senderWalletAddress): Anyone can send their version of the model, which will be stored on-chain for review and approval. We may add more permissions to this method but the idea is to keep it as open as possible.<br/> 5. listModelEngineerUpdates(modelGUID): This method returns a report listing the senderWalletAddress, model version, block number, and updateID.<br/> 6. collectiveApprovesModel(updateID, collective member or MC sender address, reward percentage:0-1): This method approves the model to replace the "Master" model and awards the Model Engineer a percentage (defined in the parameter 0-1) from the Model Engineer pool.<br/>7. addCollectiveMember(modelGUID, walletAddress): This method adds collective members to the approval list so updates to the model by MEs can be approved. Future expansions may support issues like jurisdiction, licensing, usage, as well as parameter settings for algorithm selection and more.<br/><br/>For Data Annotators, we will implement similar logical methods:<br/><br/>1. `uploadDataForAnnotation(image, text, sound, testQuestionnaire:questionText, answerType, questionId, answerPoints:numberPointsRewarded, batchParameters)`: This method allows collective members to provide data that requires annotation. The solution design records the answer types as columns and the questions as rows, enabling a wide variety of annotation questions to be modelled depending on the model requirement.<br/>2. `getDataAnnotationQuestionnaire(modelGUID)`: This method returns a list of required data annotations and associated questionnaire information with data types as columns, offering flexibility to build a wide variety of dApps that could harness and offer various rewards to DAs.<br/>3. `submitDataAnnotationForReward(modelGUID, questionId, answer)`: This method implements a simple validation test for the submitted annotated data, with the potential for more sophisticated game theory algorithms to validate DA submissions in the future.<br/>4. `reportDataAnnotationAwards(modelGUID)`: This method returns a report of pending and allocated rewards.