4844: use hash_tree_root for tx hash

[lightclient]

I think we should move to hash_tree_root for calculating the transaction hash of 4844 transactions if we plan to migrate to an SSZ list of transactions.

The reason for staying with (and originally choosing) keccak is that it fits nicely into the expectation that the MPT hashing algorithm has for leaves greater than 32 bytes, it will simply take the keccak of it.

[eth-bot]

All tests passed; auto-merging...

(pass) eip-4844.md

classification
updateEIP

• passed!

[vbuterin]

Strongly support going in this direction. We have a medium-term goal of moving transactions as a whole away from RLP and Merkle Patricia trees to SSZ, and hash_tree_root is clearly what will be used for both signing hashes and txids long-term, so it makes more sense to move to it immediately than to have an awkward halfway-house where this one transaction type has one foot in the future SSZ system and another foot in the historical RLP system.

The main downside that I see is that this will break some infrastructure that depends on txid = keccak(serialize(tx)). I think the fact that we're introducing SSZ with this type of transaction is actually an argument for why now is exactly the time to make the change. EIP-4844 transactions are expected to be a specialized tool, which would be used by either (i) sophisticated actors publishing blobs for rollups, or (ii) sophisticated actors who just really want to be vanguard users of SSZ transactions; there are no existing applications and no expectation of regular users relying on EIP-4844 transactions behaving in any particular way. Hence, the costs of EIP-4844 transactions being incompatible with some existing infrastructure (even, if desired, eg. the getTransactionHashes RPC returning the "wrong" hash) are lower than they would otherwise be.

[etan-status]

The signed hash must be protected against malleability

In this example, both hash_tree_root(foo) and hash_tree_root(bar) have the same value: b8061be2b4337ac42bc6ddb54395dbb1241b7fde97ae35539d2af32e7ba8ca5f

    type
      Foo = object
        a: uint64
        b: uint64
        c: uint64
      Bar = object
        a: uint64
        b: uint64
        c: uint64
        d: uint64

    let
      foo = Foo(
        a: 0x42,
        b: 0x42,
        c: 0x42)
      bar = Bar(
        a: 0x42,
        b: 0x42,
        c: 0x42,
        d: 0)

    debug "Foo", f = toHex(hash_tree_root(foo).data)
    debug "Bar", f = toHex(hash_tree_root(bar).data)

The transaction hash should be perpetually stable and unique.

In consensus, there is compute_signing_root. Also, all objects that are being referred by HTR have a stable offset that contains a field to derive version from, e.g., slot number for blocks.

Overall, the solution should be compatible with whatever we are deciding during ethereum/pm#721 regarding the overarching SSZ Transaction representation. While I am in favor of a hashing solution based on SHA256 / hash_tree_root for SSZ transactions, I do not see a real benefit in requiring the HTR and txid be the same value, because such a solution does not work well for either pre-SSZ transactions nor future transactions based on other hashing schemes. Technically, an SSZ hash_tree_root could simply be put into the current transactions MPT, same as any other transaction hash that is currently fed into it — this doesn't require a transactions SSZ structure.

As for security, if we decide to mix keccak256 and SHA256 hashes, cryptographic analysis may be necessary to determine the amount by which the hash collision probability is increased.

• https://en.wikipedia.org/wiki/Avalanche_effect
• https://en.wikipedia.org/wiki/Universal_composability
• https://crypto.stackexchange.com/a/96474
• https://crypto.stackexchange.com/questions/50974/merkle-trees-instead-of-the-sponge-or-the-merkle-damg%C3%A5rd-constructions-for-the-d

[etan-status]

Attempt to fix malleability: #6493

[lightclient]

Thanks @etan-status I understand the issue with malleability now. I will close this in favor of #6493