I like it, because is easier to extend in the future, but maybe is worst optimized because the key, the address, is duplicated

Thanks Shargon!
If we put the byte as a suffix, like it's being done, it won't change space efficiency.
Even if we don't put MPT hash in block header, we will eventually (soon enough) use MPT as storage, since it is optimized already for such cases, and allows a minimal and necessary chain state audit.

On a prefix tree (example MPT), the key "abcdef1" and "abcdef2" will share the same base "path" ('abcdef'), so it doesn't matter how many suffixes you create, base key space is the same. So, it's important that field options come as a suffix, not prefix.
Prefix can still be used for regular stuff, like Account marking, etc, since it's the first byte the be read, and may affect the logic of the next ones to be read.

I think Storage.Add is useless. We can check fees without it.

I think Storage.Add is useless. We can check fees without it.

Ok Erik, I also think Add is a crazy shot.. but this change here is important with or without the Add... this is useful to simplify NEP-5 native code and allow garbage collection and template reutilization of Native NEP-5. When it comes to Add decision, then we think carefully if it's worth or not. But I agree it's almost certainly not good, since depending on chain state does not seem a good thing.

Coming back to this when contract inheritance is available.