# Theory behind Hydra fork
Randez-vous: Point where Pandora and Vanguard align to match LUKSO consensus.
They are consecutive:
`BCS(p)` => pandora block height when beacon-chain started. `BCS(p) >= 0`, `BSC(p) <= RV(p)`
`RV(p)` => pandora block height for randez-vouz
`RV(v)` => vanguard block height for randez-vous

`SI(v)` => sharding info of vanguard block height, where `SI` contains properties: `blockNumber, parentHash, stateRoot, transactionHash, sealHash, receiptHash, signature`
`SIbn(v)` => function to retrieve block number of sharding info
`SIh(v)` => function to retrieve hash of sharding info
`SIph(v)` => function to retrieve parent hash of sharding info block height

`LenV(n, m)` => function to retrieve vanguard block count in range, where `n > RV(v)`; `m > n`; therfore `n,m` => `(0, +∞)`, basically `LenV(m,m ) = m-n`.

## Hydra fork restriction:

Pandora genesis: point in time when pandora (geth) started to produce any blocks. They might now be consistent in terms of geth engine. Let there be pandora block ranges: `r'p1 = (0, RV(p))`, `r'p2 = (RV(p) + 1, +∞)`, where `r'p1` => `ethash`, `r'p2` => `pandora`.
In fact it does not matter what engine was running before pandora as long as blocks are compatible and able to be verified.

Vanguard genesis: point in time when vanguard (prysm) started to produce any blocks. They might be consistent in terms of CASPER engine. Let there be vanguard block ranges `r'v1 = (0, RV(v)`, `r'v2 = (RV(v) + 1, +∞)`, where `r'v1` => `CASPER FFG`, `r'v2` => `FFG Hydra fork protection`. In fact it does not matter what engine was running before hydra as long as blocks are compatible and able to be verified in terms of FFG.

## Hypothesis of matching block len
Let `x,y` be a positive integer, where `x,y > 0`; `x,y => +∞`; `x > RV(p)` ; `y > RV(v)`
`x` => pandora sharding block height
`y` => vanguard consensus block height
`σ` => relation of vanguard block to pandora shard, describes how many shards are inserted into vanguard sharding info. Its a constant `σ => (1, 64)`.

### Math hypothesis
`SIbn(y) = LenV(RV(v), y) * σ + RV(p)`
`SIbn(y) - RV(p) = LenV(RV(v), y) * σ`
`LenV(RV(v), y) = (SIbn(y) - RV(p)) / σ`
`SIph(y) = SIh(y - σ)`

### Calculations
**L15 setup**
Let:
`σ = 1`
`RV(v)` = `0`
`RV(p)` = `0`

Therefore:
`SIbn(y) = LenV(0, y)`
**`SIbn(y) = y`**
`SIph(y) = SIh(y-1)`

When:
`y = 150`
`SIbn(y) = 150`
`SIph(y) = SIh(149)`

**SILESIACOIN setup**
Let:
`σ = 1`
`RV(v)` = `0`
`RV(p)` = `4500000`

Therefore:
`SIbn(y) = LenV(0, y) + 4500000`
`LenV(0, y) = SIbn(y) - 4500000`
When:
`y = 150`
`SIbn(y) = 4500150`

**Possible Ethereum mainnet-like setup** (already running both exec + beacon)
Let:
`σ = 1`
`BSC(p) = 11363270`
`RV(p) = 13537043`
`RV(v) = 201567`
Therefore:
`SIbn(y) = LenV(201567, y) + 13537043`
When:
`y = 201667`
`LenV(201567, 201667) = 100`
`SIbn(y) = LenV(201567, 201667) + 13537043`
`SIbn(y) = 13537143`

**Sigma == 64** (64 shards starting at same point)
Let:
`σ = 64`
`BSC(p) = 0`
`RV(p) = 0`
`RV(v) = 0`

Therefore:
`SIbn(y) = Len(0, y) * 64`
When:
`y = 201`
`SIbn(y) = LenV(0, 201) * 64`
`SIbn(y) = 12864`

## Conclusion
Before Vanguard insert any block with sharding info into its database it must assure that:
- `SIbn(y) = LenV(RV(v), y) * σ + RV(p)`
- `SIph(y) = SIh(y - σ)`

#### Further R&D
Very possible, that setup will grow with shards over time, and not all at once which means that `σ` will be increasing over time, thus equasion will break. There might need to derive more generic equation to **match σ changing over liveness of the chain.**