Block identification in a multi-hash blockchain

In a classical blockchain platform, each block is identified by a the hash of the block which contains all of the possible information of the transaction, nonce, difficult, previous block hash and so on. From a practical point of view it works as an id of the block. In a multi-hash blockchain, the situation is however a little bit more complicated as there are at least two different hashes of the block. They are certainly, not absolutely independent from each other, as they contain the same data and transactions, however the resulted hash values seem to be totally independent from each other because of the characteristics of the cryptographic hashes. There might be several ideas to identify the blocks:

- one option might be to simply use the two hashes. However as soon there is not just a pair of hashes but a complex hashmatrix, we might as well handle several docents of hash values, which makes the process relative less user-friendly. 

- we might as well use something which is calculated based on the consistent information of the hashes, but itself directly is not contained in the chain. One idea would be the hash of all of the hash pointers. 

- Another idea might be to use something which is "bellow" the hash pointers, like the hash of all data. It might provide the possibility to easily check if a certain data is available in the chain or not. Certainly, the disadvantage is that it might provide an extra attack vector for tricky hackers.  

Hash matrix - a blockchain algorithm with multiply retention policy

Hunting for the holy grail of a blockchain solution with multiply retention policy, we might as well consider the extended version of the multi-hash blockchain structure. There are different transactions or different pieces of data with different retention policies hashed together with a double hashing structure where regularly one of the hashes will be reseted realizing practically a forgetting functionality on the chain. On top data from a longer retention data can be hashed together with data from a smaller retention period realizing a kind of hash-matrix that can be seen on the picture bellow:

The structure is pretty much straightforward at the first stage, as the immutable structure has only one hash chains, however the exact implementation will be questionable at later stages. The problem that in the long retention policy structure there are actually two independent hash-chains, which are of course contain the same set of transaction and data but they differ on the hash value. It is a little bit questionable which of these chain should be hashed together with the next one. Some of the possibilities might be:
- Both hash chain is from the long retention policy chain is hashed together with the short retention policy one. This structure however might cause the exponential explosion of the different hash values, as at the case of short retention policy there might be the possibility that we have to manage 4 chains. There might be some simplification of the reset time of the different policies can divide each other and they are well scheduled.
- Only the data or transaction of the previous retention policy chain is copied into the next phase, without the information of the previous hash values. It can however decrease the reliability of the whole structure.