ethereumjs-monorepo
ethereumjs-monorepo copied to clipboard
ethereumjs
Trie inconsistency of del/put
If we put on a key where one of the nodes (i.e. the final one before we write a node) in the path is not available (i.e. get branch node key): do not care
If we delete a key where one of the nodes in the path is not available: throw
This is inconstent.
Isn't this rather even close to a bug? 🤔
Is it somewhat recognizable on put that the operation then didn't work properly? Otherwise I would think this can be very much put in the bug-category and we should (I am not a trie expert, so feel free to comment/disagree) fix this by throwing for put as well (guess we can include this in a non-breaking release).
Well, if we start throwing on put as well, then this is breaking, right?
Well, if we start throwing on
putas well, then this is breaking, right?
Technically rather yes, though one could also put this in the bugfix-category (if my understanding is correct that in case of such a put operation you end up with a corrupt trie anyhow.
I would therefore be inclined to say: since this has somewhat the notion of a bugfix and we are super early with the breaking releases not being very much used/adopted yes, we can/could just take this in.
Also open for other voices here of course, just my thoughts and personal weightings.
Is this still a thing?
If so: we should fix/adjust before the breaking releases.
If not: we should close.
I'm not super sure what I wanted to do here, and if I think about it throwing on put makes no sense since it will insert paths for most cases anyways. So I will close, not sure what my line of thought here was.