Optimize vote reward data#2841
Conversation
1607216 to
f74638f
Compare
|
I will fix ut. |
| Struct @struct = (Struct)stackItem; | ||
| BalanceHeight = (uint)@struct[1].GetInteger(); | ||
| VoteTo = @struct[2].IsNull ? null : ECPoint.DecodePoint(@struct[2].GetSpan(), ECCurve.Secp256r1); | ||
| LastGasPerVote = @struct[3].GetInteger(); |
There was a problem hiding this comment.
Yes and no. We'll get a different NEO contract state, true. We may have some problem with getAccountState method, but that's easy to solve (strip the third struct item, return only the old two ones to stay compatible, we can add getAccountStateV2 that will return everything, but we might as well not do that, I don't see a lot of uses for this data). But anything else will just work: balances, transfer data, GAS calculations, etc. So it looks more like a regular DB resync to me.
|
The main question though, does it have any effect wrt to the DB resync speed and size? Have you measured this? |
Not yet. I just compare gas balances on Testnet. I will measure db size and resync speed these two days. |
|
I test data sync on my working laptop with RpcServer, ApplicationLogs, StateService
I expect this patch will sync faster but actually not. I will retest it again on a server and test mainnet. |
|
Mainnet fullstate leveldb sync compare:
|
|
@shargon, @devhawk, @erikzhang, @vncoelho, @igormcoelho, I think after all of the testing done by @ZhangTao1596 here and in nspcc-dev/neo-go#2892 we can say that
So, I'd say it's good to go. |
|
@shargon I think we can move on. |
|
@shargon may you please review this pr? |
Optimize vote reward data, see also neo-project/neo#2841.
Close #2815
2nd option from #2815 (comment)