2021-04-27 14:19:59 +00:00
|
|
|
// Copyright 2021 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 snap
|
|
|
|
|
|
|
|
import (
|
|
|
|
"testing"
|
|
|
|
|
|
|
|
"github.com/ethereum/go-ethereum/common"
|
|
|
|
)
|
|
|
|
|
|
|
|
// Tests that given a starting hash and a density, the hash ranger can correctly
|
|
|
|
// split up the remaining hash space into a fixed number of chunks.
|
|
|
|
func TestHashRanges(t *testing.T) {
|
|
|
|
tests := []struct {
|
|
|
|
head common.Hash
|
|
|
|
chunks uint64
|
|
|
|
starts []common.Hash
|
|
|
|
ends []common.Hash
|
|
|
|
}{
|
|
|
|
// Simple test case to split the entire hash range into 4 chunks
|
|
|
|
{
|
|
|
|
head: common.Hash{},
|
|
|
|
chunks: 4,
|
|
|
|
starts: []common.Hash{
|
|
|
|
{},
|
|
|
|
common.HexToHash("0x4000000000000000000000000000000000000000000000000000000000000000"),
|
|
|
|
common.HexToHash("0x8000000000000000000000000000000000000000000000000000000000000000"),
|
|
|
|
common.HexToHash("0xc000000000000000000000000000000000000000000000000000000000000000"),
|
|
|
|
},
|
|
|
|
ends: []common.Hash{
|
|
|
|
common.HexToHash("0x3fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff"),
|
|
|
|
common.HexToHash("0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff"),
|
|
|
|
common.HexToHash("0xbfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff"),
|
eth/protocols/snap: fix snap sync failure on empty storage range (#28306)
This change addresses an issue in snap sync, specifically when the entire sync process can be halted due to an encountered empty storage range.
Currently, on the snap sync client side, the response to an empty (partial) storage range is discarded as a non-delivery. However, this response can be a valid response, when the particular range requested does not contain any slots.
For instance, consider a large contract where the entire key space is divided into 16 chunks, and there are no available slots in the last chunk [0xf] -> [end]. When the node receives a request for this particular range, the response includes:
The proof with origin [0xf]
A nil storage slot set
If we simply discard this response, the finalization of the last range will be skipped, halting the entire sync process indefinitely. The test case TestSyncWithUnevenStorage can reproduce the scenario described above.
In addition, this change also defines the common variables MaxAddress and MaxHash.
2023-10-13 07:08:26 +00:00
|
|
|
common.MaxHash,
|
2021-04-27 14:19:59 +00:00
|
|
|
},
|
|
|
|
},
|
|
|
|
// Split a divisible part of the hash range up into 2 chunks
|
|
|
|
{
|
|
|
|
head: common.HexToHash("0x2000000000000000000000000000000000000000000000000000000000000000"),
|
|
|
|
chunks: 2,
|
|
|
|
starts: []common.Hash{
|
core, eth, internal, les: RPC methods and fields for EIP 1559 (#22964)
* internal/ethapi: add baseFee to RPCMarshalHeader
* internal/ethapi: add FeeCap, Tip and correct GasPrice to EIP-1559 RPCTransaction results
* core,eth,les,internal: add support for tip estimation in gas price oracle
* internal/ethapi,eth/gasprice: don't suggest tip larger than fee cap
* core/types,internal: use correct eip1559 terminology for json marshalling
* eth, internal/ethapi: fix rebase problems
* internal/ethapi: fix rpc name of basefee
* internal/ethapi: address review concerns
* core, eth, internal, les: simplify gasprice oracle (#25)
* core, eth, internal, les: simplify gasprice oracle
* eth/gasprice: fix typo
* internal/ethapi: minor tweak in tx args
* internal/ethapi: calculate basefee for pending block
* internal/ethapi: fix panic
* internal/ethapi, eth/tracers: simplify txargs ToMessage
* internal/ethapi: remove unused param
* core, eth, internal: fix regressions wrt effective gas price in the evm
* eth/gasprice: drop weird debug println
* internal/jsre/deps: hack in 1559 gas conversions into embedded web3
* internal/jsre/deps: hack basFee to decimal conversion
* internal/ethapi: init feecap and tipcap for legacy txs too
* eth, graphql, internal, les: fix gas price suggestion on all combos
* internal/jsre/deps: handle decimal tipcap and feecap
* eth, internal: minor review fixes
* graphql, internal: export max fee cap RPC endpoint
* internal/ethapi: fix crash in transaction_args
* internal/ethapi: minor refactor to make the code safer
Co-authored-by: Ryan Schneider <ryanleeschneider@gmail.com>
Co-authored-by: lightclient@protonmail.com <lightclient@protonmail.com>
Co-authored-by: gary rong <garyrong0905@gmail.com>
Co-authored-by: Péter Szilágyi <peterke@gmail.com>
2021-06-02 13:13:10 +00:00
|
|
|
{},
|
2021-04-27 14:19:59 +00:00
|
|
|
common.HexToHash("0x9000000000000000000000000000000000000000000000000000000000000000"),
|
|
|
|
},
|
|
|
|
ends: []common.Hash{
|
|
|
|
common.HexToHash("0x8fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff"),
|
eth/protocols/snap: fix snap sync failure on empty storage range (#28306)
This change addresses an issue in snap sync, specifically when the entire sync process can be halted due to an encountered empty storage range.
Currently, on the snap sync client side, the response to an empty (partial) storage range is discarded as a non-delivery. However, this response can be a valid response, when the particular range requested does not contain any slots.
For instance, consider a large contract where the entire key space is divided into 16 chunks, and there are no available slots in the last chunk [0xf] -> [end]. When the node receives a request for this particular range, the response includes:
The proof with origin [0xf]
A nil storage slot set
If we simply discard this response, the finalization of the last range will be skipped, halting the entire sync process indefinitely. The test case TestSyncWithUnevenStorage can reproduce the scenario described above.
In addition, this change also defines the common variables MaxAddress and MaxHash.
2023-10-13 07:08:26 +00:00
|
|
|
common.MaxHash,
|
2021-04-27 14:19:59 +00:00
|
|
|
},
|
|
|
|
},
|
|
|
|
// Split the entire hash range into a non divisible 3 chunks
|
|
|
|
{
|
|
|
|
head: common.Hash{},
|
|
|
|
chunks: 3,
|
|
|
|
starts: []common.Hash{
|
|
|
|
{},
|
|
|
|
common.HexToHash("0x5555555555555555555555555555555555555555555555555555555555555556"),
|
|
|
|
common.HexToHash("0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaac"),
|
|
|
|
},
|
|
|
|
ends: []common.Hash{
|
|
|
|
common.HexToHash("0x5555555555555555555555555555555555555555555555555555555555555555"),
|
|
|
|
common.HexToHash("0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab"),
|
eth/protocols/snap: fix snap sync failure on empty storage range (#28306)
This change addresses an issue in snap sync, specifically when the entire sync process can be halted due to an encountered empty storage range.
Currently, on the snap sync client side, the response to an empty (partial) storage range is discarded as a non-delivery. However, this response can be a valid response, when the particular range requested does not contain any slots.
For instance, consider a large contract where the entire key space is divided into 16 chunks, and there are no available slots in the last chunk [0xf] -> [end]. When the node receives a request for this particular range, the response includes:
The proof with origin [0xf]
A nil storage slot set
If we simply discard this response, the finalization of the last range will be skipped, halting the entire sync process indefinitely. The test case TestSyncWithUnevenStorage can reproduce the scenario described above.
In addition, this change also defines the common variables MaxAddress and MaxHash.
2023-10-13 07:08:26 +00:00
|
|
|
common.MaxHash,
|
2021-04-27 14:19:59 +00:00
|
|
|
},
|
|
|
|
},
|
|
|
|
// Split a part of hash range into a non divisible 3 chunks
|
|
|
|
{
|
|
|
|
head: common.HexToHash("0x2000000000000000000000000000000000000000000000000000000000000000"),
|
|
|
|
chunks: 3,
|
|
|
|
starts: []common.Hash{
|
|
|
|
{},
|
|
|
|
common.HexToHash("0x6aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab"),
|
|
|
|
common.HexToHash("0xb555555555555555555555555555555555555555555555555555555555555556"),
|
|
|
|
},
|
|
|
|
ends: []common.Hash{
|
|
|
|
common.HexToHash("0x6aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"),
|
|
|
|
common.HexToHash("0xb555555555555555555555555555555555555555555555555555555555555555"),
|
eth/protocols/snap: fix snap sync failure on empty storage range (#28306)
This change addresses an issue in snap sync, specifically when the entire sync process can be halted due to an encountered empty storage range.
Currently, on the snap sync client side, the response to an empty (partial) storage range is discarded as a non-delivery. However, this response can be a valid response, when the particular range requested does not contain any slots.
For instance, consider a large contract where the entire key space is divided into 16 chunks, and there are no available slots in the last chunk [0xf] -> [end]. When the node receives a request for this particular range, the response includes:
The proof with origin [0xf]
A nil storage slot set
If we simply discard this response, the finalization of the last range will be skipped, halting the entire sync process indefinitely. The test case TestSyncWithUnevenStorage can reproduce the scenario described above.
In addition, this change also defines the common variables MaxAddress and MaxHash.
2023-10-13 07:08:26 +00:00
|
|
|
common.MaxHash,
|
2021-04-27 14:19:59 +00:00
|
|
|
},
|
|
|
|
},
|
|
|
|
// Split a part of hash range into a non divisible 3 chunks, but with a
|
|
|
|
// meaningful space size for manual verification.
|
|
|
|
// - The head being 0xff...f0, we have 14 hashes left in the space
|
|
|
|
// - Chunking up 14 into 3 pieces is 4.(6), but we need the ceil of 5 to avoid a micro-last-chunk
|
2022-10-11 07:37:00 +00:00
|
|
|
// - Since the range is not divisible, the last interval will be shorter, capped at 0xff...f
|
2021-04-27 14:19:59 +00:00
|
|
|
// - The chunk ranges thus needs to be [..0, ..5], [..6, ..b], [..c, ..f]
|
|
|
|
{
|
|
|
|
head: common.HexToHash("0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0"),
|
|
|
|
chunks: 3,
|
|
|
|
starts: []common.Hash{
|
|
|
|
{},
|
|
|
|
common.HexToHash("0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff6"),
|
|
|
|
common.HexToHash("0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffc"),
|
|
|
|
},
|
|
|
|
ends: []common.Hash{
|
|
|
|
common.HexToHash("0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff5"),
|
|
|
|
common.HexToHash("0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffb"),
|
eth/protocols/snap: fix snap sync failure on empty storage range (#28306)
This change addresses an issue in snap sync, specifically when the entire sync process can be halted due to an encountered empty storage range.
Currently, on the snap sync client side, the response to an empty (partial) storage range is discarded as a non-delivery. However, this response can be a valid response, when the particular range requested does not contain any slots.
For instance, consider a large contract where the entire key space is divided into 16 chunks, and there are no available slots in the last chunk [0xf] -> [end]. When the node receives a request for this particular range, the response includes:
The proof with origin [0xf]
A nil storage slot set
If we simply discard this response, the finalization of the last range will be skipped, halting the entire sync process indefinitely. The test case TestSyncWithUnevenStorage can reproduce the scenario described above.
In addition, this change also defines the common variables MaxAddress and MaxHash.
2023-10-13 07:08:26 +00:00
|
|
|
common.MaxHash,
|
2021-04-27 14:19:59 +00:00
|
|
|
},
|
|
|
|
},
|
|
|
|
}
|
|
|
|
for i, tt := range tests {
|
|
|
|
r := newHashRange(tt.head, tt.chunks)
|
|
|
|
|
|
|
|
var (
|
|
|
|
starts = []common.Hash{{}}
|
|
|
|
ends = []common.Hash{r.End()}
|
|
|
|
)
|
|
|
|
for r.Next() {
|
|
|
|
starts = append(starts, r.Start())
|
|
|
|
ends = append(ends, r.End())
|
|
|
|
}
|
|
|
|
if len(starts) != len(tt.starts) {
|
|
|
|
t.Errorf("test %d: starts count mismatch: have %d, want %d", i, len(starts), len(tt.starts))
|
|
|
|
}
|
|
|
|
for j := 0; j < len(starts) && j < len(tt.starts); j++ {
|
|
|
|
if starts[j] != tt.starts[j] {
|
|
|
|
t.Errorf("test %d, start %d: hash mismatch: have %x, want %x", i, j, starts[j], tt.starts[j])
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if len(ends) != len(tt.ends) {
|
|
|
|
t.Errorf("test %d: ends count mismatch: have %d, want %d", i, len(ends), len(tt.ends))
|
|
|
|
}
|
|
|
|
for j := 0; j < len(ends) && j < len(tt.ends); j++ {
|
|
|
|
if ends[j] != tt.ends[j] {
|
|
|
|
t.Errorf("test %d, end %d: hash mismatch: have %x, want %x", i, j, ends[j], tt.ends[j])
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|