## 4 Need for Transparency of the Robotic System
\begin{table}
\begin{tabular}{p{56.9 pt} p{113.8 pt} p{113.8 pt} p{113.8 pt}} \hline \hline
**Requirements** & **Motivation** & **Current State** & **Possible Solution** \\ \hline Network and Storage Security & So that remote access storage do not least user data. & During the remote access, available standard IPSec security mechanisms would be adopted, and to protect the robotic system, a proxy system would be in place. In addition, storage security e.g., encryption is available; however, there is no mechanism to protect from tampering, deletion, etc., by attackers or unintentional actions by authentic users, etc. & A private permission based blockchain system would be designed. It would be designed in such a way that the blocks will not hold the data, but only parameters necessary to detect and identify any changes to the actual data, so that the resource hungry blockchain does not degrade the robotic performance. Moreover, the storage framework should not lead to a single point failure either. & A private permission based blockchain system would be designed. It would be designed in such a way that the blocks will not hold the data, but only parameters necessary to detect and identify any changes to the actual data, so that the resource hungry blockchain does not degrade the robotic performance. Moreover, the storage framework should not lead to a single point failure either. & A private permission based blockchain system would be designed in such a way that the blocks will not be developed in such a way that the system is easily adoptable and usable. It should also be easy to integrate with the assistive robotic system, so that the overheads do not degrade the response time and performance of the robotic system. Moreover, the data should be stored encrypted, and visibility should be controlled based on the needs and rights of the users and the third party service providers, such as the engineer, nurse, doctors etc. \\ \hline \hline \end{tabular}
\end{table} 
Table 2: _Cont._to make it computationally efficient, and optimise energy and storage utilisation, while preserving user's privacy during the data collection or communication or storage process. It would be computationally effective if raw data is not stored in the blocks of the blockchain. A great deal of multimedia information would be collected during user and robotic interaction, and such an approach would reduce the computational overhead. 1. The data collected from the user, ambient environment of the user, health, and raw or processed wellbeing data, etc., are all collected and securely stored within the robotic system. All data are timestamped, and an ID is assigned. Only authorised users with the correct credentials can access the data and the level of access would depend upon the access priority and access rights provided by the user, or as required by the care provider or the maintenance team or supervisor. 2. A private BC system could be built among the robot, user's PC/PCs, and cloud storage. However, the BC would not store any raw data or encrypted data; rather it would store only the 'Merkle tree', a hash of the transaction, timestamp, and unique ID of each transaction. This way, there would be no concerns about the data leakage or visibility in the BC network. It will, thus, preserve the user's privacy in the BC system; even if hackers get into the BC system of the cloud or the PC of the user, no data would be visible. However, the stored encrypted data in the robot would be synced with the BC system that runs in the robot, the user's PC, and the cloud, so that every activity of the robot is transparently captured in the BC system. 3. In order to maintain consistency and preserve the integrity of the BC system, a proof of stake (PoS) consensus algorithm approach could be adopted rather than the proof of work (PoW). This is because PoS blocks are assigned to validating nodes rather than miners, solving the hash math problems to validate and update the block, as described in [61].