Gossip Network

Cluster Replicated Datastore for Diet Clients

Individually the diet clients would be sampling shreds and storing them for the epoch which would help prevent eclipse attacks as explained above. In addition to that, it also helps the lagging clients to sync up very quickly with others in the network. But the probability of data being withheld exponentially decreases once you have multiple diet clients which communicate with each other about the state of data availability for a particular slot. When a client starts sampling a slot and doesn’t receive the necessary shreds it may request other clients in the network to check if the shred has been propagated to any other client. This ensures that there are no false alarms about an eclipse attack that might be caused by some kind of software or network error with that particular client and node. Upon verify the merkle root if there seems to be an invalid shred that too can be confirmed with other clients in the network.

Client Aided Partition Repair

Validators tend to have to repair their forks either due to inefficiency in turbine or network difficulties. Repair is usually extremely slow and inefficient. Addi- tionally, nodes can be eclipsed from the shreds necessary to repair the partition if the super majority has propagated a malicious block in which case the node cannot repair and replay the block to prove this. To combat this the validator can look at the gossip table and request the shreds that are missing from it’s fork from each client and then clients can then send the shreds to the validator. Because partitions can be repaired from diet clients spread across the globe that may be geographically close to the node, the repair process will also be faster by a significant magnitude compared to the from another validator.