c1a3d640ef
UtxoCache is an unspent transaction output cache that sits on top of the
utxo set database and provides significant runtime performance benefits
at the cost of some additional memory usage. It drastically reduces the
amount of reading and writing to disk, especially during initial block
download when a very large number of blocks are being processed in quick
succession.
The UtxoCache is a read-through cache. All utxo reads go through the
cache. When there is a cache miss, the cache loads the missing data
from the database, caches it, and returns it to the caller.
The UtxoCache is a write-back cache. Writes to the cache are
acknowledged by the cache immediately but are only periodically flushed
to the database. This allows intermediate steps to effectively be
skipped. For example, a utxo that is created and then spent in between
flushes never needs to be written to the utxo set in the database.
Due to the write-back nature of the cache, at any given time the
database may not be in sync with the cache, and therefore all utxo reads
and writes MUST go through the cache, and never read or write to the
database directly.
An overview of the changes is as follows:
- Add UtxoCache and UtxoCacheConfig struct types and NewUtxoCache method
- Update server to create the utxo cache with the configured max size
and pass to the block chain instance that is created
- Update all test block chains to create a utxo cache
- Add FetchEntry to UtxoCache
- FetchEntry returns the specified transaction output from the utxo
set
- If the output exists in the cache, it is returned immediately.
Otherwise, it uses an existing database transaction to fetch the
output from the database, caches it, and returns it to the caller.
- Add AddEntry to UtxoCache
- AddEntry adds the specified output to the cache
- Add SpendEntry to UtxoCache
- SpendEntry marks the specified output as spent
- Remove entries that are marked as fresh and then subsequently spent.
This is an optimization to skip writing to the database for outputs
that are added and spent in between flushes to the database.
- Update UtxoViewpoint to hold the UtxoCache
- Update fetching entries from the database to fetch entries from the
cache instead
- Add Commit to UtxoCache
- Commit updates all entries in the cache based on the state of each
entry in the provided view
- All entries in the provided view that are marked as modified and
spent are removed from the view
- Additionally, all entries that are added to the cache are removed
from the provided view
- Add MaybeFlush to UtxoCache
- MaybeFlush conditionally flushes the cache to the database
- If the maximum size of the cache has been reached, or if the
periodic flush duration has been reached, then a flush is required
- A flush can be forced by setting the force flush parameter
- Flushing commits all modified entries to the database and
conditionally evicts entries
- Entries that are nil or spent are always evicted since they are
unlikely to be accessed again. Additionally, if the cache has
reached its maximum size, entries are evicted based on the height of
the block that they are contained in.
- Update connect block and disconnect block to commit to the cache and
conditionally flush to the database
- Rather than writing to the utxo set in the database every time that
a block is connected or disconnected, commit the updated view to the
cache and call MaybeFlush on the cache to conditionally flush it to
the database
- Add InitUtxoCache to UtxoCache
- InitUtxoCache initializes the utxo cache by ensuring that the utxo
set is caught up to the tip of the best chain
- Since the cache is only flushed to the database periodically, the
utxo set may not be caught up to the tip of the best chain
- InitUtxoCache catches the utxo set up by replaying all blocks from
the block after the block that was last flushed to the tip block
through the cache
- Add ShutdownUtxoCache to BlockChain
- ShutdownUtxoCache flushes the utxo cache to the database on
shutdown. Since the cache is flushed periodically during initial
block download and flushed after every block is connected after
initial block download is complete, this flush that occurs during
shutdown should finish relatively quickly
- Note that if an unclean shutdown occurs, the cache will still be
initialized properly when restarted as during initialization it will
replay blocks to catch up to the tip block if it was not fully
flushed before shutting down. However, it is still preferred to
flush when shutting down versus always recovering on startup since
it is faster
- Track the hit ratio of UtxoCache
- Track the number of hits and misses when accessing the cache in
order to calculate the overall hit ratio of the cache to gauge its
performance
82 lines
3.0 KiB
Go
82 lines
3.0 KiB
Go
// Copyright (c) 2014-2016 The btcsuite developers
|
|
// Copyright (c) 2015-2021 The Decred developers
|
|
// Use of this source code is governed by an ISC
|
|
// license that can be found in the LICENSE file.
|
|
|
|
package blockchain_test
|
|
|
|
import (
|
|
"context"
|
|
"fmt"
|
|
"os"
|
|
"path/filepath"
|
|
|
|
"github.com/decred/dcrd/blockchain/v4"
|
|
"github.com/decred/dcrd/chaincfg/v3"
|
|
"github.com/decred/dcrd/database/v2"
|
|
_ "github.com/decred/dcrd/database/v2/ffldb"
|
|
"github.com/decred/dcrd/dcrutil/v4"
|
|
)
|
|
|
|
// This example demonstrates how to create a new chain instance and use
|
|
// ProcessBlock to attempt to add a block to the chain. As the package
|
|
// overview documentation describes, this includes all of the Decred consensus
|
|
// rules. This example intentionally attempts to insert a duplicate genesis
|
|
// block to illustrate how an invalid block is handled.
|
|
func ExampleBlockChain_ProcessBlock() {
|
|
// Create a new database to store the accepted blocks into. Typically
|
|
// this would be opening an existing database and would not be deleting
|
|
// and creating a new database like this, but it is done here so this is
|
|
// a complete working example and does not leave temporary files laying
|
|
// around.
|
|
mainNetParams := chaincfg.MainNetParams()
|
|
dbPath := filepath.Join(os.TempDir(), "exampleprocessblock")
|
|
_ = os.RemoveAll(dbPath)
|
|
db, err := database.Create("ffldb", dbPath, mainNetParams.Net)
|
|
if err != nil {
|
|
fmt.Printf("Failed to create database: %v\n", err)
|
|
return
|
|
}
|
|
defer os.RemoveAll(dbPath)
|
|
defer db.Close()
|
|
|
|
// Create a new BlockChain instance using the underlying database for
|
|
// the main bitcoin network. This example does not demonstrate some
|
|
// of the other available configuration options such as specifying a
|
|
// notification callback and signature cache. Also, the caller would
|
|
// ordinarily keep a reference to the median time source and add time
|
|
// values obtained from other peers on the network so the local time is
|
|
// adjusted to be in agreement with other peers.
|
|
chain, err := blockchain.New(context.Background(),
|
|
&blockchain.Config{
|
|
DB: db,
|
|
ChainParams: mainNetParams,
|
|
TimeSource: blockchain.NewMedianTime(),
|
|
UtxoCache: blockchain.NewUtxoCache(&blockchain.UtxoCacheConfig{
|
|
DB: db,
|
|
MaxSize: 100 * 1024 * 1024, // 100 MiB
|
|
}),
|
|
})
|
|
if err != nil {
|
|
fmt.Printf("Failed to create chain instance: %v\n", err)
|
|
return
|
|
}
|
|
|
|
// Process a block. For this example, intentionally cause an error by
|
|
// trying to process the genesis block which already exists.
|
|
genesisBlock := dcrutil.NewBlock(mainNetParams.GenesisBlock)
|
|
forkLen, err := chain.ProcessBlock(genesisBlock,
|
|
blockchain.BFNone)
|
|
if err != nil {
|
|
fmt.Printf("Failed to create chain instance: %v\n", err)
|
|
return
|
|
}
|
|
isMainChain := forkLen == 0
|
|
fmt.Printf("Block accepted. Is it on the main chain?: %v", isMainChain)
|
|
|
|
// This output is dependent on the genesis block, and needs to be
|
|
// updated if the mainnet genesis block is updated.
|
|
// Output:
|
|
// Failed to process block: already have block 267a53b5ee86c24a48ec37aee4f4e7c0c4004892b7259e695e9f5b321f1ab9d2
|
|
}
|