**This work was done as part of the Course work by Author: Abdyukov Z.M. **
Brief introduction
Development tools and Programming Language
Prototype architecture
Optimization contract
Some problem and TODO:
View Prototype
The main goal of the work is to develop the architecture and prototype of a system of decentralized interaction between doctors and patients.
The scientific novelty of the work lies in the fact that a new approach to the interaction of the patient with doctors is proposed.
When a medical record is generated and signed, it can be recorded in the blockchain, which gives patients proof and confidence that the record cannot be changed. These personal medical records can be encoded and stored on the blockchain using a private key so that they are accessible only to certain individuals, thereby ensuring confidentiality.
Smart contracts can make data accessible and transparent to both patients and doctors by working as a gatekeeper who manages who is given access to information.
The Interplanetary File System (IPFS) can be considered as a peer-to-peer distributed file system that seeks to connect all computing devices into a single file system.
For Smart Contract, i used Solidity and IDE Remix, also Personal Blockchain Ganache
For Web-Site, used HTML/CSS/JS and NodeJS (express,body-parser,browserify,dotenv,ejs,ejs-mate,express-fileupload,ganache,ipfs-core,ipfs-http-client,node-abort-controller,web3,web3-eth),
npm install -S express body-parser browserify dotenv ejs ejs-mate express-fileupload ganache ipfs-core ipfs-http-client node-abort-controller web3 web3-eth
Node v13.14.0 ,
npm v6.14.4
Interaction patient with doctor
Interaction Doctor with patient's contract
Interaction patient with contract
The developed prototype works with two contracts, with the contract of the patient (Patient) and the contract that interacts with the contract of the patient (addPatient). The patient contract stores and processes data about a particular patient, and the patient does not have direct access to this contract. The second contract allows the patient to interact with the patient contract. Thus, each patient will have his own separate contract.
Since each patient has his own personal contract, it puts a lot of pressure on the system and is quite an expensive operation. In this regard, the concept of "Clone Factory" from OpenZepplin is used, this library allows you to reduce the load on the system and reduce costs. It turns out this is due to the fact that the library works in the Assembly language, which directly works with memory. The essence of the library is that the patient's contract is first deployed, and then the main contract, which will create clones. Clones simply refer to the functions of the parent, thereby reducing their volume and increasing the processing speed, while each clone stores its own patient data
The contract also contains a function that converts an integer to a string. This function requires optimization, since the cost is high for large numbers, and the larger the number, the higher the cost (for example, for 9997779 the cost is 42676 gas). After the translation of the function into the Assembly language, the cost of the function has significantly decreased and with an increase in the number, it does not increase significantly (for example, for the same number the cost is already equal to 24576 gas and with an increase in the number, the cost increases by only a few hundred, against several thousand)
The rest of the functions in the contract were not translated into the Assembly language significantly, since the Assembly language requires more time to learn, and the Solidity developers do not recommend using it often, due to the fact that, quoting from the Solidity language developers this is a way to access the virtual machine Ethereum is at a low level and this drops several important security features of Solidity.”"
The first problem is the limited size of the contract. The developers of the Ethereum network and smart contracts have limited the size of contracts, which does not allow adding a lot of functionality. The maximum contract size is 24576 bytes, you can also use the built-in optimizer, but they also have a "too deep stack" limit of no more than 16 local variables. This was done in order to prevent DDos attacks. It is also possible to optimize the contract if it is translated into the Assembly (Assembler) language, but the developers strongly do not recommend it, since in this case there is work with memory, as a result of which it can cause problems in the Ethereum network. As a result, a smart contract can only be used with little functionality and a limited number of checks in the contract itself.
The second problem is that the contract is too expensive. The write functions are not expensive, but the display functions have nested loops, which greatly increases the price of the contract. So, for example, displaying one diagnosis costs 35,000 gas, if there are already two, then 70,000 gas. But I also note that the Ethereum network switched to “ProofOfStake” in the fall of 2022, perhaps next year the cost of computing will fall, and the contract will become cheaper.
The third problem is file storage. About 75 million people use cloud storage. Part of the campaign, another part uses intentionally, and still others only indirectly. The rest may not know about it, because there is simply no need. IPFS, on the other hand, is still a very young technology that requires development, testing and implementation to the masses (for example, a default installation along with the OS). As a result, the use of IPFS as a storage is not very advisable in the near future, since in addition to those mentioned above, there are few users, and, therefore, the data will be loaded for a long time, and the receipt can also be long.
Also, the developed application is only partially decentralized, as it works on the basis of a central node - a server. For an application to be fully decentralized, the contract must be published to IPFS and the application deployed to a distributed file system. Only in this case, the dependence on the central node will disappear and the application will be truly decentralized.
Cost(gas): Contract Creation (Patient) - 4764952, (addPatient) - 2224094 ,
Register - 362839,
Show BaseInfo - 58385, Show all diagnosis - 248218, Show history - 246536
-
- Contract optimization: learn Solc and apply
-
- WebSite optimization (the main page slows down)
-
- WebSite: remove jQuery (only used for slider), manually create slider
-
- Test on large volumes of data
-
- In case of successful solution of the problems above, create an Android App
MAIN PAGE
Prototype.mp4
Chapter Patient
Chapter Doctor
Show Base info
Check connect: circle is check connect with wallet, check mark is connect with contract
Register Form
Success Register
Success access
Set diagnosis Form
Info diagnos
History
