How to test chain reorganization with testrpc?

Question

I am working on blockchain synchronization script. I need a way to make reorganization programmatically for testing purposes. Is there such functionality in some testrpc?

Answer 1

I don't know of a way to accomplish that with TestRPC. There might be a better way than described below.

I think I would make a private chain with Geth and low-difficulty/fast blocks in the genesis block.

1. Connect two nodes to each other and make sure both are mining and synchronized. Deploy your contracts, set up accounts and balances (they will each be earning mining rewards) and otherwise get ready for the test - generally, create the initial test conditions.

2. Then, break the connectivity between the nodes. To do that progamatically you could consider stomping on the network configuration. The idea is to create a "split-brain". You can then start submitting transactions to one node or the other, or even both. You can arrange it so Geth on localhost still responds even though connectivity to the other node is lost.

   Since both nodes will be mining, they will each form block histories, but they will be divergent histories.

3. Restore the connection between the nodes and expect reorganization until one canonical history emerges on both nodes.

Hope it helps.

p.s. As an afterthought, a crude variation would be to use three nodes and force one to drop out while two stay connected, with all three mining. That would all but guarantee that conjoined nodes would have the longer chain and the dropped-out node will be the victim of the reorganization. Knowing that in advance might simplify your probing of the results.

Answer 2

It wouldnt be possible to do it with test rpc as it only mints blocks when transactions arrives, and isnt connected to other remote nodes, so there would never be discrepancies between nodes.

We have done this recently using private chains and some chaos tool .. pumba. Pumba will allow you to kill nodes, restart them and introduce latency and drop packets.

Any of these adverse scenarios will result in reorgs once the nodes come back online