tfchain
tfchain copied to clipboard
threefoldtech
Calculate vote weight when a proposal is closed
Currently vote weights are calculated when a vote is cast. A farmer setup can change during the duration of a proposal and thus his weight can be different when a proposal is closed then when he actually voted. We can calculate the weight of a vote when we close a proposal but this can be a very storage intensive operation. When we want to do this we also need proper weight calculation on the close method.
We can calculate the weight of a vote when we close a proposal but this can be a very storage intensive operation
When you say "storage intensive operation" you mean the accumulation of validation processes (1 for each farm) to write farms weight on chain at end of vote, right? (instead of doing it on the flight when a vote is cast)
The weight of a farmers vote is calculated independantly from the vote. The weight is modified whenever a node is added or removed from the farm.
When the farmer casts his vote, the weight is read from storage and set on the vote. This is a 1 read, 1 write operation when vote is called. This means the weight is locked in when the farmer called vote.
If we want to calculate the weight for a farmer when close is called we need to iterate over all the farmers that voted, and read the weight from storage. This a n read operation (where n is the amount of farmers). This can be a heavy iteration if for example +1000 farmers voted for a proposal and close is called.
This a n read operation (where n is the amount of farmers). This can be a heavy iteration
I understand that reading on chain for all farmers at the same time can be an unwanted cost But I though there was kind of middle-man (gridproxy or graphql...) that has updated information on farms, is this the case?
I understand that reading on chain for all farmers at the same time can be an unwanted cost But I though there was kind of middle-man (gridproxy or graphql...) that has updated information on farms, is this the case?
The chain cannot read from gridproxy or graphql.
Ok I get it So a solution could be considering an extended "counting period" after end of voting to be able to smooth the heavy iteration of the n read operation
Ok I get it So a solution could be considering an extended "counting period" after end of voting to be able to smooth the heavy iteration of the n read operation
Not really, since closing a proposal is manual operation and the work needs to be done when the proposal is closed.
The solution is properly calculating the weights for the close operation based on the amount of farmers that have voted.