Shulou(Shulou.com)06/02 Report--

This article mainly introduces "the reasons for the emergence of Bytom blocks and the introduction of related operations". In daily operation, I believe many people have doubts about the reasons for the emergence of Bytom blocks and the introduction of related operations. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts of "the reasons for the emergence of Bytom blocks and the introduction of related operations". Next, please follow the editor to study!

Solitary block introduces what an isolated block is.

When a node receives a valid block and its parent block is not found in the existing main chain, the block is considered an "isolated block". The parent block is the hash value that the PreviousBlockHash field of the current block points to the previous block.

Received chunks are stored in the chunk pool until their parent block is received by the node. Once the parent block is received, the node takes the block out of the orphan pool and connects it to its parent block as part of the blockchain.

The reason for the occurrence of isolated blocks

When two or more blocks are dug out in a very short time interval, the nodes may receive them in different order, and the isolated block phenomenon will occur.

We assume that there are three blocks with heights of 100, 101 and 102 respectively, which are received by the node in the reverse order of 102, 101 and 100, respectively. At this point, the nodes put 102 and 101 into the isolated block management cache pool, waiting for each other's parent blocks. When a block with a height of 100 is synchronized in, the block and transaction are verified and then stored on the block chain. At this time, a recursive query is made on the isolated block cache pool, 101 blocks are found according to blocks with a height of 100 and stored on the block chain, and 102 blocks are found and stored on the block chain according to blocks with a height of 101.

Isolated block source code analysis isolated block management cache pool structure

Protocol/orphan_manage.go

Type OrphanManage struct {orphan map [bc.Hash] * types.Block prevOrphans map [bc.Hash] [] * bc.Hash mtx sync.RWMutex} func NewOrphanManage () * OrphanManage {return & OrphanManage {orphan: make (map [bc.Hash] * types.Block), prevOrphans: make (map [bc.Hash] [] * bc.Hash),}}

Orphan stores isolated blocks, and key is block hash,value and block structure.

PrevOrphans stores the parent block of an isolated block

Mtx mutex to protect map structure to keep data consistent in multiple concurrent read and write states

Add an orphan to the cache pool func (o * OrphanManage) Add (block * types.Block) {blockHash: = block.Hash () o.mtx.Lock () defer o.mtx.Unlock () if _, ok: = o.orphan [blockHash] Ok {return} o.orphan [blockHash] = block o.prevOrphans [block.PreviousBlockHash] = append (o.prevOrphans [block.PreviousBlockHash], & blockHash) log.WithFields (log.Fields {"hash": blockHash.String (), "height": block.Height}) .Info ("add block to orphan")}

When an isolated block is added to the cache pool, the parent block hash of the isolated block also needs to be recorded. Query for parent block hash

Query func (o * OrphanManage) Get (hash * bc.Hash) (* types.Block, bool) {o.mtx.RLock () block, ok: = o.orphan [* hash] o.mtx.RUnlock () return block, ok} func (o * OrphanManage) GetPrevOrphans (hash * bc.Hash) ([] * bc.Hash, bool) {o.mtx.RLock () prevOrphans Ok: = o.prevOrphans [* hash] o.mtx.RUnlock () return prevOrphans, ok} Delete the isolated block func (o * OrphanManage) Delete (hash * bc.Hash) {o.mtx.Lock () defer o.mtx.Unlock () block, ok: = o.orphan [* hash] if! ok {return} delete (o.orphan, * hash) prevOrphans Ok: = o.prevOrphans [block.PreviousBlockHash] if! ok | | len (prevOrphans) = = 1 {delete (o.prevOrphans, block.PreviousBlockHash) return} for I, preOrphan: = range prevOrphans {if preOrphan = = hash {o.prevOrphans [block.PreviousBlockHash] = append (prevOrphans [: I], Orphans [I + 1:]...) Return}

In the process of deleting an isolated block, the parent block is also deleted

Solitary block processing logic

Protocol/block.go

Func (c * Chain) processBlock (block * types.Block) (bool, error) {blockHash: = block.Hash () if c.BlockExist (& blockHash) {log.WithFields (log.Fields {"hash": blockHash.String (), "height": block.Height}). Info ("block has been processed") return c.orphanManage.BlockExist (& blockHash), nil} if parent: = c.index.GetNode (& block.PreviousBlockHash) Parent = = nil {c.orphanManage.Add (block) return true, nil} if err: = c.saveBlock (block); err! = nil {return false, err} bestBlock: = c.saveSubBlock (block) / /.}

The processBlock function handles the process before a block block is added to the blockchain.

C.BlockExist determines whether the current block block exists on the block chain or in the isolated block cache pool, and returns if it does.

C.index.GetNode determines whether the parent node of the block block exists. If its parent block is not found in the existing main chain, the block block is added to the orphaned cache pool.

C.saveBlock has come to this step to show that the block parent node exists in the block chain, then the block block is stored in the block chain. This function verifies the validity of blocks and transactions.

The saveSubBlock code is as follows:

Func (c * Chain) saveSubBlock (block * types.Block) * types.Block {blockHash: = block.Hash () prevOrphans, ok: = c.orphanManage.GetPrevOrphans (& blockHash) if! ok {return block} bestBlock: = block for _, prevOrphan: = range prevOrphans {orphanBlock Ok: = c.orphanManage.Get (prevOrphan) if! ok {log.WithFields (log.Fields {"hash": prevOrphan.String ()}) .Warning ("saveSubBlock fail to get block from orphanManage") continue} if err: = c.saveBlock (orphanBlock) Err! = nil {log.WithFields (log.Fields {"hash": prevOrphan.String (), "height": orphanBlock.Height}). Warning ("saveSubBlock fail to save block") continue} if subBestBlock: = c.saveSubBlock (orphanBlock); subBestBlock.Height > bestBlock.Height {bestBlock = subBestBlock}} return bestBlock}

SaveSubBlock queries the isolated block cache pool for the existence of the next block of the current block. For example, if the current block height is 100, query whether there is a block with a height of 101 in the isolated block cache pool. If present, the 101 block is stored in the block chain and removed from the orphan cache pool.

SaveSubBlock is an implementation of a recursive function. The aim is to find the recursive way of the deepest leaf node. For example, if the current block height is 100, recursively query the blocks with heights of 99, 98, 97 and so on.

At this point, the study of "the reasons for the emergence of Bytom isolated blocks and the introduction of related operations" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.