Investigate which node is making the network crash

[cducrest]

Find out the source of timestamp overflow. Perhaps a single validator is responsible for all the wrong blocks, find out if the block is actually wrong and unused.

[cducrest]

Crashed at block 2707093 http://blockexplorer.trustlines.foundation/blocks/2707093/transactions
Crashed at block 2707888 http://blockexplorer.trustlines.foundation/blocks/2707888/transactions
Crashed at block 2708038 http://blockexplorer.trustlines.foundation/blocks/2708038/transactions
Crashed at block 2757105 http://blockexplorer.trustlines.foundation/blocks/2757105/transactions

[saschagoebel]

@cducrest @schmir-at-bb : How sure are we, that this was actually a chain problem and not a problem with the blockexplorer? Do we have additional logs to look into?

I've checked for all 4 blocks the previous and following blocks and

• The timestamps are almost exactly 5 seconds apart
• The validators are in the order they are defined in the chainspec
• There are no uncles in the blocks
• The step values are also correct

eth.events SQL: SELECT * FROM block WHERE number IN('2707092', '2707093', '2707094', '2707887', '2707888', '2707889', '2708037', '2708038', '2708039', '2757104', '2757105', '2757106') ORDER BY number

[saschagoebel]

See openethereum/parity-ethereum#10688 (comment)

[ghost]

Bernd already commented on that issue. It looks like system clocks have been off for a bit: openethereum/parity-ethereum#10688 (comment)

I do think this issue doesn't need further work.

[saschagoebel]

The issue has been fixed in openethereum/parity-ethereum#10720 which is just waiting to be merged.

We have to make sure the validator nodes update the time regularly though. Added documentation in this PR #172

[cducrest]

Closing this because it no longer makes sense.