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

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

ethereum / py-ssz

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

the problem