6

Let's suppose I have 50 machines deployed in multiple locations, every machine has Linux as OS.

The machines have not a continued internet connection, for every 2h without connection, they have a 45min period of Wi-Fi connection.

During these 2h the machines are getting data through IoT sensors, stored locally in JSON.

When the 45min. internet connection arrives, the machines send the data into a cloud server for a posterior treatment.

The objective of this question is compare, in this concrete situation, the best DLT for assuring the reliability of the data sent to the Cloud server through multiple concurrent machines.

Thank you very much in advance, and happy new year.

Across
  • 63
  • 5

1 Answers1

5

Summary: Both should provide similar reliability of data. Sawtooth may more easily manage the volatility of the network addressing. In your situation the utility of a DLT is unclear.

Details: Hyperledger Sawtooth uses a Merkle Radix Tree to enforce state agreement. That means that when transactions are exchanged amongst those nodes, each node will check if it has reached the same internal database state as the other nodes. See https://sawtooth.hyperledger.org/docs/core/releases/latest/architecture/global_state.html

Quorum as a Go Ethereum fork has a similar mechanism. However that trie is split to represent public ethereum network state and whatever private state is being managed on the side chain.

According to Quorum's docs the endpoints must be known apriori. That may be difficult for your proposed network if the IP addresses change when the nodes gain and lose connectivity. https://github.com/jpmorganchase/quorum/wiki/Quorum-Overview

This will also be difficult for Sawtooth if all the addresses change. If at least one node remains consistent then the topology can be rebuilt dynamically. Sawtooth includes different protocol options including dynamic peer discovery.

https://sawtooth.hyperledger.org/docs/core/releases/latest/architecture/validator_network.html#peer-discovery

If I'm interpreting your use case correctly, you are suggesting that blockchain nodes would feed their independent views of data into a centralized server. This would not be a good fit for blockchain.

The idea with blockchain is each of those independent nodes would gossip the transactions it has received to the other nodes so that ultimately they all have the same view of data.

Dan
  • 136
  • 3
  • I could install a central machine to enable the peer discovery protocol, that would be a quite good option. I am trying to use a DLT just as a "checking" measure, a way to confirm the receivement of the message and that the message is not corrupted (in the application layer, if it gets lost DLT has nothing to do). Also, would you recommend any other DLT more specialized in this scenario? Thanks! – Across Jan 08 '18 at 12:09
  • If the machines that have intermittent connectivity are just acting as clients (submitting transactions) then most of this doesn't matter. Most of my answer was with the assumption that these nodes were blockchain validators. Clients aren't expected to have persistent connectivity. – Dan Jan 10 '18 at 19:52