Hyperledger Sawtooth vs Quorum in concurrency and speed

Question

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.

Answer 1

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.