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...).
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:
when changing the
state_root
should definitely yield a differenthash_tree_root
(and ultimately yield an inequality in value...)the above example fails when we use the persistent interface: