mirror of
https://github.com/bitcoin/bitcoin.git
synced 2025-03-04 13:55:23 -05:00
doc: Improve assumeutxo guide and add more docs/comments
Also fixes some outdated information in the remaining design doc.
This commit is contained in:
Fabian Jahr
parent
b29c21fc92
commit
e868a6e070
3 changed files with 94 additions and 43 deletions
85
doc/assumeutxo.md
Normal file
85
doc/assumeutxo.md
Normal file
|
|
@ -0,0 +1,85 @@
|
|||
# Assumeutxo Usage
|
||||
|
||||
Assumeutxo is a feature that allows fast bootstrapping of a validating bitcoind
|
||||
instance.
|
||||
|
||||
For notes on the design of Assumeutxo, please refer to [the design doc](/doc/assumeutxo.md).
|
||||
|
||||
## Loading a snapshot
|
||||
|
||||
There is currently no canonical source for snapshots, but any downloaded snapshot
|
||||
will be checked against a hash that's been hardcoded in source code. If there is
|
||||
no source for the snapshot you need, you can generate it yourself using
|
||||
`dumptxoutset` on another node that is already synced (see
|
||||
[Generating a snapshot](#generating-a-snapshot)).
|
||||
|
||||
Once you've obtained the snapshot, you can use the RPC command `loadtxoutset` to
|
||||
load it.
|
||||
|
||||
```
|
||||
$ bitcoin-cli loadtxoutset /path/to/input
|
||||
```
|
||||
|
||||
After the snapshot has loaded, the syncing process of both the snapshot chain
|
||||
and the background IBD chain can be monitored with the `getchainstates` RPC.
|
||||
|
||||
### Pruning
|
||||
|
||||
A pruned node can load a snapshot. To save space, it's possible to delete the
|
||||
snapshot file as soon as `loadtxoutset` finishes.
|
||||
|
||||
The minimum `-prune` setting is 550 MiB, but this functionality ignores that
|
||||
minimum and uses at least 1100 MiB.
|
||||
|
||||
As the background sync continues there will be temporarily two chainstate
|
||||
directories, each multiple gigabytes in size (likely growing larger than the
|
||||
downloaded snapshot).
|
||||
|
||||
### Indexes
|
||||
|
||||
Indexes work but don't take advantage of this feature. They always start building
|
||||
from the genesis block and can only apply blocks in order. Once the background
|
||||
validation reaches the snapshot block, indexes will continue to build all the
|
||||
way to the tip.
|
||||
|
||||
|
||||
For indexes that support pruning, note that these indexes only allow blocks that
|
||||
were already indexed to be pruned. Blocks that are not indexed yet will also
|
||||
not be pruned.
|
||||
|
||||
This means that, if the snapshot is old, then a lot of blocks after the snapshot
|
||||
block will need to be downloaded, and these blocks can't be pruned until they
|
||||
are indexed, so they could consume a lot of disk space until indexing catches up
|
||||
to the snapshot block.
|
||||
|
||||
## Generating a snapshot
|
||||
|
||||
The RPC command `dumptxoutset` can be used to generate a snapshot for the current
|
||||
tip (using type "latest") or a recent height (using type "rollback"). A generated
|
||||
snapshot from one node can then be loaded
|
||||
on any other node. However, keep in mind that the snapshot hash needs to be
|
||||
listed in the chainparams to make it usable. If there is no snapshot hash for
|
||||
the height you have chosen already, you will need to change the code there and
|
||||
re-compile.
|
||||
|
||||
Using the type parameter "rollback", `dumptxoutset` can also be used to verify the
|
||||
hardcoded snapshot hash in the source code by regenerating the snapshot and
|
||||
comparing the hash.
|
||||
|
||||
Example usage:
|
||||
|
||||
```
|
||||
$ bitcoin-cli -rpcclienttimeout=0 dumptxoutset /path/to/output rollback
|
||||
```
|
||||
|
||||
For most of the duration of `dumptxoutset` running the node is in a temporary
|
||||
state that does not actually reflect reality, i.e. blocks are marked invalid
|
||||
although we know they are not invalid. Because of this it is discouraged to
|
||||
interact with the node in any other way during this time to avoid inconsistent
|
||||
results and race conditions, particularly RPCs that interact with blockstorage.
|
||||
This inconsistent state is also why network activity is temporarily disabled,
|
||||
causing us to disconnect from all peers.
|
||||
|
||||
`dumptxoutset` takes some time to complete, independent of hardware and
|
||||
what parameter is chosen. Because of that it is recommended to increase the RPC
|
||||
client timeout value (use `-rpcclienttimeout=0` for no timeout).
|
||||
|
|
@ -1,45 +1,6 @@
|
|||
# assumeutxo
|
||||
# Assumeutxo Design
|
||||
|
||||
Assumeutxo is a feature that allows fast bootstrapping of a validating bitcoind
|
||||
instance.
|
||||
|
||||
## Loading a snapshot
|
||||
|
||||
There is currently no canonical source for snapshots, but any downloaded snapshot
|
||||
will be checked against a hash that's been hardcoded in source code.
|
||||
|
||||
Once you've obtained the snapshot, you can use the RPC command `loadtxoutset` to
|
||||
load it.
|
||||
|
||||
### Pruning
|
||||
|
||||
A pruned node can load a snapshot. To save space, it's possible to delete the
|
||||
snapshot file as soon as `loadtxoutset` finishes.
|
||||
|
||||
The minimum `-prune` setting is 550 MiB, but this functionality ignores that
|
||||
minimum and uses at least 1100 MiB.
|
||||
|
||||
As the background sync continues there will be temporarily two chainstate
|
||||
directories, each multiple gigabytes in size (likely growing larger than the
|
||||
downloaded snapshot).
|
||||
|
||||
### Indexes
|
||||
|
||||
Indexes work but don't take advantage of this feature. They always start building
|
||||
from the genesis block. Once the background validation reaches the snapshot block,
|
||||
indexes will continue to build all the way to the tip.
|
||||
|
||||
For indexes that support pruning, note that no pruning will take place between
|
||||
the snapshot and the tip, until the background sync has completed - after which
|
||||
everything is pruned. Depending on how old the snapshot is, this may temporarily
|
||||
use a significant amount of disk space.
|
||||
|
||||
## Generating a snapshot
|
||||
|
||||
The RPC command `dumptxoutset` can be used to generate a snapshot for the current
|
||||
tip or a recent height. This can be used
|
||||
to create a snapshot on one node that you wish to load on another node.
|
||||
It can also be used to verify the hardcoded snapshot hash in the source code.
|
||||
For notes on the usage of Assumeutxo, please refer to [the usage doc](/doc/assumeutxo.md).
|
||||
|
||||
## General background
|
||||
|
||||
|
|
@ -77,7 +38,7 @@ data.
|
|||
### "Normal" operation via initial block download
|
||||
|
||||
`ChainstateManager` manages a single Chainstate object, for which
|
||||
`m_snapshot_blockhash` is null. This chainstate is (maybe obviously)
|
||||
`m_from_snapshot_blockhash` is `std::nullopt`. This chainstate is (maybe obviously)
|
||||
considered active. This is the "traditional" mode of operation for bitcoind.
|
||||
|
||||
| | |
|
||||
|
|
|
|||
|
|
@ -2676,7 +2676,10 @@ static RPCHelpMan dumptxoutset()
|
|||
{
|
||||
return RPCHelpMan{
|
||||
"dumptxoutset",
|
||||
"Write the serialized UTXO set to a file.",
|
||||
"Write the serialized UTXO set to a file. This can be used in loadtxoutset afterwards if this snapshot height is supported in the chainparams as well.\n\n"
|
||||
"Unless the the \"latest\" type is requested, the node will roll back to the requested height and network activity will be suspended during this process. "
|
||||
"Because of this it is discouraged to interact with the node in any other way during the execution of this call to avoid inconsistent results and race conditions, particularly RPCs that interact with blockstorage.\n\n"
|
||||
"This call may take several minutes. Make sure to use no RPC timeout (bitcoin-cli -rpcclienttimeout=0)",
|
||||
{
|
||||
{"path", RPCArg::Type::STR, RPCArg::Optional::NO, "Path to the output file. If relative, will be prefixed by datadir."},
|
||||
{"type", RPCArg::Type::STR, RPCArg::Default(""), "The type of snapshot to create. Can be \"latest\" to create a snapshot of the current UTXO set or \"rollback\" to temporarily roll back the state of the node to a historical block before creating the snapshot of a historical UTXO set. This parameter can be omitted if a separate \"rollback\" named parameter is specified indicating the height or hash of a specific historical block. If \"rollback\" is specified and separate \"rollback\" named parameter is not specified, this will roll back to the latest valid snapshot block that currently be loaded with loadtxoutset."},
|
||||
|
|
@ -2773,6 +2776,8 @@ static RPCHelpMan dumptxoutset()
|
|||
// would be classified as a block connecting an invalid block.
|
||||
disable_network = std::make_unique<NetworkDisable>(connman);
|
||||
|
||||
// Note: Unlocking cs_main before CreateUTXOSnapshot might be racy
|
||||
// if the user interacts with any other *block RPCs.
|
||||
invalidate_index = WITH_LOCK(::cs_main, return node.chainman->ActiveChain().Next(target_index));
|
||||
InvalidateBlock(*node.chainman, invalidate_index->GetBlockHash());
|
||||
const CBlockIndex* new_tip_index{WITH_LOCK(::cs_main, return node.chainman->ActiveChain().Tip())};
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue