-
Notifications
You must be signed in to change notification settings - Fork 124
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
EEI: Account handle #112
Comments
Makes sense to me, and seems to better reflect the actual I/O cost of the operation. |
is this really an issue? memory size is neglegible and the copy cost is dwarfed by the IO
It can be mitigated easily though, by adding bitflags, integer or another versioning mechanism |
I believe that's not enough. If you deploy a contract that supports the current version 1 there is no way to support future version 2. Maybe the contract should specify what account fields it is interested in. I added this idea as the alternative #2. |
Could you explain me why that matters? A contract is written against version 1 and explicitly requests v.1 and gets the result in v.1, that sounds good to me and I can't see a reason why it should care about v.2 or something (unless you want to do something like a dynamic proxy that requests and forwards some account data and while it should be forward-compatible).
Yeah, that's what i meant by bitflags : ) |
Yes, that will work. For that I'd rather suggest using different function names for new versions. E.g. Previously, I though you meant to return the format version number as a part of the account structure. |
Ah sorry for that, I was writting on the go back then. Should have make this more clear |
@pepyakin do you have anything similar in pwasm? |
Nope, we don't! |
The main issue with the cost of e.g.
getBalance()
is the fact that the account lookup in the database might be needed. This idea is to split the account loading from the accessing account metadata.Instead of
we should have
Similarly to
getBalance()
there should be getters for code hash, code, code size and others.Pros
Cons
loadAccount
would append new entry to the array.Alternatives
Just dump account matadata to memory:
loadAccount(memoryOffset)
. This is simpler, but might waste some memory when contract is not interested in all data. Is is also not extensible, i.e. we cannot change the account representation in the future.Extension of the alternative 1 where the contract specify the bit mask of account fields it is interested in, e.g.
loadAccount(BALANCE | NONCE, memoryOffset)
. This at least allows adding more fields to the account in the future. But the output would be a mess, especially when getting the account code is considered.The text was updated successfully, but these errors were encountered: