Add the `data_hash` to the output of the `cell info`.

[jordanmack]

It would be helpful to have the data_hash available on the cell info viewer.

[shaojunda]

What does data_hash mean? Does it mean to do Blake2b on cell data ? Why do you need data_hash?

[jordanmack]

What does data_hash mean? Does it mean to do Blake2b on cell data ? Why do you need data_hash?

Yes, it is the Blake2b hash of the cell data as seen in the output of get_live_cell.

I believe this is beneficial to have because it can be matched against code_hash when trying to match cell content.

[shaojunda]

I understand what you mean, but not all cell data is code. cell data can be normal data, so dada_hash is meaningless to normal data. @jordanmack

[jordanmack]

A data_hash may be irrelevant in some cases, but it is highly relevant for a code_hash and also dynamic loading. For anything that is executable, like a script, library, or module, it is very beneficial to have this information.

If the purpose of an explorer is to allow a user an easy interface to walk through the blockchain, then being able to match the data_hash is the final step for tracing any script. I can see this being very beneficial to developers trying to understand CKB, and I would like to use this functionality as part of the lesson plans currently being developed.

[shaojunda]

My current point is that most data will not be a script, but common data. For tracing script, We are considering adding a Script module. It can be understood as a separate page, the user can enter this page by clicking code_hash in the script.

[jordanmack]

I agree that the data in the majority of cells will not be scripts, but if it's not relevant to the user it can just be ignored. It's a single line in a JSON structure.

If you have a better way of presenting it in mind, I'm fine with that as long as it completely addresses the needs. Tracing a code_hash is the most common, but we may also see growing use in the future from libraries and dynamic loaded modules. Ultimately the bridge needed is to determine if an outpoint specified by the user has the data hash being searched for. As long as that is accomplished by this solution, we're in agreement.

[shaojunda]

I agree that the data in the majority of cells will not be scripts, but if it's not relevant to the user it can just be ignored. It's a single line in a JSON structure.

If you have a better way of presenting it in mind, I'm fine with that as long as it completely addresses the needs. Tracing a code_hash is the most common, but we may also see growing use in the future from libraries and dynamic loaded modules. Ultimately the bridge needed is to determine if an outpoint specified by the user has the data hash being searched for. As long as that is accomplished by this solution, we're in agreement.

Thank you very much for your suggestions, which we will discuss it internally.