-
Notifications
You must be signed in to change notification settings - Fork 771
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
Handle updates on the bigchain table #195
Comments
Note: It's not enough to check if an update to the bigchain table is a vote. It must be a valid vote:
|
I don't think this is possible in the current architecture. Reverting a change will itself trigger a change and so on. How is the Election process (which handles updates to bigchain) to know the difference between a reverted change, legitimate change, and illegitimate change? |
@rhsimplex and I discussed an idea: make a hash chain of votes (appended to each block) so that we can tell if a previous vote was changed or deleted. (Right now, we can't tell if a vote is being changed by a bad node or by a revert process.) To do that, we could add a new The first vote's hash would be just the hash of the block (the block The last-received vote could be changed (but only by the node who created it), but maybe that's okay: it's just one vote. @r-marques @diminator @vrde Do you think this would work? |
How would you append?
|
The block model already has |
oh, ok so we're actually updating that record and not appending? |
The list of |
but couldnt a node always remove all votes and restart from the block id? |
Yes, but I guess that would be easy to detect from the changefeed: a block would go from having lots of votes (with a valid vote hash chain) to none (also valid, so this is a corner case). The revert change would also be easy to verify: a bunch of votes suddenly appearing where there were none before, and they would have a valid hash chain (and there's no way one node could build such a thing). |
ok, taking into account |
As discussed in the planning meeting today, @rhsimplex and I thought of an alternative solution: create a new, third table for votes. Then the bigchain table becomes append-only, the votes table would be append-only, and the logic for detecting "bad" changes in the changefeed becomes really simple. This idea was discussed and we decided to go ahead with it. Note: The |
We need to check for updates on the
bigchain
table. The only updates allowed are the appending of new votes. Any other update needs to be revertedThe text was updated successfully, but these errors were encountered: