# Revert flow in Pandora

First of all we need to find a difference between `setHead` and `reorg`. Both moves the chain head to our desired position. `setHead` will delete *blockBody* and *blockHead* from the database. `reorg` will move the chainhead to our desired position (new block number) and don't delete any block information.

So our `revert` function works exactly like `reorg`. Just give a desired position, it will move the chainHead to that position and delete older transactions (from transaction dB to make them invalid) and don't delete older block information.

## Example of our revert function:
Let our chainHeight = 100
our desired position = 50

revert will collect all transactions from 51 to 100. Remove them from `TxLookupEntry` database. Set head to 50.

That's it in short. (not describing the coding details)

## Transaction restoration
In order understand transaction pool reorg we need to under two things.
1. How pandora downloads blocks
2. How pandora tx_pool reorg works

### How pandora downloads blocks:
1. Find our localchain height and remote chain height
2. Find common ancestor (`CA`)
3. Start downloading from `CA + 1`

#### How CA works?
Find a position where two blocks are generated from a block. I mean where the chain splitted. And also determine if that block state and block information is already present there. If block information is intact then don't download it.

##### Example of download
localChainHeight = 50 (after revert)
RemoteChainHeight = 110

Common ancestor????
It's interesting....
Common ancestor = 100

How? In revert we didn't delete blocks so CA finds that it has block `100` in the databse.

So download will start from 101 to 110.

### How pandora tx_pool reorg works
1. it holds chainHead. (in our case 100) before revert chainHead was 100 and tx_pool doesn't know about reorg or revert.
2. If `chainHeadFeed` gets any message then tx_pool reorg is triggered.
3. `chainHeadFeed` receives message when any new block is minned or downloaded and inserted into the databse. (`writeBlockWithState` and `insertChain` to be specific)
4. If `chainHeadFeed` event finds that any new block is received and previousChainHead is not a parent of this newly received block then tx_pool understands a reorg has happended.
5. So it collects all transactions from previousChainhead to common ancestor and push them again to the tx_pool as they will be deleted.

### Why we have not moved our chain to finalized slot
A common idea is to revert our chain to the finalized slot. So if reorg event received we can do that. But we have not done it. Let's check a scenario so that we can explain the reason:

pandoraHead = 100
FinalizedSlotBlock = 50
tx_poolHead = 100 // on chainHeadEvent tx_pool set block#100 as Head

// if we move our pandoraHead to finalized slot then
pandoraHead = 50
tx_poolHead = 100 // we just moved into same chain. no new block received yet

// download process triggered
remoteHeight = 110
localHeight = 50
commonAncestor = 100 // cause? Because common ancestor finds that 51 - 100 is already present in the database.

// download will start from 101 and tx_pool finds that 100 is parent of 101.
// so no tx reversal will happen

#### Why sharding parentHash will work:

pandoraHead = 100
reorgParentHashBlock = 50
tx_poolHead = 100

// if we move our pandora to reorgParentHashBlock then
pandoraHead = 50
tx_poolHead = 100

// now download process triggered.
// it finds taht from block#51 new hash exists. So 
remoteHeight = 110
localHeight = 50
commonAncestor = 50

// download will trigger from 51 to 110
// default tx_Pool reorg will be triggered.