accb6c9472
This overhauls the primary code that deals with synchronizing the
blockchain with other peers on the network to use a model based on
header announcements instead of inventory vectors.
Currently, all blocks are discovered via a combination of inventory
vector announcements and the getblocks protocol message, both of which
only include the hash of the blocks in question.
This is not ideal because it means blocks are blindly downloaded based
on those announcements without knowing if they're actually likely to be
something that is useful since there is no further information such as
what blocks they connect to. It also means that extra logic is needed
to deal with orphan blocks (those whose parents are not yet known) such
as caching them, determining known orphan roots, and expiration.
In short, the current method generally ends up wasting bandwidth and
also makes it much more difficult to detect certain classes of malicious
behavior.
The recently added capability of blockchain to process headers
independently from blocks while the block data is added out of order
later opened the door for a much better model that addresses all of the
aforementioned issues as well as paves the way for many other related
enhancements.
The new model discovers and downloads all of the headers prior to any
block data via the getheaders protocol message and then uses those
headers to determine exactly which blocks need to be downloaded to reach
the tip of the best chain. Notably, this means orphan blocks are now a
thing of the past as blocks that do not connect are no longer
downloaded under any circumstance.
Further, the new model also makes use of sendheaders so that all block
announcements are made via the associated block header. This in turn is
used to better determine if an announced block is likely to be useful
prior to downloading it.
It should be noted that the changes herein are intentionally limited to
those necessary to use the new sync model based on headers in an
incremental fashion to help simplify review and make it easier to assert
correctness. There are many more improvements that this model paves the
way to support planned for future commits. For example, syncing from
multiple peers in parallel and improved DoS protection.
The following is a high-level overview of the key features:
- All headers are downloaded and examined prior to downloading any
blocks
- The initial header sync process:
- Detects and recovers from stalled/malicious peers
- The concept of orphan blocks no longer exists
- This means blocks which are not already known to connect are not
downloaded
- All block announcements are handled via header announcements
- Detects and prevents malicious behavior related to orphan headers
- The chain sync process:
- Starts once the headers are downloaded and entails both downloading
blocks as well as verifying them
- Uses the headers to determine the best blocks to download
- Pipelines the requests to increase throughput
- Actively avoids downloading duplicate blocks
- The sync height is dynamically updated as new headers are discovered
|
||
|---|---|---|
| .github | ||
| addrmgr | ||
| bech32 | ||
| blockchain | ||
| certgen | ||
| chaincfg | ||
| cmd | ||
| connmgr | ||
| contrib | ||
| crypto | ||
| database | ||
| dcrec | ||
| dcrjson | ||
| dcrutil | ||
| docs | ||
| gcs | ||
| hdkeychain | ||
| internal | ||
| lru | ||
| peer | ||
| rpc/jsonrpc/types | ||
| rpcclient | ||
| rpctest | ||
| sampleconfig | ||
| txscript | ||
| wire | ||
| .dockerignore | ||
| .gitignore | ||
| blockdb.go | ||
| cert_test.go | ||
| CHANGES | ||
| config_test.go | ||
| config.go | ||
| dcrd.go | ||
| doc.go | ||
| Dockerfile | ||
| Dockerfile.alpine | ||
| go.mod | ||
| go.sum | ||
| ipc.go | ||
| LICENSE | ||
| log.go | ||
| networkparams_test.go | ||
| params.go | ||
| README.md | ||
| require.go | ||
| rpcadaptors.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
Core software:
- dcrd: a Decred full node daemon (this)
- dcrwallet: a CLI Decred wallet daemon
- dcrctl: a CLI client for dcrd and dcrwallet
Bundles:
- Decrediton: a GUI bundle for
dcrdanddcrwallet - CLI app suite:
a CLI bundle for
dcrdanddcrwallet
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.
It important to note that dcrd does NOT include wallet functionality. Users who desire a wallet will need to use dcrwallet(CLI) or Decrediton(GUI).
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)
- 12 GB disk space (as of April 2020, increases over time)
- 1GB memory (RAM)
- ~150MB/day download, ~1.5GB/day upload
- Plus one-time initial download of the entire block chain
- Windows 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. The easiest method is to download Decrediton from the link below, which will include dcrd. Advanced users may prefer the Command-line app suite, which includes dcrd and dcrwallet.
https://decred.org/downloads/
- How to verify binaries before installing: https://docs.decred.org/advanced/verifying-binaries/
- How to install the CLI Suite: https://docs.decred.org/wallets/cli/cli-installation/
- How to install Decrediton: https://docs.decred.org/wallets/decrediton/decrediton-setup/
Build from source (all platforms)
Install Dependencies
-
Go 1.14 or 1.15
Installation instructions can be found here: https://golang.org/doc/install. Ensure Go was installed properly and is a supported version:
$ go version $ go env GOROOT GOPATHNOTE:
GOROOTandGOPATHmust not be on the same path. Since Go 1.8 (2016),GOROOTandGOPATHare set automatically, and you do not need to change them. However, you still need to add$GOPATH/binto yourPATHin order to run binaries installed bygo getandgo install(On Windows, this happens automatically).Unix example -- add these lines to .profile:
PATH="$PATH:/usr/local/go/bin" # main Go binaries ($GOROOT/bin) PATH="$PATH:$HOME/go/bin" # installed Go projects ($GOPATH/bin) -
Git
Installation instructions can be found at https://git-scm.com or https://gitforwindows.org.
$ git version
Windows Example
PS> git clone https://github.com/decred/dcrd $env:USERPROFILE\src\dcrd
PS> cd $env:USERPROFILE\src\dcrd
PS> go install . .\cmd\...
PS> dcrd -V
Run the dcrd executable now installed in "$(go env GOPATH)\bin".
Unix Example
This assumes you have already added $GOPATH/bin to your $PATH as described
in dependencies.
$ git clone https://github.com/decred/dcrd $HOME/src/dcrd
$ git clone https://github.com/decred/dcrctl $HOME/src/dcrctl
$ (cd $HOME/src/dcrd && go install . ./...)
$ (cd $HOME/src/dcrctl && go install)
$ dcrd -V
Run the dcrd executable now installed in $GOPATH/bin.
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 customize 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 using the script run_tests.sh. Generally,
Decred only supports the current and previous major versions of Go.
./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.