Missing perfectly divisible deposits #1821
Comments
|
Check if #1852 has fixed this issue. |
|
#1852 won't fix that. After the introduction of epochs, deposits are activated in the epoch after next i.e. it takes in best case 3601 in worst case 7199 subsequent blocks for them to become effective. If some of the 35 deposit transactions were included in blocks in epoch N and the rest of them in epoch N+1, the deposits that were submitted during epoch N+1 will only take effect a whole epoch i.e. 3600 blocks later. If this is what happened, then it's expected behavior. |
|
I've encountered this issue several times in Note that the missing deposit has a block number of 0x5a0 (1440) which is perfectly divisible by 36, the blocks/epoch value. There may be an off-by-one error in the deposit.sol contract. |
|
Just stashing here the block numbers: 0x577 0x584 0x592 0x5a0 0x5ad 0x5ba 0x5c8 0x5d5 0x5e2 0x5ef. 0x5a0 is the only one divisible by 36 blocks/epoch - the configured value in And the block 0xdc5 is >> 0x5a0. So, it's past many epochs. |
|
Confirmed that the issue still plagues the network post #1946 deposit upgrade changes. |
|
Confirmed that issue disappears when LRU cache is removed - commit d4a2330 does not exhibit this issue. |
|
Confirmed that this issue is not present in #1915 |
|
#1915 removes the state trie cache and allocates that space to the redb cache, since I found the performance was the same and it makes the code simpler. I am curious if we can identify why the cache causes this bug though? Maybe we can run a version which reads from both the cache and the DB and logs if they are different? |
|
I came about this in a reversed way. After looking thru both the Solidity deposit contract and Rust code and not finding any obvious logical errors, I began to work backwards on how the issue could have happened. One hypothesis I had was that the state being presented to the EVM was somehow inconsistent. Since removing the caching layer eliminated the issue, I chalked it up to some inconsistency in caching. Not sure if it might be an issue on our part or the external crate. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Running
z2 deployer depositon a large number of Validators doesn't always stake every node e.g. running it successfully for 35 nodes, may result in only 33 validators - but there are no errors.then a second deposit
Could this be due to the timing of Epochs?
The text was updated successfully, but these errors were encountered: