Nethermind sync test fails: import failure
holiman opened this issue · 3 comments
Nethermind rejects block 28 in the initial import, and thus fails to serve as a sync source for the sync test.
--
| 2021-11-17 11:17:22.7332\|HIVE new head block 27 (0x06f382...a7a35b)
| 2021-11-17 11:17:22.7332\|HIVE suggested 27 (0x06f382...a7a35b), now best suggested header Hash: 0x06f38272831a264ac1d33995f95f79df762bc49a268f8a07a7315b5606a7a35b
| Number: 27
| Parent: 0x0ea990a3d2e2461397e508c43d61f9a0a38368a1f802f86fe3f7c4e96d58cc9f
| Beneficiary: 0x0000000000000000000000000000000000000000
| Gas Limit: 2147483648
| Gas Used: 0
| Timestamp: 11340
| Extra Data:
| Difficulty: 131072
| Mix Hash: 0x8733c3acd6d089e820b29c8d4831a082579de65af25f012f4174c4da4c9d4984
| Nonce: 4404912134999573770
| Uncles Hash: 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347
| Tx Root: 0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421
| Receipts Root: 0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421
| State Root: 0x28f73ac76ee88388cf5619fd75b9c36ed5cd9f314a183f9aa2567f8d3b9264bd
| BaseFeePerGas: 0
| , head 27 (0x06f382...a7a35b)
| 2021-11-17 11:17:22.7332\|HIVE Processing a chain.rlp block 28 (0xd2651c...94e60e)
| 2021-11-17 11:17:22.7332\|Cannot add block 28 (0xd2651c...94e60e) to the blockTree, add result CannotAccept
@MarekM25 @tkstanczak any ideas? Is it possible to see why it's rejected? You have the config in the log file, and the actual chain can be found here: https://github.com/ethereum/hive/tree/master/simulators/ethereum/sync/simplechain .
So even without running hive, it should be fairly simple to just init with the genesis and import the blocks, and see why it fails.
After digging into the code a bit, the result CannotAccept does not mean that the block was bad, it means that nethermind was in a state where it was unable to accept blocks.
Specifically, you have this thing: https://github.com/NethermindEth/nethermind/blob/master/src/Nethermind/Nethermind.Blockchain/BlockTree.cs#L1548
internal void BlockAcceptingNewBlocks()
{
Interlocked.Increment(ref _canAcceptNewBlocksCounter);
}
internal void ReleaseAcceptingNewBlocks()
{
Interlocked.Decrement(ref _canAcceptNewBlocksCounter);
}
It's an atomic counter, and when you check it, you want it to be zero, otherwise it's interpreted as CannotAccept.
However, the reader for that does not use the Interlocked API to do an atomic read (https://github.com/NethermindEth/nethermind/blob/master/src/Nethermind/Nethermind.Blockchain/BlockTree.cs#L97) :
private int _canAcceptNewBlocksCounter;
public bool CanAcceptNewBlocks => _canAcceptNewBlocksCounter == 0;
The docs however, say that
The Read method is unnecessary on 64-bit systems, because 64-bit read operations are already atomic. On 32-bit systems, 64-bit read operations are not atomic unless performed using Read.
So this is probably not the cause of the issues, as AFAIK hive runs on a 64-bit system.
This is fixed now.