fce24223cd
Decred's serialized format for transactions split the 32-bit version field into two 16-bit components such that the upper bits are used to encode a serialization type and the lower 16 bits are the actual transaction version. Unfortunately, when this was done, the in-memory transaction struct was not also updated to hide this complexity, which means that callers currently have to understand and take special care when dealing with the version field of the transaction. Since the main purpose of the wire package is precisely to hide these details, this remedies the situation by introducing a new field on the in-memory transaction struct named SerType which houses the serialization type and changes the Version field back to having the desired semantics of actually being the real transaction version. Also, since the maximum version can only be a 16-bit value, the Version field has been changed to a uint16 to properly reflect this. The serialization and deserialization functions now deal with properly converting to and from these fields to the actual serialized format as intended. Finally, these changes also include a fairly significant amount of related code cleanup and optimization along with some bug fixes in order to allow the transaction version to be bumped as intended. The following is an overview of all changes: - Introduce new SerType field to MsgTx to specify the serialization type - Change MsgTx.Version to a uint16 to properly reflect its maximum allowed value - Change the semantics of MsgTx.Version to be the actual transaction version as intended - Update all callers that had special code to deal with the previous Version field semantics to use the new semantics - Switch all of the code that deals with encoding and decoding the serialized version field to use more efficient masks and shifts instead of binary writes into buffers which cause allocations - Correct several issues that would prevent producing expected serializations for transactions with actual transaction versions that are not 1 - Simplify the various serialize functions to use a single func which accepts the serialization type to reduce code duplication - Make serialization type switch usage more consistent with the rest of the code base - Update the utxoview and related code to use uint16s for the transaction version as well since it should not care about the serialization type due to using its own - Make code more consistent in how it uses bytes.Buffer - Clean up several of the comments regarding hashes and add some new comments to better describe the serialization types |
||
|---|---|---|
| .. | ||
| chaingen | ||
| fullblocktests | ||
| indexers | ||
| internal | ||
| stake | ||
| testdata | ||
| accept.go | ||
| bench_test.go | ||
| blocklocator.go | ||
| chain_test.go | ||
| chain.go | ||
| chainio_test.go | ||
| chainio.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 | ||
| internal_test.go | ||
| log.go | ||
| mediantime_test.go | ||
| mediantime.go | ||
| merkle_test.go | ||
| merkle.go | ||
| notifications.go | ||
| process.go | ||
| prune.go | ||
| README.md | ||
| reorganization_test.go | ||
| scriptval_test.go | ||
| scriptval.go | ||
| stakeext.go | ||
| stakenode.go | ||
| stakeversion_test.go | ||
| stakeversion.go | ||
| subsidy_test.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 attempt add a block to the chain. This example intentionally attempts to insert a duplicate genesis block to illustrate how an invalid block is handled. -
CompactToBig Example
Demonstrates how to convert the compact "bits" in a block header which represent the target difficulty to a big integer and display it using the typical hex notation. -
BigToCompact Example
Demonstrates how to convert how to convert a target difficulty into the compact "bits" in a block header which represent that target difficulty.
License
Package blockchain is licensed under the copyfree ISC License.