Historic Data Integrity on Storage and Validation

Projects such as BigChainDB use external storage to save the Blockchain data. Similarly I am planning to use external storage to save large scale data and use Cosmos SDK to provide the blockchain capability on top of it (distributed nodes validate all the entries as they are being added onto the storage). One question I have is, how Tendermint ensures the correctness of old blocks (that are on the storage)? Recently there are incidents of ransomware corrupting the data on storage (actually it encrypted the data, demanding money to provide the decryption key). Essentially there is nothing (in Tendermint) that prevents anyone to access the database or harddisk directly and selectively overwrite parts of the record data. I understand that block hashes has to match and changing the data will result in hash mismatches. The question I have is: when the old data on the storage is changed, how does Tendermint (or my app built on top of it), would know that somewhere on the disk some hashes are mismatching for some records ? Is the complete chain validated at all times (whenever a new block is being added)? For example, on one node, one could open one year back records (on the…

Excerpt (1196 of 2395 characters). Read the whole post on the forum ↗

Essentially there is nothing (in Tendermint) that prevents anyone to access the database or harddisk directly and selectively overwrite parts of the record data. Correct Is the complete chain validated at all times (whenever a new block is being added)? No it is not. How Tendermint prevents these kind of situations? Currently it doesn’t. If someone tries to gossip such a block, it will not be possible to validate. For instance if your node is so compromised, and I’m downloading blocks from you, I will mark you as a bad peer for sending me this bad block. This isn’t something we can really deal with short of running an integrity check on the entire blockchain all the time. We could add support for something like that in the future, but it’s not really a priority now because you can always remove your data and resync from the network. For this to be a problem, the attack would have to compromise more than 2/3 of the validators. If they manage to do so, well, to some extent they deserve to win That said, it would be interesting to add such integrity checking in the future. I think other databases do this under the guise of “anti-entropy”. It’s something…

Excerpt (1197 of 1356 characters). Read the whole post on the forum ↗

Thank you @ebuchman It is good to know the capabilities and limitations of the system, so that we can use the SDK more effectively. Your explanation was helpful in clarifying things. ebuchman: If someone tries to gossip such a block, it will not be possible to validate. My understanding currently is that, only new / latest proposed blocks/records come to gossip and old records usually tend to not come in validation again - is it correct? I am trying to understand the scenarios when an old block might come into gossip again. If the compromised block in question is, say 1 year old record, and assume that there are many blocks (records) after it, would there be a situation where this 1 year old record comes into validation again? ebuchman: For this to be a problem, the attack would have to compromise more than 2/3 of the validators. If they manage to do so, well, to some extent they deserve to win I totally agree. But I am coming from a slightly different perspective. In a distributed system (such as these blockchains), the attack need not be centralized or coordinated anymore. For a distributed system, there will be distributed compromises…

Excerpt (1199 of 2134 characters). Read the whole post on the forum ↗