Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ralexstokes opened this issue May 15, 2020 · 1 comment

Comments

@ralexstokes
Copy link
Member

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
@ralexstokes
Copy link
Member Author

i'll leave this issue as temporary documentation and ideally we get around to fixing this ASAP

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant