826d66bb56
Currently, block templates that provide work to PoW miners are generated
in response to them calling the getwork RPC. However, unlike in a pure
PoW system, in Decred, when a new block is connected, a new block
template extending that block can't be generated until the minimum
number of required votes for it has been received. This poses a
challenge for PoW miners because they are typically unaware of when
votes are received. Consequently, miners poll getwork waiting until
they see a new template generated when a new block is connected.
Since only a minimum of 3 votes is required to build a template and new
templates are only generated in response to the miners calling getwork,
as just described, miners often, unfortunately, end up receiving a
template that only has 3 votes and begin working on it. Worse, since
many new miners are not well versed in the intricacies of Decred voting,
they often aren't aware they really need to continue polling for new
votes and immediately switch over to the new template with more votes in
it in order to avoid receiving a reduced subsidy. This often results in
new miners producing blocks with 3 votes.
Moreover, blocks with less than all 5 votes are not only undesirable for
the PoW miners because they receive reduced subsidy, they're also
undesirable for PoS stakers since it means the votes that were not
included don't receive the reward despite having voted simply due to a
propagation delay.
Another issue with the existing approach is that since it takes a bit of
time to generate and validate templates, particularly as the number of
transactions they include rises, miners periodically requesting updated
work to include the latest transactions have to wait for the template to
be built when they call getwork once the existing cached template is
expired. This can result in undesirable delays for them.
In order to address the need to wait for templates to be built in that
case, there was recently some preliminary work that implemented a
background template generator which asynchronously generates templates
in response to events with the intention of allowing access to the
latest one without said random delays in the future.
However, that preliminary work did not address the issues around vote
propagation such as the tendency for miners to end up with the first
block template only containing the 3 fastest-propagating votes, nor did
it have robust handling for all potential corner cases and error
conditions.
Consequently, this overhauls the background block template generator to
add support for intelligent vote propagation handling, handle chain
reorganization to alternative blocks in the case the current tip is
unable to obtain enough votes, provide a subscription for a stream of
template updates, handle template generation errors, consider the
synchronization state as a part of determining if the chain is current,
track the reason for template updates, block current template retrieval
during operations that are in the process of making it stale, and
correct several corner cases.
It should be noted that this only implements the infrastructure and does
not switch getwork or the CPU miner over to use the background templates
yet. This will be done in future commits.
The following is a high-level overview of the semantics this implements:
- Generate new templates immediately when prior to stake validation
height since no votes are required
- Do not generate templates for intermediate blocks during a chain
reorganization
- Do not generate templates before the chain is considered synchronized
- Prefer to create templates with maximum votes through the use of a
timeout once the minimum votes have been received to provide the votes
an opportunity to propagate with a fallback for immediate generation
as soon as all votes are received
- In the case the timeout expires and a template is created with less
than the maximum number of votes, generate a new template
immediately upon receiving more votes for the block it extends
- In the event there are competing blocks at the current tip, prefer to
build a template on the first seen block so long as it receives the
minimum number of required votes within a few seconds
- Generate new templates immediately when a block is disconnected to
support future planned chain invalidation capabilities
- Generate new templates periodically when there are new regular transactions
to include
- Schedule retries in the rare event template generation fails
- Allow clients to subscribe for updates every time a new template is
successfully generated along with a reason why it was generated
- Provide direct access to the most-recently generated template
- Block while generating new templates that will make the current template
stale (e.g. new parent or new votes)
The following is a high-level overview of the changes:
- Initialize PRNG once instead of at every invocation
- Implement an asynchronous queue for all events to ensure normal chain
and vote processing is not blocked
- Provide ability to subscribe for all template updates over a single
channel to ensure none can indadvertently be missed as is possible with
the current design
- Always deliver existing template upon registration
- Drop templates if the receiver falls too far behind in the same way
tickers work
- Introduce tracking the reason for template updates so that it can
ultimately be presented to miners to allow them to make better
decisions about when to force their workers to switch
- Consider the current network sync state when checking if the chain is
current
- Introduce a regen handler state such as timeouts, blocks to monitor
for votes, and the block the next template should extend
- Add logic for selectively reacting to votes on the block the current
template is extending, the current tip, and alternate competing blocks
at the current tip using the aforementioned semantics
- Perform all template generation in separate goroutines with a
cancellable context
- Cancel any in progress templates that are being generated whenever
generating a new one
- Introduce blocking current template retrieval when a new template that
would cause the existing one to become stale is being generated
- Modify periodic regen handling to use a resettable timer for better
efficiency and more fine grained control
- Remove template pool as that is something that should be handled by
the code that is actually handing the templates out
- Rename and export the event notification funcs to make it clear
they're not internal functions and also make it easier to eventually
move the code into the mining package
- Expand and improve comments
- Store and return template generation errors
- Schedule retry in the case of failure
- Correct several cases that were not being handled correctly and some
undesirable behaviors such as block disconnects (as opposed to
reorgs), reorganization to side chains, and notifying with stale
templates
|
||
|---|---|---|
| .github | ||
| addrmgr | ||
| bech32 | ||
| blockchain | ||
| certgen | ||
| chaincfg | ||
| cmd | ||
| connmgr | ||
| database | ||
| dcrec | ||
| dcrjson | ||
| dcrutil | ||
| docs | ||
| fees | ||
| gcs | ||
| hdkeychain | ||
| internal | ||
| lru | ||
| mempool | ||
| mining | ||
| peer | ||
| release | ||
| rpcclient | ||
| rpctest | ||
| sampleconfig | ||
| txscript | ||
| wire | ||
| .dockerignore | ||
| .gitignore | ||
| .travis.yml | ||
| blocklogger.go | ||
| blockmanager.go | ||
| cert_test.go | ||
| CHANGES | ||
| config_test.go | ||
| config.go | ||
| cpuminer.go | ||
| dcrd.go | ||
| doc.go | ||
| Dockerfile | ||
| Dockerfile.alpine | ||
| go.mod | ||
| go.sum | ||
| ipc.go | ||
| LICENSE | ||
| log.go | ||
| mining_test.go | ||
| mining.go | ||
| miningerror.go | ||
| networkparams_test.go | ||
| params.go | ||
| README.md | ||
| rpcserver_test.go | ||
| rpcserver.go | ||
| rpcserverhelp_test.go | ||
| rpcserverhelp.go | ||
| rpcwebsocket.go | ||
| run_tests.sh | ||
| server.go | ||
| service_windows.go | ||
| signal.go | ||
| signalsigterm.go | ||
| upnp.go | ||
dcrd
Decred Overview
Decred is a blockchain-based cryptocurrency with a strong focus on community
input, open governance, and sustainable funding for development. It utilizes a
hybrid proof-of-work and proof-of-stake mining system to ensure that a small
group cannot dominate the flow of transactions or make changes to Decred without
the input of the community. A unit of the currency is called a decred (DCR).
Latest Downloads
What is dcrd?
dcrd is a full node implementation of Decred written in Go (golang).
It acts as a fully-validating chain daemon for the Decred cryptocurrency. dcrd maintains the entire past transactional ledger of Decred and allows relaying of transactions to other Decred nodes around the world.
This software is currently under active development. It is extremely stable and has been in production use since February 2016.
The software was originally forked from btcd, which is a bitcoin full node implementation that is still under active development. To gain the benefit of btcd's ongoing upgrades, including improved peer and connection handling, database optimization, and other blockchain related technology improvements, dcrd is continuously synced with the btcd codebase.
What is a full node?
The term 'full node' is short for 'fully-validating node' and refers to software that fully validates all transactions and blocks, as opposed to trusting a 3rd party. In addition to validating transactions and blocks, nearly all full nodes also participate in relaying transactions and blocks to other full nodes around the world, thus forming the peer-to-peer network that is the backbone of the Decred cryptocurrency.
The full node distinction is important, since full nodes are not the only type of software participating in the Decred peer network. For instance, there are 'lightweight nodes' which rely on full nodes to serve the transactions, blocks, and cryptographic proofs they require to function, as well as relay their transactions to the rest of the global network.
Why run dcrd?
As described in the previous section, the Decred cryptocurrency relies on having a peer-to-peer network of nodes that fully validate all transactions and blocks and then relay them to other full nodes.
Running a full node with dcrd contributes to the overall security of the network, increases the available paths for transactions and blocks to relay, and helps ensure there are an adequate number of nodes available to serve lightweight clients, such as Simplified Payment Verification (SPV) wallets.
Without enough full nodes, the network could be unable to expediently serve users of lightweight clients which could force them to have to rely on centralized services that significantly reduce privacy and are vulnerable to censorship.
In terms of individual benefits, since dcrd fully validates every block and transaction, it provides the highest security and privacy possible when used in conjunction with a wallet that also supports directly connecting to it in full validation mode, such as dcrwallet (CLI) and Decrediton (GUI).
Minimum Recommended Specifications (dcrd only)
- 10 GB disk space (as of September 2018, increases over time)
- 1GB memory (RAM)
- ~150MB/day download, ~1.5GB/day upload
- Plus one-time initial download of the entire block chain
- Windows 7/8.x/10 (server preferred), macOS, Linux
- High uptime
Getting Started
So, you've decided to help the network by running a full node. Great! Running dcrd is simple. All you need to do is install dcrd on a machine that is connected to the internet and meets the minimum recommended specifications, and launch it.
Also, make sure your firewall is configured to allow inbound connections to port 9108.
Installing and updating
Binaries (Windows/Linux/macOS)
Binary releases are provided for common operating systems and architectures:
https://decred.org/downloads
Build from source (all platforms)
Building or updating from source requires the following build dependencies:
-
Go 1.11 or 1.12
Installation instructions can be found here: https://golang.org/doc/install. It is recommended to add
$GOPATH/binto yourPATHat this point. -
Git
Installation instructions can be found at https://git-scm.com or https://gitforwindows.org.
To build and install from a checked-out repo, run go install . ./cmd/... in
the repo's root directory. Some notes:
-
Set the
GO111MODULE=onenvironment variable if building from withinGOPATH. -
The
dcrdexecutable will be installed to$GOPATH/bin.GOPATHdefaults to$HOME/go(or%USERPROFILE%\goon Windows) if unset.
Example of obtaining and building from source on Windows 10:
PS> git clone https://github.com/decred/dcrd $env:USERPROFILE\src\dcrd
PS> cd $env:USERPROFILE\src\dcrd
PS> go install . .\cmd\...
PS> & "$(go env GOPATH)\bin\dcrd" -V
Docker
Running dcrd
You can run a decred node from inside a docker container. To build the image yourself, use the following command:
docker build -t decred/dcrd .
Or you can create an alpine based image (requires Docker 17.05 or higher):
docker build -t decred/dcrd:alpine -f Dockerfile.alpine .
You can then run the image using:
docker run decred/dcrd
You may wish to use an external volume to customise your config and persist the data in an external volume:
docker run --rm -v /home/user/dcrdata:/root/.dcrd/data decred/dcrd
For a minimal image, you can use the decred/dcrd:alpine tag. This is typically a more secure option while also being a much smaller image.
You can run dcrctl from inside the image. For example, run an image (mounting your data from externally) with:
docker run --rm -ti --name=dcrd-1 -v /home/user/.dcrd:/root/.dcrd \
decred/dcrd:alpine
And then run dcrctl commands against it. For example:
docker exec -ti dcrd-1 dcrctl getbestblock
Running Tests
All tests and linters may be run in a docker (or podman) container using the
script run_tests.sh by specifying either docker or podman as the first
parameter. This script defaults to using the current latest supported version
of Go, but it also respects the GOVERSION environment variable set to the
major version of Go to allow testing on a previous version of Go. Generally,
Decred only supports the current and previous major versions of Go.
./run_tests.sh docker
To run the tests locally without docker on the latest supported version of Go:
./run_tests.sh
To run the tests locally without docker on Go 1.11:
GOVERSION=1.11 ./run_tests.sh
Contact
If you have any further questions you can find us at:
https://decred.org/community
Issue Tracker
The integrated github issue tracker is used for this project.
Documentation
The documentation for dcrd is a work-in-progress. It is located in the docs folder.
License
dcrd is licensed under the copyfree ISC License.