Skip to content

Gotcha on caching hash tree roots and mutability (affecting, e.g. equality checks) #115

@ralexstokes

Description

@ralexstokes

Just ran into a gotcha that we should document or possibly fix in code so there is at least a warning when we hit this footgun. As I spend time writing this issue, it seems more and more like just a bug, honestly...

the problem

right now if you have some ssz object, you can change properties directly on the object OR go through the persistent interface. it turns out that not going thru the persistent interface does not update the hash tree root (if there is one cached, which may be all the time? not sure on when and how the roots are computed/cached...).

for example:

block = SignedBeaconBlock.create(...)
another_block = block.message.state_root = 32 * b'\x11'
assert block == another_block  # incorrect!!!!!!!
assert block.message.state_root != another_block.message.state_root  # correct

when changing the state_root should definitely yield a different hash_tree_root (and ultimately yield an inequality in value...)

the above example fails when we use the persistent interface:

block = SignedBeaconBlock.create(...)
another_block = block.transform(("message", "state_root"), 32 * b'\x11')
assert block != another_block  # as we expect
assert block.message.state_root != another_block.message.state_root  # still correct

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions