How block hash should be derived?

hyperledger / iroha

Iroha - A simple, enterprise-grade decentralized ledger

https://wiki.hyperledger.org/display/iroha

Apache License 2.0

433 stars 277 forks source link

How block hash should be derived? #4641

Closed Erigara closed 1 month ago

Erigara commented 3 months ago

Look like we sign over whole block not just header. I see few problems with that:

redundant becasue in the block header merkle root of transactions is alredy included
might harm ability to verify block for light client, since in order to verify inclusion of transation we need whole transacaction set

I will create a ticket for discussion.

_Originally posted by @Erigara in https://github.com/hyperledger/iroha/pull/4518#discussion_r1611265234_

mversic commented 3 months ago

I agree here

s8sato commented 3 months ago

It would be enough to sign payload.header if it derives payload.commit_topology and payload.event_recommendations
During the inclusion verification, the light client would test the other node to see if it can fill the missing path between the leaf and the root (payload.header.transactions_hash). I don't think block signatures are relevant

s8sato commented 3 months ago

Ah, I guess what you see as a problem is HashOf<SignedBlock> implementation. If so, yeah, this would be a problem when that approach is required since light clients would store at most block headers of the other chain

Erigara commented 3 months ago

Yeah, it also the case that hash of block is not the same across block's lifetime

s8sato commented 3 months ago

It sounds natural to me that a block hash is transient until it become CommittedBlock. It would not matter unless hash is used as an identifier

Erigara commented 3 months ago

In the logs i've encountered cases where there is message that block was created (one hash) and than block committed (another hash). This makes debugging less convenient. Also imo it's natural to treat block hash as some kind of identifier.

s8sato commented 3 months ago

If the problem is that a block hash is affected by the aggregating signatures, wouldn't it be enough to change the logging implementation to refer to hash_of_payload?