---
# System prepended metadata

title: Untitled

---

Solve Network Sync:

disconnected node:
s: 876 b: 734 (synced) vangaurd + pandora
s: 878 b: 734 (check in validator) ()
s: 877 b: 735



## Example:
Vanguard node: 
- in canonical chain, b: 499 at slot: 503
- disconnected sometime and missed slot:504 
- generates b: 500 at slot: 505 (already verified and saved into canonical chain)
- gets b: 500 at slot: 504 from network (save into canonical chain and pandora also save into side chain)
- 504 has proper parent hash into canonical chain but 506, 507
- Any slot after 505, node rejects those slots from peer. Only accept its own blocks.

How does van node resolve this issue?





## Todo:
- Checking parent hash and block number in `GetShardingWork` api in `consensus/pandora/api.go`
- Checking parent hash and block number with canonical pandora sharding info in `validator/cliet/pan_propose.go` and `beacon-chain/blockchain/van_process_pending_blocks.go`
- Time based implementation.
- Need to send confirmation notification when any header hash already in verified db in orchestrator (`orchestrator/pandorachain/handler.go`)
- 

## Investigation:
- Why vanguard does not re-download the invalid slot when orchestrator gives pending or invalid status.
- What happens when pandora downloads chain from network.


## Issues:
 - Lukso-6 orchestrator can't get any further block from lukso-10 vanguard after sync.
 - Lukso-10 vanguard generated seperate epoch info for epoch-110. It is not same as the other vanguard nodes.