Use hash_tree_root to generate shard block body root
#1980
Conversation
Include the mix-in length to the proof.
hwwhww
force-pushed
the
hwwhww/use-hash-tree-root-for-shard-body
branch
from
eb27a34 to
e7f070d
Compare
| data_branch = build_proof(custody_data_block.get_backing().get_left(), chunk_index + 2**spec.CUSTODY_RESPONSE_DEPTH) | ||
| leaf_index = chunk_index + 2**spec.CUSTODY_RESPONSE_DEPTH | ||
| serialized_length = (len(custody_data_block)).to_bytes(32, 'little') | ||
| data_branch = build_proof(custody_data_block.get_backing().get_left(), leaf_index) + [serialized_length] |
There was a problem hiding this comment.
Do we still need the backing from remerkleable?
What exactly does get_left() give you here?
There was a problem hiding this comment.
afaik the get_right() is the mix-in length and the left side is the block data.
@protolambda 's example here: https://gist.github.com/protolambda/8384b1305613d064ba962214d08396f0
We can use eth2spec.utils.merkle_minimal.calc_merkle_tree_from_leaves and get_merkle_proof to create the proof too. Hmm, if we want to include proof generation in v-guide, using get_merkle_proof helper would be simpler. What do you think?
There was a problem hiding this comment.
In the validator guide, I think we should be explicit and not use underlying library structure functions.
As for the spec tests, I'm happy to use the remerkleable backings because they are probably much more efficient
* Quick fix the configurations * Remove the unused `CUSTODY_RESPONSE_DEADLINE`
Issue
Address #1973 and replace #1975
#1973 (comment): No problem for the proof of custody or MPC-friendliness.
How did I fix it
hash_tree_rootto generate the root instead ofget_block_data_merkle_root