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

Dettaching Native NEP5 TState into separated keys #831

Closed

Conversation

igormcoelho
Copy link
Contributor

This is a draft implementation for #830

@igormcoelho igormcoelho changed the title Dettaching state into separated keys Dettaching Native NEP5 TState into separated keys Jun 14, 2019
@shargon
Copy link
Member

shargon commented Jun 14, 2019

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

@igormcoelho
Copy link
Contributor Author

igormcoelho commented Jun 14, 2019

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.

@igormcoelho igormcoelho mentioned this pull request Jun 14, 2019
@erikzhang
Copy link
Member

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

@igormcoelho
Copy link
Contributor Author

igormcoelho commented Jun 15, 2019

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.

@igormcoelho
Copy link
Contributor Author

Coming back to this when contract inheritance is available.

@igormcoelho igormcoelho deleted the feat_3x_dettach_tstate branch June 28, 2019 10:21
Thacryba pushed a commit to simplitech/neo that referenced this pull request Feb 17, 2020
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

Successfully merging this pull request may close these issues.

4 participants