kravitz-stability-check

kravitzCheck.MD

Version of tags running

pandora: v0.1.0-rc.1 vanguard: v0.1.0-rc.3-kravitz validator: v0.1.0-rc.3-kravitz orchestrator: v0.1.0-rc.1

Node setup must be able to:

• synchronize to any network of ours up to the head (dev, staging, prod)
• produce blocks during network lifecycle
• form a new network from scratch and start its own block progression
• withstand the reorg on the vanguard side
• withstand the reorg on the pandora side
• reach the finalization and justification on consensus layer
• talk to the tools (explorers, ethstats)
• take and withstand insane amount of tx on Pandora side (fill the gas limit to max)
• join new validators from deposit contract
• voluntrary exit validators from deposit contract
• start and progress with non-interop mode

Regression spotted during sync, tags with rc1 are able to better synchronize in initial sync
Possible sync regression candidadtes:

• onBlockBatch (verification must be done slightly different, consecutiveness must check only batch, not compare it to head, because of round-robin sync)
• onBlockBatch && onBlock -> same as above, but might be that onBlock also need to not compare against db (I doubt it)

Possible network split reason:

• broken sync
• lack of verification of shard signatures in vanguard blocks (most likely)

Possible solutions:
Sol.1: rearange checks into different places, provide unique check for onBlockBatch to increase speed of initial sync
Sol.2: Complete implementation of shard signature verification

Ad. Sol.1