-
Notifications
You must be signed in to change notification settings - Fork 78
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
Mainnet state difference at *some* of the RPC nodes at *empty* block 5282529 #3424
Comments
More fun, rpc2 (but others are fine again):
|
Related to #3424. Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
This one strange, I've checked the transaction logs for rpc2 and seed3 manually, and they are identical:
Response from https://rpc2.n3.nspcc.ru:10331:
But there are OnPersist/PostPersist differences as far in this block, and these differences are real:
|
Some more info about sorting order of validators/committee: RPC4 (https://rpc4.n3.nspcc.ru:10331), block 5282529:Candidates sorted by votes, top 21:
Committee sorted by pubs:
RPC2 (https://rpc2.n3.nspcc.ru:10331), block 5287989:Candidates sorted by votes, top 21:
Validators sorted by default primary index:
Committee sorted by pubs:
|
Notice that for block 5282530 on RPC4:
It's NXBhD662PnMFHZ1jJnreVTx71tdmqtrjL9 and it's completely missing from the list. But 5282531:
is Nhvpo1kz1iv8KuBB1KGAbUxHet4V1Gzz4u. |
Then it's NYz4EgdsM1ATNedAbxFJw499kDBWhc8uut and then NXsJYaejf5EFrFgSuPp4XUXajQ8BXUVoN8. NXsJYaejf5EFrFgSuPp4XUXajQ8BXUVoN8 and NXBhD662PnMFHZ1jJnreVTx71tdmqtrjL9 look like voters for validators. |
Except they don't really vote. |
It's NF2/NF5 nodes, from down below of the https://governance.neo.org/ |
is exactly
|
So it looks like
|
Account is blocked when it's in the Policy's storage. Introduced in bbbc680. This bug leads to the fact that during native Neo cache initialization at the last block in the dBFT epoch, all candidates accounts are "blocked", and thus, stand-by committee and validators are used in the subsequent new epoch. Close #3424. This bug may lead to the consequenses described in #3273, but it needs to be confirmed. Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Account is blocked when it's in the Policy's storage, not when it's missing from the Policy storage. Introduced in bbbc680. This bug leads to the fact that during native Neo cache initialization at the last block in the dBFT epoch, all candidates accounts are "blocked", and thus, stand-by committee and validators are used in the subsequent new epoch. Close #3424. This bug may lead to the consequenses described in #3273, but it needs to be confirmed. Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Account is blocked when it's in the Policy's storage, not when it's missing from the Policy storage. Introduced in bbbc680. This bug leads to the fact that during native Neo cache initialization at the last block in the dBFT epoch, all candidates accounts are "blocked", and thus, stand-by committee and validators are used in the subsequent new epoch. Close #3424. This bug may lead to the consequences described in #3273, but it needs to be confirmed. Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Broken RPC:
Good RPC:
Might be related to #3273.
The text was updated successfully, but these errors were encountered: