Page tree
Skip to end of metadata
Go to start of metadata


This proposal is Side Chain approach to storing and validating the collected data. The motivation to take into account this proposal is to increase confidence and trust in the system via external audit and by assuring validity and immutability of the data. It also gives the opportunity to reduce transactional cost when it comes to token transactions.

This solution is basically increasing the value of the project by:

- Increasing confidence. By adding a new figure called validator which is going to be in charge of validating data collected is correct and assuring no negligence is being mentioned.
- Immutability. Solution implies the implementation of a merkle tree (a cryptographic algorithm) which is going to assure immutability of the already validated data.
- Cost reduction. transactions over private Side Chains are cheaper and faster than transactions over the public Main Chain. This leads us to a whole set of cost reduction and availability increment opportunities.


The proposal is structured in three different layers:

  1. Physical layer. This is the tangible layer and it contains the entities that provide the data to the system (vinduinos, weather Station and workers). It also holds the administrator/owner of the system.
  2. Side Chain. This is the transactional and storing layer. It includes the smart contracts and two physical world related entities called executor and validator which will be treated further into this proposal.
  3. Main Chain. This is the security trusted layer. It mantains the real value for the tokens and validity logs (hashes) that assure the content in the Side Chain hasn't been altered.

Physical Layer.

This layer is going to be in charge of introducing the data to the system. In fact, each entity in this layer but the owner must be treated as a datasource.

  • Vinduinos. Vinduinos must send information collected directly to the Side Chain with a given frequency (this frequency will be discussed later on). Each vinduino must have a Side Chain pair of keys in order to transact via its identity allowing contracts to classify correctly the information.
  • Weather Station. It must send information to the Side Chain with a given frequency (this frequency will be discussed later on). This weather station must own a Side Chain pair of keys to allow its identification as.
  • Workers. Workers have to send their task log to the Side Chain via a software (not specified) which must be capable of holding wallets and of transacting with the blockchain. This software will interact with the Side Chain, using the wallet stored, permitting worker identification in the transaction.
  • Owner. This is a special user who is going to be in charge of administrating the Side Chain by:

A. Selecting validators (there might exist a method of auto-selection to avoid any negligence)
B. Executing merkle root updates (main chain data copies too).
C. Executing side chain to main chain transfers (MTB18 tokens).
*) Both B and C are further described in the Side Chain Layer and the Main Chain Layer point.

Side Chain Layer.

This layer is the responsible for validating data, for storing data and for offering a reduced cost transaction option.

  • Validators. Validators are persons who are in charge of validating the data collected is correct. They have no relation with the vineyard. They are working in the validation because they will receive a prize for doing it (similar to what happens with miners). The prize have to be determined, but it can be a quantity of MTB18* tokens based on their amount of work (thats why the contract validators has a register of validation counts for each validator).

  • Executor. The executor is responsible for transmitting data from the Side Chain Layer to the Main Chain Layer and of executing the merkle root updates.

  • Contracts. There are 3 subgroups of smart contracts: (Important: this is just an abstract idea, it is not a full design of a solution. Contracts are not truly specified, it's just the structure what has been taken into account.)

A. Data storage. This smart contracts are used to store the information. They all have a similar structure which contains: a timestamp (time of the transaction), some information (data collected) and a hash generated with the concatenation of the timestamp and the information.

B. Validity and immutability. This package contains three different contracts.

      • Interactors. Contain a description of each type of valid users. This contract will allow us to control permissions over the Side Chain and will also give the possibility of offering users a brief interactor description and its identifier.

      • Validation. It contains a timestamp, a count of validations and a list with the addresses which has already validated that transaction. This contract controls data validity via external audit called validators. Validators are supposed to, every X (time to be determined), validate data collected is correct and transact against this contract to communicate that everything is working OK. A validation of a given timestamp instantly validates previous validation entries. So that: "If V1 validates at 13.59 and V2 validates at 18.00, validation at 13.59 will have been done by V1 and V2 whereas validation at 18.00 will have been done only by V2". Valid data (data storage contracts) will be represented by a lower timestamp than the one in the last validation stored with more than a 50% of validators signs (this percentage may be changed)

      • MerkleTree. Every X time the executor will execute this contract to calculate a merkle root with the following values:

           - The previous merkle root. (1 leaf)
           - The new information appended and validated. (n leaf).

        This will return a hash which will represent the actual state of the information. If some historical values are changed and the merkle root is recalculated the hash will be different and negligence will be detected. As this contract saves the historical value of the merkle root and its timestamp (state at a time), in case of negligence, by recalculating the merkle roots backwards it would be possible to discover at which point this negligence was made and this would prevent from having to delete all the information.

        (merkle-tree.pyMerkle-tree example in python.

C. Token MTB18. This is going to be explained in the Main Chain Layer point.

Main Chain Layer.

This layer is supposed to be hold in the Ethereum Mainchain. The cost of transaction of this network is higher than the transaction cost in the Side Chain where it is negligible. However, this layer is the layer in which the value of the Token is and, in fact, the one with the higher confidence. As a consequence, a copy of the Side Chain Merkle Root Historic is going to be stored in this chain to increase even more the immutability, this opens us another way of action which is to duplicate this data, once it is validated in the SC, into an external database to protect the system in case the Side Chain fails.

  • MTB18. The token already implemented.
  • MerkleCheck. The historical copy of data from the MerkleTreeCheck contract located in the Side Chain.
  • LockMTB18. This is a contract that locks MTB18 Tokens in order to transfer them to the Side Chain. Whenever the user wants to get it back to the Main chain, he just has to unlock them buy burning the MTB18 in the Side Chain. In example:

"Let's suppose we are 4 friends (F1, F2, F3, F4) who bought 6 MTB each one and:

Action(MC) MTB18*(MC) LOCKMTB18*(SC) MTB18*
F1 locks 6 MTB18MTB18[F1] = 0, MTB18[F2] = 6, MTB18[F3] = 6, MTB18[F4] = 6MTB18Lock = 6MTB18[F1] = 6, MTB18[F2] = 0, MTB18[F3] = 0, MTB18[F4] = 0
F1 transfers 3 MTB18 to F2MTB18[F1] = 0, MTB18[F2] = 6, MTB18[F3] = 6, MTB18[F4] = 6MTB18Lock = 6MTB18[F1] = 0, MTB18[F2] = 3, MTB18[F3] = 0, MTB18[F4] = 0
F1 transfers 2 MTB18 to F3MTB18[F1] = 0, MTB18[F2] = 6, MTB18[F3] = 6, MTB18[F4] = 6MTB18Lock = 6MTB18[F1] = 0, MTB18[F2] = 3, MTB18[F3] = 2, MTB18[F4] = 0
F1 transfers 1 MTB18 to F4MTB18[F1] = 0, MTB18[F2] = 6, MTB18[F3] = 6, MTB18[F4] = 6MTB18Lock = 6MTB18[F1] = 0, MTB18[F2] = 3, MTB18[F3] = 2, MTB18[F4] = 1
F4 transfers 1 MTB18 to F3MTB18[F1] = 0, MTB18[F2] = 6, MTB18[F3] = 6, MTB18[F4] = 6MTB18Lock = 6MTB18[F1] = 0, MTB18[F2] = 3, MTB18[F3] = 3, MTB18[F4] = 0
F2 transfers 3 MTB18 to F3MTB18[F1] = 0, MTB18[F2] = 6, MTB18[F3] = 6, MTB18[F4] = 6MTB18Lock = 6MTB18[F1] = 0, MTB18[F2] = 0, MTB18[F3] = 6, MTB18[F4] = 0
F3 unlocks 6 MTB18MTB18[F1] = 0, MTB18[F2] = 6, MTB18[F3] = 12, MTB18[F4] = 6MTB18Lock = 0MTB18[F1] = 0, MTB18[F2] = 0, MTB18[F3] = 0, MTB18[F4] = 0

If this was done in the Main Chain, 5 transactions would be needed. In the case of doing it through the Side Chain, only 2 transactions are needed, the lock and the unlock one."


  1. Jordi Estapé CanalJoaquín Jiménez, organicemos una reunión para ver esto en detalle. Excellent idea!

  2. Propuestas de días para la reunión:

    6, 7 y 8 de junio por las tardes.

    1. OK, agenda una reunión para el 6 a las 15h en Terrassa.

  3. Coordino con Jordi. El está libre a partir de las 19 horas el día 6.

    Terrassa es un buen sitio, subiré con coche por si finalizamos tarde no tener problemas de horarios de trenes.

Write a comment…