---
# System prepended metadata

title: 'Problem Description:'

---

# Problem Description:
In getWork API we can't match parentHash because vanguard doesn't have any trace on pandora block.

In beaconBlock body we save pandora sharding information. They are:
```go  
       BlockNumber          uint64   `protobuf:"varint,1,opt,name=block_number,json=blockNumber,proto3" json:"block_number,omitempty"`
	Hash                 []byte   `protobuf:"bytes,2,opt,name=hash,proto3" json:"hash,omitempty" ssz-size:"32"`
	ParentHash           []byte   `protobuf:"bytes,3,opt,name=parent_hash,json=parentHash,proto3" json:"parent_hash,omitempty" ssz-size:"32"`
	StateRoot            []byte   `protobuf:"bytes,4,opt,name=state_root,json=stateRoot,proto3" json:"state_root,omitempty" ssz-size:"32"`
	TxHash               []byte   `protobuf:"bytes,5,opt,name=tx_hash,json=txHash,proto3" json:"tx_hash,omitempty" ssz-size:"32"`
	ReceiptHash          []byte   `protobuf:"bytes,6,opt,name=receipt_hash,json=receiptHash,proto3" json:"receipt_hash,omitempty" ssz-size:"32"`
	Signature            []byte   `protobuf:"bytes,7,opt,name=signature,proto3" json:"signature,omitempty" ssz-size:"96"`
	
```


Block production steps:

1. validator -> beacon-chain: getBlock() return newBeaconBlock
2. validator -> beacon-chain: getCanonicalPandoraShardInfo() return pandoraShardInfo
    a. beacon-chain retrieves head block from blockchain then retrieve pandora shard info from beacon block body and sends it to validator.
    b. validator retrieves parentHash and block number from pandora shard info. 
    
    That means, Let ***n*** be the current block number in pandora chain. Which is not minned yet. In validator we are getting sharding info of block number ***n - 1***. And thus, we are getting parentHash of ***n - 1*** in the sharding info which is the hash of the block number ***n - 2***. 
    c. validator add 1 with block number which is the current block number.
4. validator -> pandora: getWork(parentHash, curBlockNumber) return header, sealHash
    a. pandora checks the block number with it's new block number
    b. try to match parentHash with new header's parentHash. But this will not match because we can't get pandora block in vanguard side. Thus, we can't generate block body hash which is also known as parentHash.
    d. pandora sends header and sealHash then validator signs on sealHash.
6. validator -> pandora: submitWork(signature) return true
    a. pandora checks signature and return true.
    b. If submit work is successfull then, validator create pandora shard info using header info and store it into beaon block body.
    c. validator signs beacon block.
8. validator -> beacon-chain: proposeBlock(signedBeaconBlock) return nil


# Proposal: 
We can try to match the HeaderHash of ***n-1*** block (Current block of canonical chain) not the parentHash. 

But here we will also face some coding issues. Like, currently there is no blockchain reference in the consensus package. So,when we call the getWork API we can't get the current block of the canonical chain.


We can retrieve the info from miner package and pass it to consensus package. But first we need to do some R&D about this approach.
