Skip to end of metadata
Go to start of metadata

Currently, data received from vinduinos and sensor stations is being stored in a DB service. Vinduinos and sensor stations send the data collected to Bravo node (10.112.48.22) where the DB is allocated (PostgreSQL 8.3.x server). This database is used by the website (costaflores.com) to display the data for the user to check. A structure similar to the one shown in the following figure:

With this proposal I want to change this strucuture in order to replace the database with a Side Chain (Ethereum private network) solution. This proposal will integrate the database part of the project into the blockchain, and thanks to that, this project is going to based on a full-blockchain backend (not really common). Having a full-blockchain backend contributes highly to transparency and immutability. As OpenVino is an open-vineyard, transparency is crucial. The new structure is going to follow this structure (extended description of internal side chain design in the 'Blockchain storage proposal'):
Apart from that, this migration will also allow the future introduction of the validator figure, explained in the initial 'Blockchain storage proposal'. Adding this figure will increase the value of the project by giving the opportunity to:
  1. Prove that data collected and stored is correct and no negligence is committed during the sensor to bravo communication.
  2. Control that data stored has no outlier and that everything is working correctly during the Growing the grapes process.
  3. Add a new feature to allow users interaction with the vineyard via and App that leads them to improve their wine and blockchain knowledge.
 
This initial proposal will only include the part of storing the data in the blockchain. This decision was made because after making a first approach to the problem with the 'Blockchain storage proposal', I have realised that there might be several problems when it comes to using Blockchain as a Database because it is not as optimized as an SQL DB and this could lead to a slower response time which is undesirable. So in this first step of the Side Chain Development, I'm going to implement the data storage part of the side chain solution and load tests are going to be executed in order to check if the system proposed response time is acceptable or not. In case of not being acceptable a second iteration is going to be done adding a DB to store utility indexes in order to reduce the response time of queries and searches and other optimizations.
 
For this project to be done, a private Ethereum Network and a Database Server (in case of reaching the second iteration) must be given.  The raspberry in charge of inserting data to the blockchain will have to own a pair of private/public keys. I will also need a clear specification of the data extracted with the sensors and its treatment. Communication with the website development team might be necessary in order to make both developments fit.
 
After having finished the first part of the proposal, a blockchain database system will have been deployed and documentation for its integration with the sensors/vinduinos and the website will be given. Once finished and accepted, the validation part of the Side Chain proposal will begin (defined as a new project). This part might alter the first smart contracts given but a full migration will be included and previous functionalities won't be changed.
 
The development of this Side chain data storage feature is being started today and tomorrow it is planned to have already defined the requirements. Communication with team members might be necessary in order to establish quality and performance requirements.

1 Comment

  1. I have posted this without being authenticated. If you have any questions, do not hesitate to contact me.

Write a comment…