frozeman/SymbioticBlockCreation.md

## SymbioticBlockCreation.md

      
    Raw
  

              SymbioticBlockCreation.md
            
          
    Block creation

Pandora and Vanguard orchestration when producing a new block.
Terminology

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.
Connection

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