Pandora and Vanguard orchestration when producing a new block.
Orchestrator - client written in go. Its responsibility is to orchestrate the Pandora and Vanguard to verify blocks.
Pandora - modified fork of go-ethereum (geth). Responsible to create valid execution blocks. P2P is enabled to share txpool and propagate blocks. It requires symbiotic connection with the orchestrator/validator client.
Vanguard - modified fork of prysm client. Responsible to run consensus algorithm (CASPER) with add execution layer data for shard0.
Clients should be connected via IPC socket (secure) or HTTPS(troublesome).
Pandora is having sub-network of p2p (execution layer)
Vanguard is having sub-network of p2p (consensus layer)
common:
connections:
orc > van
untrusted pan > orc
// CONSENSUS INFO SYNC
1. ☑️ orc > van: get validator list (committee) of epoch(s):
(OVER PUSH, WSS/IPC; `van_subscribe`; params; ['minimalConsensusInfo', {fromEpoch: number}]
-> {... "result":"0xcd0c3e8af590364c09d0fa6a1210faf5"}
notification: {..., "method":"van_subscribe","params": {"subscription":"0xcd0c3e8af590364c09d0fa6a1210faf5","result": {
"epoch": 0,
"validatorList": ["BLS_KEY1", "BLS_KEY2", ...], // turn 0-31
"epochTimeStart": 1615845764,
"slotTimeDuration": 6,
"reorg": {
vanguard: "0xparentHashOfVanguard"
pandora: "0xparentHashOfPandora"
},
finalizedEpoch: epochNumber
}})) // fires for each information set
// connection: multiple untrusted pan > orc
// CONSENSUS INFO SYNC
// when pandora restarts, it can ask if thge last known block is still valid; IF NOT, go to the previous epcoch and ask again, and so on ...
2. 🦺 pan > orc : orc_isValidBlock({slot: 1, hash: blockHash}) > TRUE/FALSE
3. ☑️ pan > orc : get validator list (committee) of epoch(s):
(OVER PUSH, WSS/IPC; `orc_subscribe`; params; ['minimalConsensusInfo', {fromEpoch: number}]
-> {... "result":"0xcd0c3e8af590364c09d0fa6a1210faf5"}}
notification: {..., "method":"orc_subscription","params": {"subscription":"0xcd0c3e8af590364c09d0fa6a1210faf5","result": {
"epoch": 0,
"validatorList": ["BLS_KEY1", "BLS_KEY2", ...], // turn 0-31
"epochTimeStart": 1615845764,
"slotTimeDuration": 6
}})) // fires for each information set
block verifcation:
connections:
orc c> trusted pan
orc c> van
1. ☑️ van: receives block and verifies it
- stores it in queue
3. ☑️ pan: receives block // SLASH?
- checks BLS signature: val is in committee
- hash the block header without extraData, and compare it to signed BLS hash
- stores it in queue
// BLOCK INFO SYNC
4. ☑️ van i> orc: block received
(OVER PUSH, WSS/IPC; `van_subscribe`; params; ['newPendingBlockHeaders']
-> {... "result":"0xcd0c3e8af590364c09d0fa6a1210faf5"}}
notification: {..., "method":"van_subscription","params":{"subscription":"0xcd0c3e8af590364c09d0fa6a1210faf5","result":{"difficulty":"0xd90b1a7ad02", <...>}}))
6. ☑️ pan i> orc: exec block(s) received
(OVER PUSH, WSS/IPC; `eth_subscribe`; params; ['newPendingBlockHeaders', {fromBlockHash: hash}])
-> {... "result":"0xcd0c3e8af590364c09d0fa6a1210faf5"}}
notification: {..., "method":"eth_subscribe","params":{"subscription":"0xff0c3e8af590364c09d0fa6a1210fadd","result":{"difficulty":"0xd90b1a7ad02", <...>}}))
ORC needs to wait for block from VAN and PAN
7. ☑️ orc: compare exec blocks to consensus blocks // SLASH?
- orc has consensus blocks, and exec blocks
- map exec blocks to consensus blocks
- compare slots
- compare epoch
- compare BLS sig
- compare timestamp
- compare TBD
8. ☑️ orc: store blockHashes in DB // necessary for syncing (ask for batches of blocks)
blockHash[slotNumber: {vanBlockHash, panBlockHash}]
finalizedEpoch: epochNumber1234
// BLOCK CONFIRMATION
// potentially a WSS/IPC subscription
9. ☑️ pan > orc : confirmBlockBatch: 'orc_confirmPanBlockHashes', params: [[{slot: 1, hash: blockHash},...]]
> [{slot: 1, status: 'pending'}, {slot: 2, status: 'verified'}, {slot: 3, status: 'unknown'}, ...]
10. ☑️ van > orc : confirmBlockBatch: 'orc_confirmVanBlockHashes', params: [[{slot: 1, hash: blockHash},...]]
> [{slot: 1, status: 'pending'}, {slot: 2, status: 'verified'}, {slot: 3, status: 'unknown'}, ...]
// BLOCK CONFIRMATION to VAN (DEPRECATED)
// 10. 🦺 orc > van: notify about valid consensus block: WSS/IPC: JSONRPC method call 'van_confirmBlock', params[{
// slot: 123,
// blockHash: 'blockHash',
// status: 'verified'
// }]
slashing:
by pan
1. pan > orc: block invalid, but signed by validator
2. orc > slasher: please slash val X, here is the proof
by orc
1. orc: blocks didn't compare, or not the vals turn/slot
2. orc > slasher: please slash val X, here is the proof
no exec block
1. orc: hasn't received a exec block from pan in n seconds
2. orc > slasher: please slash val X, here is the proof
block production (validator):
connections: van > val val > pan
1. ☑️ van > val: please sign block
2. ☑️ val > pan: prepareBlock (eth_getWork)
3. ☑️ pan > val: here is the prepared exec block (response of eth_getWork)
4. ☑️ val: verifies block hash without BLS, signs with BLS
- get parentHash from previous slot and check with given parentHash
- generate timestamp
- generate coinbase
- generate blockNumber
- insert randao into "nonce"?
7. ☑️ val: generate final exec blockhash, and add it sharding part
8. ☑️ val: signs block
9. ☑️ val > van: sends signed block
10. ☑️ van: propagates block
11. ☑️ val > pan: construct final block with data (extraData with BLS, timestamp, block number, etc) we give him (eth_submitWorkBLS)
12. ☑️ pan: propagates exec block
Block reversal flow: (Proposed by @frozeman )