f140d33745
This decouples and removes the orphan handling from blockchain in favor
of implementing it in the block manager as part of the overall effort to
decouple the connection code from the download logic.
The change might not make a ton of sense in isolation, since there is no
major functional change, however, decoupling the orphan handling
independently helps make the review process easier and alleviates what
would otherwise result in additional intermediate code to handle cases
that ultimately will no longer exist.
The following is a high level overview of the changes:
- Introduce blockchain function to more easily determine if an error is
a rule error with a given error code
- Move core orphan handling code from blockchain to block manager
- Move data structures used to cache and track orphan blocks
- Move all functions releated to orphans
- BlockChain.IsKnownOrphan -> blockManager.isKnownOrphan
- BlockChain.GetOrphanRoot -> blockManager.orphanRoot
- BlockChain.removeOrphanBlock -> blockManager.removeOrphanBlock
- BlockChain.addOrphanBlock -> blockManager.addOrphanBlock
- Implement orphan handling in block manager
- Rework to use the moved functions and data structs
- Add check for known orphans in addition HaveBlock calls to retain
the same behavior
- Modify the semantics of the process block func exposed by the block
manager so that it no longer stores orphans since all consumers of
it ultimately reject orphans anyway
- Remove remaining orphan related code from blockchain
- Update ProcessBlock to return an error when called with an orphan
- Remove additional orphan processing from ProcessBlock
- Remove orphan cache check from HaveBlock
- Adjust example to account for the removed parameter
- Change chaingen harness tests to detect orphans via returned error
- Modify fullblock tests to detect orphans via returned error
- Adapt process order logic tests to cope with lack of orphan
processing
- Update all other tests accordingly
- Update various comments and the README.md and doc.go to properly
reflect the removal of orphan handling
66 lines
3.4 KiB
Go
66 lines
3.4 KiB
Go
// Copyright (c) 2013-2014 The btcsuite developers
|
|
// Copyright (c) 2015-2016 The Decred developers
|
|
// Use of this source code is governed by an ISC
|
|
// license that can be found in the LICENSE file.
|
|
|
|
/*
|
|
Package blockchain implements Decred block handling and chain selection rules.
|
|
|
|
The Decred block handling and chain selection rules are an integral, and quite
|
|
likely the most important, part of decred. At its core, Decred is a distributed
|
|
consensus of which blocks are valid and which ones will comprise the main block
|
|
chain (public ledger) that ultimately determines accepted transactions, so it is
|
|
extremely important that fully validating nodes agree on all rules.
|
|
|
|
At a high level, this package provides support for inserting new blocks into the
|
|
block chain according to the aforementioned rules. It includes functionality
|
|
such as rejecting duplicate blocks, ensuring blocks and transactions follow all
|
|
rules, and best chain selection along with reorganization.
|
|
|
|
Since this package does not deal with other Decred specifics such as network
|
|
communication or wallets, it provides a notification system which gives the
|
|
caller a high level of flexibility in how they want to react to certain events
|
|
such as newly connected main chain blocks which might result in wallet updates.
|
|
|
|
Decred Chain Processing Overview
|
|
|
|
Before a block is allowed into the block chain, it must go through an intensive
|
|
series of validation rules. The following list serves as a general outline of
|
|
those rules to provide some intuition into what is going on under the hood, but
|
|
is by no means exhaustive:
|
|
|
|
- Reject duplicate blocks
|
|
- Perform a series of sanity checks on the block and its transactions such as
|
|
verifying proof of work, timestamps, number and character of transactions,
|
|
transaction amounts, script complexity, and merkle root calculations
|
|
- Compare the block against predetermined checkpoints for expected timestamps
|
|
and difficulty based on elapsed time since the checkpoint
|
|
- Perform a series of more thorough checks that depend on the block's position
|
|
within the block chain such as verifying block difficulties adhere to
|
|
difficulty retarget rules, timestamps are after the median of the last
|
|
several blocks, all transactions are finalized, checkpoint blocks match, and
|
|
block versions are in line with the previous blocks
|
|
- Determine how the block fits into the chain and perform different actions
|
|
accordingly in order to ensure any side chains which have higher difficulty
|
|
than the main chain become the new main chain
|
|
- When a block is being connected to the main chain (either through
|
|
reorganization of a side chain to the main chain or just extending the
|
|
main chain), perform further checks on the block's transactions such as
|
|
verifying transaction duplicates, script complexity for the combination of
|
|
connected scripts, coinbase maturity, double spends, and connected
|
|
transaction values
|
|
- Run the transaction scripts to verify the spender is allowed to spend the
|
|
coins
|
|
- Insert the block into the block database
|
|
|
|
Errors
|
|
|
|
Errors returned by this package are either the raw errors provided by underlying
|
|
calls or of type blockchain.RuleError. This allows the caller to differentiate
|
|
between unexpected errors, such as database errors, versus errors due to rule
|
|
violations through type assertions. In addition, callers can programmatically
|
|
determine the specific rule violation by examining the ErrorCode field of the
|
|
type asserted blockchain.RuleError.
|
|
*/
|
|
package blockchain
|