Conversation
4d77dc3 to
8865e91
Compare
8865e91 to
f89e6a2
Compare
|
could you please give some context how this PR is related to #809 ? |
| constexpr uint32 QRAFFLE_MIN_QRAFFLE_AMOUNT = 1000000ull; | ||
| constexpr uint32 QRAFFLE_MAX_QRAFFLE_AMOUNT = 1000000000ull; | ||
| constexpr uint32 QRAFFLE_MAX_TOKEN_RAFFLES = 1048576; | ||
| constexpr uint32 QRAFFLE_MAX_SHAREHOLDERS = 1024; |
There was a problem hiding this comment.
there are only 676 shares, why do you need this constant?
| Array<uint32, QRAFFLE_MAX_EPOCH> daoMemberCount; // Number of DAO members (registers) at each epoch | ||
| HashMap<id, uint8, QRAFFLE_MAX_MEMBER> registers; | ||
| Array<ProposalInfo, QRAFFLE_MAX_PROPOSAL_EPOCH> proposals; | ||
| HashMap<VoteKey, bit, QRAFFLE_MAX_VOTE_ENTRIES> voteStatus; |
There was a problem hiding this comment.
you're changing the memory layout of the state here, this means all previous data will be scrambled.
There was a problem hiding this comment.
@double-k-3033 For the core, the state is a binary blob of data and by replacing HashMap <uint32, Array <VotedId, QRAFFLE_MAX_MEMBER>, QRAFFLE_MAX_PROPOSAL_EPOCH> voteStatus; with HashMap<VoteKey, bit, QRAFFLE_MAX_VOTE_ENTRIES> voteStatus; you just change how this part of the binary blob is interpreted, which usually leads to nonsense data and a lot of problems.
Quite common practice is extending the state with additional members, which are initialized with zeros.
For changing parts of the existing state (what you do here), you need to build a separate state conversion tool for the computor operators that reads the state file of the contract from before the change and writes the new state that the new version of the contract expects. That is why changing the memory layout of the state should be avoided.
Release v1.287.0
* update contract verification tool for oracles * reenable check for QUtil * use pre-built docker image for contract verify
No description provided.