Necessity of signature method

This Page describes why it is necessary to sign actual file hash which is used to sign validation root.

Now that we are clear about Fixed Merkle Tree and Validation Tree, lets describe signature method used to secure data. We generate signatures in following manner:

1. Actual file hash is signed thus giving Actual File Hash Signature(FHS). This signature is common for a file among all blobbers.

2. For each blobber, FHS + ValidationRoot is hashed and signed, thus generating Validation Signature(VS). This VS is different for different blobbers because content for each blobber is different with an exception when number of data-shards = parity-shards = 1.

We could have simply signed Validation Root and be fine with it as when data is downloaded we could verify Validation Root and then verify data w.r.t. merkle proof whose root is Validation Root. However some dishonest blobber can corrupt whole data and neither blobber gets punished by blockchain nor is it easy to find dishonest blobber.

Suppose a file has content C and its plain hash(aka actual file hash) is H. Lets suppose that there is an allocation with 3 blobbers; 2 data-shards and 1 parity-shard. Consider Validation Root is VR1, VR2 and VR3 for blobber-1, blobber-2 and blobber-3 respectively. Now client updates this file with content C', actual file Hash H' and validation roots VR1', VR2' and VR3' respectively in blobbers blobber-1, blobber-2 and blobber-3. If blobber-3 is dishonest then it shall retain data with validation root VR3 which will pass signature verification and merkle proof as well. But reconstructing whole file with this data will corrupt file. Its not easy to find dishonest blobber. And if there are more than one dishonest blobber then situation becomes worse.

How will above signature method save client from dishonest blobber?

1. First client verifies actual file hash against its signature and takes consensus on actual file hash amongst blobbers. If consensus is not met, it means majority blobbers are dishonest and client has basically lost their data. However our protocol relies on the assumption that majority blobbers will be honest.

2. For each blobber that is included in above consensus, actual file hash signature + validation root is hashed and it is verified against validation root signature.

3. We can see in step 2 that blobber cannot use latest actual file hash and older validation root as it will mismatch with validation root signature.

4. We then verify downloaded data w.r.t. this verified validation root with the given merkle proof.

What if blobber does not comply with these standards? Client can simply acknowledge such blobber and replace it with other blobber.