Vote should be preserved without neo balance

[shargon]

Describe the bug
We recently experienced a problem associated with this issue.

If you vote someone and transfer your neos, your vote is removed.
Also, you are able to vote without neo and do nothing.

Expected behavior
Vote must be preserved .

[shargon]

@lock9 move the discussion here

[dusmart]

Should be aware that applying this will result in a hard fork.

[shargon]

Should be aware that applying this will result in a hard fork.

It can be included in Echina

[cschuchardt88]

They paid for the storage already. Unless I am getting a refund or not having to pay. I vote keep their balance. All contracts do this, so they don't have to repay for storage or very little storage to just change the balance.

[Jim8y]

They paid for the storage already. Unless I am getting a refund or not having to pay. I vote keep their balance. All contracts do this, so they don't have to repay for storage or very little storage to just change the balance.

its not about the storage price, its governance protocol issue.

[cschuchardt88]

If you want my real opinion. All native contracts, should be developed like any other contract on the blockchain. What does you mean? It should be compiled NeoVM assembly code. This would make it easier to update than having all this hard fork code. If interop is a problem. Then expand the vm.

[roman-khimov]

All contracts do this

Why do you think so? We're talking about NEP-17 with additional account data. But it's NEP-17 first of all, so if account has no token it's not obliged to keep any additional data. I think any NEP-17 would make the same decision as NEO wrt associated data, balance goes to zero --- bye-bye, we've never met. Just like they never store "0" balance itself, they just delete the entry.

It should be compiled NeoVM assembly code

That was my thought on native contracts about five years ago as well. But at this stage it's not possible since native contracts do things regular contracts can't. And they're exactly for this purpose, we're not adding native contracts if things they provide can be implemented in a regular contract. NNS is the best example, it's not native.

This would make it easier to update than having all this hard fork code

Well, it's just shuffling the update complexity around. From native contract code to non-native contract code. The complexity itself won't disappear because of that.

Regarding the issue itself, WORKSFORME/NOTABUG, but not critical to me either, both approaches have some rationale, so my preference is to minimize data stored and keep things the way they are. Some statistics as in #3720 (comment) can be helpful.