2015-10-05 11:37:56 -05:00
|
|
|
// Copyright 2015 The go-ethereum Authors
|
|
|
|
// This file is part of the go-ethereum library.
|
|
|
|
//
|
|
|
|
// The go-ethereum library is free software: you can redistribute it and/or modify
|
|
|
|
// it under the terms of the GNU Lesser General Public License as published by
|
|
|
|
// the Free Software Foundation, either version 3 of the License, or
|
|
|
|
// (at your option) any later version.
|
|
|
|
//
|
|
|
|
// The go-ethereum library is distributed in the hope that it will be useful,
|
|
|
|
// but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
// GNU Lesser General Public License for more details.
|
|
|
|
//
|
|
|
|
// You should have received a copy of the GNU Lesser General Public License
|
|
|
|
// along with the go-ethereum library. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
|
|
|
package trie
|
|
|
|
|
|
|
|
import (
|
2016-05-27 06:26:00 -05:00
|
|
|
"errors"
|
2015-10-05 11:37:56 -05:00
|
|
|
"fmt"
|
2022-09-06 04:57:03 -05:00
|
|
|
"sync"
|
2015-10-05 11:37:56 -05:00
|
|
|
|
|
|
|
"github.com/ethereum/go-ethereum/common"
|
2018-09-03 10:33:21 -05:00
|
|
|
"github.com/ethereum/go-ethereum/common/prque"
|
2020-08-21 07:10:40 -05:00
|
|
|
"github.com/ethereum/go-ethereum/core/rawdb"
|
2018-02-05 10:40:32 -06:00
|
|
|
"github.com/ethereum/go-ethereum/ethdb"
|
2022-07-15 06:55:51 -05:00
|
|
|
"github.com/ethereum/go-ethereum/log"
|
2015-10-05 11:37:56 -05:00
|
|
|
)
|
|
|
|
|
2016-05-27 06:26:00 -05:00
|
|
|
// ErrNotRequested is returned by the trie sync when it's requested to process a
|
|
|
|
// node it did not request.
|
|
|
|
var ErrNotRequested = errors.New("not requested")
|
|
|
|
|
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 07:26:03 -05:00
|
|
|
// ErrAlreadyProcessed is returned by the trie sync when it's requested to process a
|
|
|
|
// node it already processed previously.
|
|
|
|
var ErrAlreadyProcessed = errors.New("already processed")
|
|
|
|
|
2020-08-26 05:05:06 -05:00
|
|
|
// maxFetchesPerDepth is the maximum number of pending trie nodes per depth. The
|
|
|
|
// role of this value is to limit the number of trie nodes that get expanded in
|
|
|
|
// memory if the node was configured with a significant number of peers.
|
|
|
|
const maxFetchesPerDepth = 16384
|
|
|
|
|
2020-08-28 02:50:37 -05:00
|
|
|
// SyncPath is a path tuple identifying a particular trie node either in a single
|
|
|
|
// trie (account) or a layered trie (account -> storage).
|
|
|
|
//
|
|
|
|
// Content wise the tuple either has 1 element if it addresses a node in a single
|
|
|
|
// trie or 2 elements if it addresses a node in a stacked trie.
|
|
|
|
//
|
|
|
|
// To support aiming arbitrary trie nodes, the path needs to support odd nibble
|
|
|
|
// lengths. To avoid transferring expanded hex form over the network, the last
|
|
|
|
// part of the tuple (which needs to index into the middle of a trie) is compact
|
|
|
|
// encoded. In case of a 2-tuple, the first item is always 32 bytes so that is
|
|
|
|
// simple binary encoded.
|
|
|
|
//
|
|
|
|
// Examples:
|
|
|
|
// - Path 0x9 -> {0x19}
|
|
|
|
// - Path 0x99 -> {0x0099}
|
|
|
|
// - Path 0x01234567890123456789012345678901012345678901234567890123456789019 -> {0x0123456789012345678901234567890101234567890123456789012345678901, 0x19}
|
|
|
|
// - Path 0x012345678901234567890123456789010123456789012345678901234567890199 -> {0x0123456789012345678901234567890101234567890123456789012345678901, 0x0099}
|
|
|
|
type SyncPath [][]byte
|
|
|
|
|
2022-05-10 09:37:24 -05:00
|
|
|
// NewSyncPath converts an expanded trie path from nibble form into a compact
|
2020-08-28 02:50:37 -05:00
|
|
|
// version that can be sent over the network.
|
2022-05-10 09:37:24 -05:00
|
|
|
func NewSyncPath(path []byte) SyncPath {
|
2020-08-28 02:50:37 -05:00
|
|
|
// If the hash is from the account trie, append a single item, if it
|
2022-11-28 07:31:28 -06:00
|
|
|
// is from a storage trie, append a tuple. Note, the length 64 is
|
2020-08-28 02:50:37 -05:00
|
|
|
// clashing between account leaf and storage root. It's fine though
|
|
|
|
// because having a trie node at 64 depth means a hash collision was
|
|
|
|
// found and we're long dead.
|
|
|
|
if len(path) < 64 {
|
|
|
|
return SyncPath{hexToCompact(path)}
|
|
|
|
}
|
|
|
|
return SyncPath{hexToKeybytes(path[:64]), hexToCompact(path[64:])}
|
|
|
|
}
|
|
|
|
|
2022-11-28 07:31:28 -06:00
|
|
|
// LeafCallback is a callback type invoked when a trie operation reaches a leaf
|
|
|
|
// node.
|
|
|
|
//
|
|
|
|
// The keys is a path tuple identifying a particular trie node either in a single
|
|
|
|
// trie (account) or a layered trie (account -> storage). Each key in the tuple
|
|
|
|
// is in the raw format(32 bytes).
|
|
|
|
//
|
|
|
|
// The path is a composite hexary path identifying the trie node. All the key
|
|
|
|
// bytes are converted to the hexary nibbles and composited with the parent path
|
|
|
|
// if the trie node is in a layered trie.
|
|
|
|
//
|
|
|
|
// It's used by state sync and commit to allow handling external references
|
|
|
|
// between account and storage tries. And also it's used in the state healing
|
|
|
|
// for extracting the raw states(leaf nodes) with corresponding paths.
|
|
|
|
type LeafCallback func(keys [][]byte, path []byte, leaf []byte, parent common.Hash, parentPath []byte) error
|
|
|
|
|
2022-07-15 06:55:51 -05:00
|
|
|
// nodeRequest represents a scheduled or already in-flight trie node retrieval request.
|
|
|
|
type nodeRequest struct {
|
|
|
|
hash common.Hash // Hash of the trie node to retrieve
|
|
|
|
path []byte // Merkle path leading to this node for prioritization
|
|
|
|
data []byte // Data content of the node, cached until all subtrees complete
|
|
|
|
|
|
|
|
parent *nodeRequest // Parent state node referencing this entry
|
|
|
|
deps int // Number of dependencies before allowed to commit this node
|
|
|
|
callback LeafCallback // Callback to invoke if a leaf node it reached on this branch
|
|
|
|
}
|
|
|
|
|
|
|
|
// codeRequest represents a scheduled or already in-flight bytecode retrieval request.
|
|
|
|
type codeRequest struct {
|
|
|
|
hash common.Hash // Hash of the contract bytecode to retrieve
|
|
|
|
path []byte // Merkle path leading to this node for prioritization
|
|
|
|
data []byte // Data content of the node, cached until all subtrees complete
|
|
|
|
parents []*nodeRequest // Parent state nodes referencing this entry (notify all upon completion)
|
|
|
|
}
|
|
|
|
|
|
|
|
// NodeSyncResult is a response with requested trie node along with its node path.
|
|
|
|
type NodeSyncResult struct {
|
|
|
|
Path string // Path of the originally unknown trie node
|
|
|
|
Data []byte // Data content of the retrieved trie node
|
|
|
|
}
|
|
|
|
|
|
|
|
// CodeSyncResult is a response with requested bytecode along with its hash.
|
|
|
|
type CodeSyncResult struct {
|
|
|
|
Hash common.Hash // Hash the originally unknown bytecode
|
|
|
|
Data []byte // Data content of the retrieved bytecode
|
2015-10-05 11:37:56 -05:00
|
|
|
}
|
|
|
|
|
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 07:26:03 -05:00
|
|
|
// syncMemBatch is an in-memory buffer of successfully downloaded but not yet
|
|
|
|
// persisted data items.
|
|
|
|
type syncMemBatch struct {
|
2022-07-15 06:55:51 -05:00
|
|
|
nodes map[string][]byte // In-memory membatch of recently completed nodes
|
|
|
|
hashes map[string]common.Hash // Hashes of recently completed nodes
|
|
|
|
codes map[common.Hash][]byte // In-memory membatch of recently completed codes
|
2022-09-28 01:08:18 -05:00
|
|
|
size uint64 // Estimated batch-size of in-memory data.
|
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 07:26:03 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
// newSyncMemBatch allocates a new memory-buffer for not-yet persisted trie nodes.
|
|
|
|
func newSyncMemBatch() *syncMemBatch {
|
|
|
|
return &syncMemBatch{
|
2022-07-15 06:55:51 -05:00
|
|
|
nodes: make(map[string][]byte),
|
|
|
|
hashes: make(map[string]common.Hash),
|
|
|
|
codes: make(map[common.Hash][]byte),
|
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 07:26:03 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-07-15 06:55:51 -05:00
|
|
|
// hasNode reports the trie node with specific path is already cached.
|
|
|
|
func (batch *syncMemBatch) hasNode(path []byte) bool {
|
|
|
|
_, ok := batch.nodes[string(path)]
|
2020-08-21 07:10:40 -05:00
|
|
|
return ok
|
|
|
|
}
|
|
|
|
|
|
|
|
// hasCode reports the contract code with specific hash is already cached.
|
|
|
|
func (batch *syncMemBatch) hasCode(hash common.Hash) bool {
|
|
|
|
_, ok := batch.codes[hash]
|
|
|
|
return ok
|
|
|
|
}
|
|
|
|
|
2018-05-29 10:48:43 -05:00
|
|
|
// Sync is the main state trie synchronisation scheduler, which provides yet
|
2015-10-05 11:37:56 -05:00
|
|
|
// unknown trie hashes to retrieve, accepts node data associated with said hashes
|
2015-10-07 04:14:30 -05:00
|
|
|
// and reconstructs the trie step by step until all is done.
|
2018-05-29 10:48:43 -05:00
|
|
|
type Sync struct {
|
2023-02-06 09:28:40 -06:00
|
|
|
scheme string // Node scheme descriptor used in database.
|
2022-07-15 06:55:51 -05:00
|
|
|
database ethdb.KeyValueReader // Persistent database to check for existing entries
|
|
|
|
membatch *syncMemBatch // Memory buffer to avoid frequent database writes
|
|
|
|
nodeReqs map[string]*nodeRequest // Pending requests pertaining to a trie node path
|
|
|
|
codeReqs map[common.Hash]*codeRequest // Pending requests pertaining to a code hash
|
|
|
|
queue *prque.Prque // Priority queue with the pending requests
|
|
|
|
fetches map[int]int // Number of active fetches per trie node depth
|
2015-10-05 11:37:56 -05:00
|
|
|
}
|
|
|
|
|
2018-05-29 10:48:43 -05:00
|
|
|
// NewSync creates a new trie data download scheduler.
|
2023-02-06 09:28:40 -06:00
|
|
|
func NewSync(root common.Hash, database ethdb.KeyValueReader, callback LeafCallback, scheme string) *Sync {
|
2018-05-29 10:48:43 -05:00
|
|
|
ts := &Sync{
|
2022-11-28 07:31:28 -06:00
|
|
|
scheme: scheme,
|
2015-10-05 11:37:56 -05:00
|
|
|
database: database,
|
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 07:26:03 -05:00
|
|
|
membatch: newSyncMemBatch(),
|
2022-07-15 06:55:51 -05:00
|
|
|
nodeReqs: make(map[string]*nodeRequest),
|
|
|
|
codeReqs: make(map[common.Hash]*codeRequest),
|
2018-09-03 10:33:21 -05:00
|
|
|
queue: prque.New(nil),
|
2020-08-26 05:05:06 -05:00
|
|
|
fetches: make(map[int]int),
|
2015-10-05 11:37:56 -05:00
|
|
|
}
|
2022-07-15 06:55:51 -05:00
|
|
|
ts.AddSubTrie(root, nil, common.Hash{}, nil, callback)
|
2015-10-05 11:37:56 -05:00
|
|
|
return ts
|
|
|
|
}
|
|
|
|
|
2022-07-15 06:55:51 -05:00
|
|
|
// AddSubTrie registers a new trie to the sync code, rooted at the designated
|
|
|
|
// parent for completion tracking. The given path is a unique node path in
|
|
|
|
// hex format and contain all the parent path if it's layered trie node.
|
|
|
|
func (s *Sync) AddSubTrie(root common.Hash, path []byte, parent common.Hash, parentPath []byte, callback LeafCallback) {
|
2015-10-07 04:14:30 -05:00
|
|
|
// Short circuit if the trie is empty or already known
|
2015-10-05 11:37:56 -05:00
|
|
|
if root == emptyRoot {
|
|
|
|
return
|
|
|
|
}
|
2022-07-15 06:55:51 -05:00
|
|
|
if s.membatch.hasNode(path) {
|
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 07:26:03 -05:00
|
|
|
return
|
|
|
|
}
|
2022-11-28 07:31:28 -06:00
|
|
|
owner, inner := ResolvePath(path)
|
2023-02-06 09:28:40 -06:00
|
|
|
if rawdb.HasTrieNode(s.database, owner, inner, root, s.scheme) {
|
2021-12-03 04:32:41 -06:00
|
|
|
return
|
2015-10-07 04:14:30 -05:00
|
|
|
}
|
2015-10-05 11:37:56 -05:00
|
|
|
// Assemble the new sub-trie sync request
|
2022-07-15 06:55:51 -05:00
|
|
|
req := &nodeRequest{
|
2015-10-05 11:37:56 -05:00
|
|
|
hash: root,
|
2022-07-15 06:55:51 -05:00
|
|
|
path: path,
|
2015-10-05 11:37:56 -05:00
|
|
|
callback: callback,
|
|
|
|
}
|
|
|
|
// If this sub-trie has a designated parent, link them together
|
|
|
|
if parent != (common.Hash{}) {
|
2022-07-15 06:55:51 -05:00
|
|
|
ancestor := s.nodeReqs[string(parentPath)]
|
2015-10-05 11:37:56 -05:00
|
|
|
if ancestor == nil {
|
|
|
|
panic(fmt.Sprintf("sub-trie ancestor not found: %x", parent))
|
|
|
|
}
|
|
|
|
ancestor.deps++
|
2022-07-15 06:55:51 -05:00
|
|
|
req.parent = ancestor
|
2015-10-05 11:37:56 -05:00
|
|
|
}
|
2022-07-15 06:55:51 -05:00
|
|
|
s.scheduleNodeRequest(req)
|
2015-10-05 11:37:56 -05:00
|
|
|
}
|
|
|
|
|
2020-08-21 07:10:40 -05:00
|
|
|
// AddCodeEntry schedules the direct retrieval of a contract code that should not
|
|
|
|
// be interpreted as a trie node, but rather accepted and stored into the database
|
|
|
|
// as is.
|
2022-07-15 06:55:51 -05:00
|
|
|
func (s *Sync) AddCodeEntry(hash common.Hash, path []byte, parent common.Hash, parentPath []byte) {
|
2015-10-07 04:14:30 -05:00
|
|
|
// Short circuit if the entry is empty or already known
|
|
|
|
if hash == emptyState {
|
|
|
|
return
|
|
|
|
}
|
2020-08-21 07:10:40 -05:00
|
|
|
if s.membatch.hasCode(hash) {
|
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 07:26:03 -05:00
|
|
|
return
|
|
|
|
}
|
2021-12-03 04:32:41 -06:00
|
|
|
// If database says duplicate, the blob is present for sure.
|
2022-11-28 07:31:28 -06:00
|
|
|
// Note we only check the existence with new code scheme, snap
|
2021-12-03 04:32:41 -06:00
|
|
|
// sync is expected to run with a fresh new node. Even there
|
|
|
|
// exists the code with legacy format, fetch and store with
|
|
|
|
// new scheme anyway.
|
2021-12-15 09:16:45 -06:00
|
|
|
if rawdb.HasCodeWithPrefix(s.database, hash) {
|
2021-12-03 04:32:41 -06:00
|
|
|
return
|
2015-10-07 04:14:30 -05:00
|
|
|
}
|
|
|
|
// Assemble the new sub-trie sync request
|
2022-07-15 06:55:51 -05:00
|
|
|
req := &codeRequest{
|
2020-08-26 05:05:06 -05:00
|
|
|
path: path,
|
|
|
|
hash: hash,
|
2015-10-07 04:14:30 -05:00
|
|
|
}
|
|
|
|
// If this sub-trie has a designated parent, link them together
|
|
|
|
if parent != (common.Hash{}) {
|
2022-07-15 06:55:51 -05:00
|
|
|
ancestor := s.nodeReqs[string(parentPath)] // the parent of codereq can ONLY be nodereq
|
2015-10-07 04:14:30 -05:00
|
|
|
if ancestor == nil {
|
|
|
|
panic(fmt.Sprintf("raw-entry ancestor not found: %x", parent))
|
|
|
|
}
|
|
|
|
ancestor.deps++
|
|
|
|
req.parents = append(req.parents, ancestor)
|
|
|
|
}
|
2022-07-15 06:55:51 -05:00
|
|
|
s.scheduleCodeRequest(req)
|
2015-10-07 04:14:30 -05:00
|
|
|
}
|
|
|
|
|
2020-08-28 02:50:37 -05:00
|
|
|
// Missing retrieves the known missing nodes from the trie for retrieval. To aid
|
|
|
|
// both eth/6x style fast sync and snap/1x style state sync, the paths of trie
|
|
|
|
// nodes are returned too, as well as separate hash list for codes.
|
2022-07-15 06:55:51 -05:00
|
|
|
func (s *Sync) Missing(max int) ([]string, []common.Hash, []common.Hash) {
|
2020-08-28 02:50:37 -05:00
|
|
|
var (
|
2022-07-15 06:55:51 -05:00
|
|
|
nodePaths []string
|
2020-08-28 02:50:37 -05:00
|
|
|
nodeHashes []common.Hash
|
|
|
|
codeHashes []common.Hash
|
|
|
|
)
|
|
|
|
for !s.queue.Empty() && (max == 0 || len(nodeHashes)+len(codeHashes) < max) {
|
2022-01-04 09:23:52 -06:00
|
|
|
// Retrieve the next item in line
|
2020-08-26 05:05:06 -05:00
|
|
|
item, prio := s.queue.Peek()
|
|
|
|
|
|
|
|
// If we have too many already-pending tasks for this depth, throttle
|
|
|
|
depth := int(prio >> 56)
|
|
|
|
if s.fetches[depth] > maxFetchesPerDepth {
|
|
|
|
break
|
|
|
|
}
|
|
|
|
// Item is allowed to be scheduled, add it to the task list
|
|
|
|
s.queue.Pop()
|
|
|
|
s.fetches[depth]++
|
2020-08-28 02:50:37 -05:00
|
|
|
|
2022-07-15 11:36:05 -05:00
|
|
|
switch item := item.(type) {
|
2022-07-15 06:55:51 -05:00
|
|
|
case common.Hash:
|
2022-07-15 11:36:05 -05:00
|
|
|
codeHashes = append(codeHashes, item)
|
2022-07-15 06:55:51 -05:00
|
|
|
case string:
|
2022-07-15 11:36:05 -05:00
|
|
|
req, ok := s.nodeReqs[item]
|
2022-07-15 06:55:51 -05:00
|
|
|
if !ok {
|
2022-07-15 11:36:05 -05:00
|
|
|
log.Error("Missing node request", "path", item)
|
2022-07-15 06:55:51 -05:00
|
|
|
continue // System very wrong, shouldn't happen
|
|
|
|
}
|
2022-07-15 11:36:05 -05:00
|
|
|
nodePaths = append(nodePaths, item)
|
2022-07-15 06:55:51 -05:00
|
|
|
nodeHashes = append(nodeHashes, req.hash)
|
2020-08-28 02:50:37 -05:00
|
|
|
}
|
2015-10-05 11:37:56 -05:00
|
|
|
}
|
2022-07-15 06:55:51 -05:00
|
|
|
return nodePaths, nodeHashes, codeHashes
|
2015-10-05 11:37:56 -05:00
|
|
|
}
|
|
|
|
|
2022-07-15 06:55:51 -05:00
|
|
|
// ProcessCode injects the received data for requested item. Note it can
|
2020-08-21 07:10:40 -05:00
|
|
|
// happpen that the single response commits two pending requests(e.g.
|
|
|
|
// there are two requests one for code and one for node but the hash
|
|
|
|
// is same). In this case the second response for the same hash will
|
|
|
|
// be treated as "non-requested" item or "already-processed" item but
|
|
|
|
// there is no downside.
|
2022-07-15 06:55:51 -05:00
|
|
|
func (s *Sync) ProcessCode(result CodeSyncResult) error {
|
|
|
|
// If the code was not requested or it's already processed, bail out
|
|
|
|
req := s.codeReqs[result.Hash]
|
|
|
|
if req == nil {
|
2020-08-21 07:10:40 -05:00
|
|
|
return ErrNotRequested
|
|
|
|
}
|
2022-07-15 06:55:51 -05:00
|
|
|
if req.data != nil {
|
|
|
|
return ErrAlreadyProcessed
|
2020-08-21 07:10:40 -05:00
|
|
|
}
|
2022-07-15 06:55:51 -05:00
|
|
|
req.data = result.Data
|
|
|
|
return s.commitCodeRequest(req)
|
|
|
|
}
|
2015-10-05 11:37:56 -05:00
|
|
|
|
2022-07-15 06:55:51 -05:00
|
|
|
// ProcessNode injects the received data for requested item. Note it can
|
|
|
|
// happen that the single response commits two pending requests(e.g.
|
|
|
|
// there are two requests one for code and one for node but the hash
|
|
|
|
// is same). In this case the second response for the same hash will
|
|
|
|
// be treated as "non-requested" item or "already-processed" item but
|
|
|
|
// there is no downside.
|
|
|
|
func (s *Sync) ProcessNode(result NodeSyncResult) error {
|
|
|
|
// If the trie node was not requested or it's already processed, bail out
|
|
|
|
req := s.nodeReqs[result.Path]
|
|
|
|
if req == nil {
|
|
|
|
return ErrNotRequested
|
2015-10-05 11:37:56 -05:00
|
|
|
}
|
2022-07-15 06:55:51 -05:00
|
|
|
if req.data != nil {
|
2020-08-21 07:10:40 -05:00
|
|
|
return ErrAlreadyProcessed
|
|
|
|
}
|
2022-07-15 06:55:51 -05:00
|
|
|
// Decode the node data content and update the request
|
|
|
|
node, err := decodeNode(req.hash.Bytes(), result.Data)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
req.data = result.Data
|
|
|
|
|
|
|
|
// Create and schedule a request for all the children nodes
|
|
|
|
requests, err := s.children(req, node)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if len(requests) == 0 && req.deps == 0 {
|
|
|
|
s.commitNodeRequest(req)
|
|
|
|
} else {
|
|
|
|
req.deps += len(requests)
|
|
|
|
for _, child := range requests {
|
|
|
|
s.scheduleNodeRequest(child)
|
|
|
|
}
|
|
|
|
}
|
2020-08-21 07:10:40 -05:00
|
|
|
return nil
|
2015-10-05 11:37:56 -05:00
|
|
|
}
|
|
|
|
|
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 07:26:03 -05:00
|
|
|
// Commit flushes the data stored in the internal membatch out to persistent
|
2019-10-28 12:50:11 -05:00
|
|
|
// storage, returning any occurred error.
|
|
|
|
func (s *Sync) Commit(dbw ethdb.Batch) error {
|
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 07:26:03 -05:00
|
|
|
// Dump the membatch into a database dbw
|
2022-07-15 06:55:51 -05:00
|
|
|
for path, value := range s.membatch.nodes {
|
2022-11-28 07:31:28 -06:00
|
|
|
owner, inner := ResolvePath([]byte(path))
|
2023-02-06 09:28:40 -06:00
|
|
|
rawdb.WriteTrieNode(dbw, owner, inner, s.membatch.hashes[path], value, s.scheme)
|
2020-08-21 07:10:40 -05:00
|
|
|
}
|
2022-07-15 06:55:51 -05:00
|
|
|
for hash, value := range s.membatch.codes {
|
|
|
|
rawdb.WriteCode(dbw, hash, value)
|
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 07:26:03 -05:00
|
|
|
}
|
|
|
|
// Drop the membatch data and return
|
|
|
|
s.membatch = newSyncMemBatch()
|
2019-10-28 12:50:11 -05:00
|
|
|
return nil
|
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 07:26:03 -05:00
|
|
|
}
|
|
|
|
|
2022-09-28 01:08:18 -05:00
|
|
|
// MemSize returns an estimated size (in bytes) of the data held in the membatch.
|
|
|
|
func (s *Sync) MemSize() uint64 {
|
|
|
|
return s.membatch.size
|
|
|
|
}
|
|
|
|
|
2015-10-07 04:14:30 -05:00
|
|
|
// Pending returns the number of state entries currently pending for download.
|
2018-05-29 10:48:43 -05:00
|
|
|
func (s *Sync) Pending() int {
|
2020-08-21 07:10:40 -05:00
|
|
|
return len(s.nodeReqs) + len(s.codeReqs)
|
2015-10-07 04:14:30 -05:00
|
|
|
}
|
|
|
|
|
2015-10-05 11:37:56 -05:00
|
|
|
// schedule inserts a new state retrieval request into the fetch queue. If there
|
|
|
|
// is already a pending request for this node, the new request will be discarded
|
|
|
|
// and only a parent reference added to the old one.
|
2022-07-15 06:55:51 -05:00
|
|
|
func (s *Sync) scheduleNodeRequest(req *nodeRequest) {
|
|
|
|
s.nodeReqs[string(req.path)] = req
|
|
|
|
|
|
|
|
// Schedule the request for future retrieval. This queue is shared
|
|
|
|
// by both node requests and code requests.
|
|
|
|
prio := int64(len(req.path)) << 56 // depth >= 128 will never happen, storage leaves will be included in their parents
|
|
|
|
for i := 0; i < 14 && i < len(req.path); i++ {
|
|
|
|
prio |= int64(15-req.path[i]) << (52 - i*4) // 15-nibble => lexicographic order
|
2020-08-21 07:10:40 -05:00
|
|
|
}
|
2022-07-15 06:55:51 -05:00
|
|
|
s.queue.Push(string(req.path), prio)
|
|
|
|
}
|
|
|
|
|
|
|
|
// schedule inserts a new state retrieval request into the fetch queue. If there
|
|
|
|
// is already a pending request for this node, the new request will be discarded
|
|
|
|
// and only a parent reference added to the old one.
|
|
|
|
func (s *Sync) scheduleCodeRequest(req *codeRequest) {
|
2015-10-05 11:37:56 -05:00
|
|
|
// If we're already requesting this node, add a new reference and stop
|
2022-07-15 06:55:51 -05:00
|
|
|
if old, ok := s.codeReqs[req.hash]; ok {
|
2015-10-05 11:37:56 -05:00
|
|
|
old.parents = append(old.parents, req.parents...)
|
|
|
|
return
|
|
|
|
}
|
2022-07-15 06:55:51 -05:00
|
|
|
s.codeReqs[req.hash] = req
|
2020-08-21 07:10:40 -05:00
|
|
|
|
|
|
|
// Schedule the request for future retrieval. This queue is shared
|
2022-07-15 06:55:51 -05:00
|
|
|
// by both node requests and code requests.
|
2020-08-26 05:05:06 -05:00
|
|
|
prio := int64(len(req.path)) << 56 // depth >= 128 will never happen, storage leaves will be included in their parents
|
|
|
|
for i := 0; i < 14 && i < len(req.path); i++ {
|
|
|
|
prio |= int64(15-req.path[i]) << (52 - i*4) // 15-nibble => lexicographic order
|
|
|
|
}
|
|
|
|
s.queue.Push(req.hash, prio)
|
2015-10-05 11:37:56 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
// children retrieves all the missing children of a state trie entry for future
|
|
|
|
// retrieval scheduling.
|
2022-07-15 06:55:51 -05:00
|
|
|
func (s *Sync) children(req *nodeRequest, object node) ([]*nodeRequest, error) {
|
2015-10-05 11:37:56 -05:00
|
|
|
// Gather all the children of the node, irrelevant whether known or not
|
2022-09-06 04:57:03 -05:00
|
|
|
type childNode struct {
|
2020-08-26 05:05:06 -05:00
|
|
|
path []byte
|
|
|
|
node node
|
2015-10-05 11:37:56 -05:00
|
|
|
}
|
2022-09-06 04:57:03 -05:00
|
|
|
var children []childNode
|
2015-10-05 11:37:56 -05:00
|
|
|
|
2016-10-21 10:34:17 -05:00
|
|
|
switch node := (object).(type) {
|
2016-10-14 11:04:33 -05:00
|
|
|
case *shortNode:
|
2020-08-28 02:50:37 -05:00
|
|
|
key := node.Key
|
|
|
|
if hasTerm(key) {
|
|
|
|
key = key[:len(key)-1]
|
|
|
|
}
|
2022-09-06 04:57:03 -05:00
|
|
|
children = []childNode{{
|
2020-08-26 05:05:06 -05:00
|
|
|
node: node.Val,
|
2020-08-28 02:50:37 -05:00
|
|
|
path: append(append([]byte(nil), req.path...), key...),
|
2015-10-05 11:37:56 -05:00
|
|
|
}}
|
2016-10-14 11:04:33 -05:00
|
|
|
case *fullNode:
|
2015-10-05 11:37:56 -05:00
|
|
|
for i := 0; i < 17; i++ {
|
2016-05-19 05:24:14 -05:00
|
|
|
if node.Children[i] != nil {
|
2022-09-06 04:57:03 -05:00
|
|
|
children = append(children, childNode{
|
2020-08-26 05:05:06 -05:00
|
|
|
node: node.Children[i],
|
|
|
|
path: append(append([]byte(nil), req.path...), byte(i)),
|
2015-10-05 11:37:56 -05:00
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
panic(fmt.Sprintf("unknown node: %+v", node))
|
|
|
|
}
|
|
|
|
// Iterate over the children, and request all unknown ones
|
2022-09-06 04:57:03 -05:00
|
|
|
var (
|
|
|
|
missing = make(chan *nodeRequest, len(children))
|
|
|
|
pending sync.WaitGroup
|
|
|
|
)
|
2015-10-05 11:37:56 -05:00
|
|
|
for _, child := range children {
|
|
|
|
// Notify any external watcher of a new key/value node
|
|
|
|
if req.callback != nil {
|
2016-10-21 10:34:17 -05:00
|
|
|
if node, ok := (child.node).(valueNode); ok {
|
core, eth: faster snapshot generation (#22504)
* eth/protocols: persist received state segments
* core: initial implementation
* core/state/snapshot: add tests
* core, eth: updates
* eth/protocols/snapshot: count flat state size
* core/state: add metrics
* core/state/snapshot: skip unnecessary deletion
* core/state/snapshot: rename
* core/state/snapshot: use the global batch
* core/state/snapshot: add logs and fix wiping
* core/state/snapshot: fix
* core/state/snapshot: save generation progress even if the batch is empty
* core/state/snapshot: fixes
* core/state/snapshot: fix initial account range length
* core/state/snapshot: fix initial account range
* eth/protocols/snap: store flat states during the healing
* eth/protocols/snap: print logs
* core/state/snapshot: refactor (#4)
* core/state/snapshot: refactor
* core/state/snapshot: tiny fix and polish
Co-authored-by: rjl493456442 <garyrong0905@gmail.com>
* core, eth: fixes
* core, eth: fix healing writer
* core, trie, eth: fix paths
* eth/protocols/snap: fix encoding
* eth, core: add debug log
* core/state/generate: release iterator asap (#5)
core/state/snapshot: less copy
core/state/snapshot: revert split loop
core/state/snapshot: handle storage becoming empty, improve test robustness
core/state: test modified codehash
core/state/snapshot: polish
* core/state/snapshot: optimize stats counter
* core, eth: add metric
* core/state/snapshot: update comments
* core/state/snapshot: improve tests
* core/state/snapshot: replace secure trie with standard trie
* core/state/snapshot: wrap return as the struct
* core/state/snapshot: skip wiping correct states
* core/state/snapshot: updates
* core/state/snapshot: fixes
* core/state/snapshot: fix panic due to reference flaw in closure
* core/state/snapshot: fix errors in state generation logic + fix log output
* core/state/snapshot: remove an error case
* core/state/snapshot: fix condition-check for exhausted snap state
* core/state/snapshot: use stackTrie for small tries
* core/state/snapshot: don't resolve small storage tries in vain
* core/state/snapshot: properly clean up storage of deleted accounts
* core/state/snapshot: avoid RLP-encoding in some cases + minor nitpicks
* core/state/snapshot: fix error (+testcase)
* core/state/snapshot: clean up tests a bit
* core/state/snapshot: work in progress on better tests
* core/state/snapshot: polish code
* core/state/snapshot: fix trie iteration abortion trigger
* core/state/snapshot: fixes flaws
* core/state/snapshot: remove panic
* core/state/snapshot: fix abort
* core/state/snapshot: more tests (plus failing testcase)
* core/state/snapshot: more testcases + fix for failing test
* core/state/snapshot: testcase for malformed data
* core/state/snapshot: some test nitpicks
* core/state/snapshot: improvements to logging
* core/state/snapshot: testcase to demo error in abortion
* core/state/snapshot: fix abortion
* cmd/geth: make verify-state report the root
* trie: fix failing test
* core/state/snapshot: add timer metrics
* core/state/snapshot: fix metrics
* core/state/snapshot: udpate tests
* eth/protocols/snap: write snapshot account even if code or state is needed
* core/state/snapshot: fix diskmore check
* core/state/snapshot: review fixes
* core/state/snapshot: improve error message
* cmd/geth: rename 'error' to 'err' in logs
* core/state/snapshot: fix some review concerns
* core/state/snapshot, eth/protocols/snap: clear snapshot marker when starting/resuming snap sync
* core: add error log
* core/state/snapshot: use proper timers for metrics collection
* core/state/snapshot: address some review concerns
* eth/protocols/snap: improved log message
* eth/protocols/snap: fix heal logs to condense infos
* core/state/snapshot: wait for generator termination before restarting
* core/state/snapshot: revert timers to counters to track total time
Co-authored-by: Martin Holst Swende <martin@swende.se>
Co-authored-by: Péter Szilágyi <peterke@gmail.com>
2021-04-14 15:23:11 -05:00
|
|
|
var paths [][]byte
|
|
|
|
if len(child.path) == 2*common.HashLength {
|
|
|
|
paths = append(paths, hexToKeybytes(child.path))
|
|
|
|
} else if len(child.path) == 4*common.HashLength {
|
|
|
|
paths = append(paths, hexToKeybytes(child.path[:2*common.HashLength]))
|
|
|
|
paths = append(paths, hexToKeybytes(child.path[2*common.HashLength:]))
|
|
|
|
}
|
2022-07-15 06:55:51 -05:00
|
|
|
if err := req.callback(paths, child.path, node, req.hash, req.path); err != nil {
|
2015-10-05 11:37:56 -05:00
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
// If the child references another node, resolve or schedule
|
2016-10-21 10:34:17 -05:00
|
|
|
if node, ok := (child.node).(hashNode); ok {
|
2015-10-05 11:37:56 -05:00
|
|
|
// Try to resolve the node from the local database
|
2022-07-15 06:55:51 -05:00
|
|
|
if s.membatch.hasNode(child.path) {
|
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 07:26:03 -05:00
|
|
|
continue
|
|
|
|
}
|
2022-09-06 04:57:03 -05:00
|
|
|
// Check the presence of children concurrently
|
|
|
|
pending.Add(1)
|
|
|
|
go func(child childNode) {
|
|
|
|
defer pending.Done()
|
|
|
|
|
|
|
|
// If database says duplicate, then at least the trie node is present
|
|
|
|
// and we hold the assumption that it's NOT legacy contract code.
|
2022-11-28 07:31:28 -06:00
|
|
|
var (
|
|
|
|
chash = common.BytesToHash(node)
|
|
|
|
owner, inner = ResolvePath(child.path)
|
|
|
|
)
|
2023-02-06 09:28:40 -06:00
|
|
|
if rawdb.HasTrieNode(s.database, owner, inner, chash, s.scheme) {
|
2022-09-06 04:57:03 -05:00
|
|
|
return
|
|
|
|
}
|
|
|
|
// Locally unknown node, schedule for retrieval
|
|
|
|
missing <- &nodeRequest{
|
|
|
|
path: child.path,
|
|
|
|
hash: chash,
|
|
|
|
parent: req,
|
|
|
|
callback: req.callback,
|
|
|
|
}
|
|
|
|
}(child)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
pending.Wait()
|
|
|
|
|
|
|
|
requests := make([]*nodeRequest, 0, len(children))
|
|
|
|
for done := false; !done; {
|
|
|
|
select {
|
|
|
|
case miss := <-missing:
|
|
|
|
requests = append(requests, miss)
|
|
|
|
default:
|
|
|
|
done = true
|
2015-10-05 11:37:56 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return requests, nil
|
|
|
|
}
|
|
|
|
|
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 07:26:03 -05:00
|
|
|
// commit finalizes a retrieval request and stores it into the membatch. If any
|
2015-10-05 11:37:56 -05:00
|
|
|
// of the referencing parent requests complete due to this commit, they are also
|
|
|
|
// committed themselves.
|
2022-07-15 06:55:51 -05:00
|
|
|
func (s *Sync) commitNodeRequest(req *nodeRequest) error {
|
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 07:26:03 -05:00
|
|
|
// Write the node content to the membatch
|
2022-07-15 06:55:51 -05:00
|
|
|
s.membatch.nodes[string(req.path)] = req.data
|
|
|
|
s.membatch.hashes[string(req.path)] = req.hash
|
2022-09-28 01:08:18 -05:00
|
|
|
// The size tracking refers to the db-batch, not the in-memory data.
|
|
|
|
// Therefore, we ignore the req.path, and account only for the hash+data
|
|
|
|
// which eventually is written to db.
|
|
|
|
s.membatch.size += common.HashLength + uint64(len(req.data))
|
2022-07-15 06:55:51 -05:00
|
|
|
delete(s.nodeReqs, string(req.path))
|
|
|
|
s.fetches[len(req.path)]--
|
|
|
|
|
|
|
|
// Check parent for completion
|
|
|
|
if req.parent != nil {
|
|
|
|
req.parent.deps--
|
|
|
|
if req.parent.deps == 0 {
|
|
|
|
if err := s.commitNodeRequest(req.parent); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
2020-08-21 07:10:40 -05:00
|
|
|
}
|
2022-07-15 06:55:51 -05:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// commit finalizes a retrieval request and stores it into the membatch. If any
|
|
|
|
// of the referencing parent requests complete due to this commit, they are also
|
|
|
|
// committed themselves.
|
|
|
|
func (s *Sync) commitCodeRequest(req *codeRequest) error {
|
|
|
|
// Write the node content to the membatch
|
|
|
|
s.membatch.codes[req.hash] = req.data
|
2022-09-28 01:08:18 -05:00
|
|
|
s.membatch.size += common.HashLength + uint64(len(req.data))
|
2022-07-15 06:55:51 -05:00
|
|
|
delete(s.codeReqs, req.hash)
|
|
|
|
s.fetches[len(req.path)]--
|
|
|
|
|
2015-10-05 11:37:56 -05:00
|
|
|
// Check all parents for completion
|
|
|
|
for _, parent := range req.parents {
|
|
|
|
parent.deps--
|
|
|
|
if parent.deps == 0 {
|
2022-07-15 06:55:51 -05:00
|
|
|
if err := s.commitNodeRequest(parent); err != nil {
|
2015-10-05 11:37:56 -05:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
2022-11-28 07:31:28 -06:00
|
|
|
|
|
|
|
// ResolvePath resolves the provided composite node path by separating the
|
|
|
|
// path in account trie if it's existent.
|
|
|
|
func ResolvePath(path []byte) (common.Hash, []byte) {
|
|
|
|
var owner common.Hash
|
|
|
|
if len(path) >= 2*common.HashLength {
|
|
|
|
owner = common.BytesToHash(hexToKeybytes(path[:2*common.HashLength]))
|
|
|
|
path = path[2*common.HashLength:]
|
|
|
|
}
|
|
|
|
return owner, path
|
|
|
|
}
|