Closed Inphi closed 1 year ago
Hi, does it work if you change CalculateLimit
with 48? Also, are there any official tests for these encodings I can use to unit test?
Please check if #116 works.
The change looks OK, but the root doesn't match what I expect. I've narrowed it down to the merkleization of the kzg List itself. There aren't any official test vectors for the new types yet. But we use remerkeable in the official specs for consensus tests. The hash_tree_root I get using remerkleable doesn't match sszgen's:
from remerkleable.complex import List
from remerkleable.byte_arrays import ByteVector
kzgs = List[ByteVector[48], 16]()
kzgs.hash_tree_root().hex() == "792930bbd5baac43bcc798ee49aa8185ef76bb3b44ba62b91d86ae569e4bb535"
whereas the root the above struct definition in my OP for fastssz, the root is 0x52e2647abc3d0c9d3be0387f3f0d925422c7a4e98cf4489066f0f43281a899f3
. I'm not sure which ssz implementation is correct here though.
Hi. Any updates here?
Hi @Inphi. Sorry I was in an offsite and quite dumped with work. I am still checking this. I think I might find time in the coming days to check.
Please check again the PR linked, it returns now the same results as remerkleable
. There was a problem in how the limit for the merkle trie was being calculated for complex types (Vector
).
Awesome! The fix works well. Thank you!
We're using sszgen for an updated eip4844 beacon block body:
The
BeaconBlockBody
contains a new field,blob_kzg_commitments
, whereKZGCommitment
is aBytes48
ssz type andMAX_BLOBS_PER_BLOCK
is16
. So we add the field to the newBeaconBlockBody
struct in our prysm fork:However, the updated generated tree routine for the beacon block looks incorrect:
I'd expect that the
size
input forCalculateLimit
to be48
but here it's0
which causes the newBeaconBlockBody
root to be incorrect.