eea386e4e9
This modifies the chain logic to create and store version 2 block
filters for all new blocks and also adds code to migrate the database to
retroactively create and store the v2 filters for all historical blocks.
Since this requires a database upgrade and the next release of the
software will include a vote to change the consensus rules, this also
takes the opportunity to unmark all blocks previously marked as having
failed validation so they are eligible for validation again under what
will likely become new consensus rules. This ensures clients that did
not update prior to new rules activating are able to automatically
recover under the new rules without having to download the entire chain
again.
The following is a high level overview of the changes:
- Introduce a new database bucket to house v2 block filters
- Make UtxoViewpoint satisfy the PrevScripter interface so it may be
used as a source previous scripts when creating filters
- Create and store the new filters in the db when connecting blocks
- Introduce exported function named FilterByBlockHash to retrieve the
new block filters so they are available to be served in the future
- Implement database migration code to retroactively create the new
filters for all historical blocks
- Bump the chain database version to 6
- Introduce code to allow spent txout entries from the spend journal
to be used as a source of previous scripts to significantly optimize
the filter creation as compared to what would be required to
reconstruct all the utxo views as of each block
- Mark all blocks that failed validation under the current consensus
rules as eligible for validation again
- Export a new constant named HeaderCmtFilterIndex which indicates the
header proof index for the upcoming filter header commitment
|
||
|---|---|---|
| .. | ||
| chaingen | ||
| fullblocktests | ||
| indexers | ||
| internal | ||
| stake | ||
| standalone | ||
| testdata | ||
| accept.go | ||
| agendas_test.go | ||
| bench_test.go | ||
| blockindex_test.go | ||
| blockindex.go | ||
| chain_test.go | ||
| chain.go | ||
| chainio_test.go | ||
| chainio.go | ||
| chainquery.go | ||
| chainview_test.go | ||
| chainview.go | ||
| checkpoints.go | ||
| common_test.go | ||
| compress_test.go | ||
| compress.go | ||
| difficulty_test.go | ||
| difficulty.go | ||
| doc.go | ||
| error_test.go | ||
| error.go | ||
| example_test.go | ||
| fullblocks_test.go | ||
| fullblocksstakeversion_test.go | ||
| go.mod | ||
| go.sum | ||
| headercmt.go | ||
| log.go | ||
| mediantime_test.go | ||
| mediantime.go | ||
| notifications.go | ||
| process.go | ||
| prune.go | ||
| README.md | ||
| scriptval.go | ||
| sequencelock_test.go | ||
| sequencelock.go | ||
| stakeext.go | ||
| stakenode.go | ||
| stakeversion_test.go | ||
| stakeversion.go | ||
| subsidy.go | ||
| thresholdstate_test.go | ||
| thresholdstate.go | ||
| timesorter_test.go | ||
| timesorter.go | ||
| upgrade.go | ||
| utxoviewpoint.go | ||
| validate_test.go | ||
| validate.go | ||
| votebits_test.go | ||
| votebits.go | ||
blockchain
Package blockchain implements Decred block handling and chain selection rules.
The test coverage is currently only around 60%, but will be increasing over
time. See test_coverage.txt for the gocov coverage report. Alternatively, if
you are running a POSIX OS, you can run the cov_report.sh script for a
real-time report. Package blockchain is licensed under the liberal ISC license.
There is an associated blog post about the release of this package here.
This package has intentionally been designed so it can be used as a standalone package for any projects needing to handle processing of blocks into the decred block chain.
Installation and Updating
$ go get -u github.com/decred/dcrd/blockchain
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
- Save the most recent orphan blocks for a limited time in case their parent blocks become available
- Stop processing if the block is an orphan as the rest of the processing depends on the block's position within the block chain
- 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
Examples
- ProcessBlock Example Demonstrates how to create a new chain instance and use ProcessBlock to attempt to add a block to the chain. This example intentionally attempts to insert a duplicate genesis block to illustrate how an invalid block is handled.
License
Package blockchain is licensed under the copyfree ISC License.