2016-04-14 11:18:24 -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/>.
|
|
|
|
|
2015-09-08 20:35:41 -05:00
|
|
|
package trie
|
|
|
|
|
|
|
|
import (
|
|
|
|
"bytes"
|
|
|
|
crand "crypto/rand"
|
2020-12-14 03:27:15 -06:00
|
|
|
"encoding/binary"
|
2023-03-20 03:09:35 -05:00
|
|
|
"fmt"
|
2015-09-08 20:35:41 -05:00
|
|
|
mrand "math/rand"
|
|
|
|
"testing"
|
|
|
|
|
|
|
|
"github.com/ethereum/go-ethereum/common"
|
2022-03-31 02:28:32 -05:00
|
|
|
"github.com/ethereum/go-ethereum/core/rawdb"
|
2017-10-24 08:19:09 -05:00
|
|
|
"github.com/ethereum/go-ethereum/crypto"
|
2018-09-24 07:57:49 -05:00
|
|
|
"github.com/ethereum/go-ethereum/ethdb/memorydb"
|
2023-06-19 04:41:31 -05:00
|
|
|
"golang.org/x/exp/slices"
|
2015-09-08 20:35:41 -05:00
|
|
|
)
|
|
|
|
|
2023-03-20 03:09:35 -05:00
|
|
|
// Prng is a pseudo random number generator seeded by strong randomness.
|
|
|
|
// The randomness is printed on startup in order to make failures reproducible.
|
|
|
|
var prng = initRnd()
|
|
|
|
|
|
|
|
func initRnd() *mrand.Rand {
|
|
|
|
var seed [8]byte
|
|
|
|
crand.Read(seed[:])
|
|
|
|
rnd := mrand.New(mrand.NewSource(int64(binary.LittleEndian.Uint64(seed[:]))))
|
|
|
|
fmt.Printf("Seed: %x\n", seed)
|
|
|
|
return rnd
|
|
|
|
}
|
|
|
|
|
|
|
|
func randBytes(n int) []byte {
|
|
|
|
r := make([]byte, n)
|
|
|
|
prng.Read(r)
|
|
|
|
return r
|
|
|
|
}
|
|
|
|
|
2018-05-10 04:49:27 -05:00
|
|
|
// makeProvers creates Merkle trie provers based on different implementations to
|
|
|
|
// test all variations.
|
2019-03-11 10:01:47 -05:00
|
|
|
func makeProvers(trie *Trie) []func(key []byte) *memorydb.Database {
|
|
|
|
var provers []func(key []byte) *memorydb.Database
|
2018-05-10 04:49:27 -05:00
|
|
|
|
|
|
|
// Create a direct trie based Merkle prover
|
2019-03-11 10:01:47 -05:00
|
|
|
provers = append(provers, func(key []byte) *memorydb.Database {
|
2018-09-24 07:57:49 -05:00
|
|
|
proof := memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
trie.Prove(key, proof)
|
2018-05-10 04:49:27 -05:00
|
|
|
return proof
|
|
|
|
})
|
|
|
|
// Create a leaf iterator based Merkle prover
|
2019-03-11 10:01:47 -05:00
|
|
|
provers = append(provers, func(key []byte) *memorydb.Database {
|
2018-09-24 07:57:49 -05:00
|
|
|
proof := memorydb.New()
|
cmd, core/state, eth, tests, trie: improve state reader (#27428)
The state availability is checked during the creation of a state reader.
- In hash-based database, if the specified root node does not exist on disk disk, then
the state reader won't be created and an error will be returned.
- In path-based database, if the specified state layer is not available, then the
state reader won't be created and an error will be returned.
This change also contains a stricter semantics regarding the `Commit` operation: once it has been performed, the trie is no longer usable, and certain operations will return an error.
2023-06-20 14:31:45 -05:00
|
|
|
if it := NewIterator(trie.MustNodeIterator(key)); it.Next() && bytes.Equal(key, it.Key) {
|
2018-05-10 04:49:27 -05:00
|
|
|
for _, p := range it.Prove() {
|
|
|
|
proof.Put(crypto.Keccak256(p), p)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return proof
|
|
|
|
})
|
|
|
|
return provers
|
|
|
|
}
|
|
|
|
|
2015-09-08 20:35:41 -05:00
|
|
|
func TestProof(t *testing.T) {
|
|
|
|
trie, vals := randomTrie(500)
|
|
|
|
root := trie.Hash()
|
2018-05-10 04:49:27 -05:00
|
|
|
for i, prover := range makeProvers(trie) {
|
|
|
|
for _, kv := range vals {
|
|
|
|
proof := prover(kv.k)
|
|
|
|
if proof == nil {
|
|
|
|
t.Fatalf("prover %d: missing key %x while constructing proof", i, kv.k)
|
|
|
|
}
|
2020-04-24 06:37:56 -05:00
|
|
|
val, err := VerifyProof(root, kv.k, proof)
|
2018-05-10 04:49:27 -05:00
|
|
|
if err != nil {
|
|
|
|
t.Fatalf("prover %d: failed to verify proof for key %x: %v\nraw proof: %x", i, kv.k, err, proof)
|
|
|
|
}
|
|
|
|
if !bytes.Equal(val, kv.v) {
|
|
|
|
t.Fatalf("prover %d: verified value mismatch for key %x: have %x, want %x", i, kv.k, val, kv.v)
|
|
|
|
}
|
2015-09-08 20:35:41 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestOneElementProof(t *testing.T) {
|
2024-02-13 07:49:53 -06:00
|
|
|
trie := NewEmpty(newTestDatabase(rawdb.NewMemoryDatabase(), rawdb.HashScheme))
|
2015-09-08 20:35:41 -05:00
|
|
|
updateString(trie, "k", "v")
|
2018-05-10 04:49:27 -05:00
|
|
|
for i, prover := range makeProvers(trie) {
|
|
|
|
proof := prover([]byte("k"))
|
|
|
|
if proof == nil {
|
|
|
|
t.Fatalf("prover %d: nil proof", i)
|
|
|
|
}
|
|
|
|
if proof.Len() != 1 {
|
|
|
|
t.Errorf("prover %d: proof should have one element", i)
|
|
|
|
}
|
2020-04-24 06:37:56 -05:00
|
|
|
val, err := VerifyProof(trie.Hash(), []byte("k"), proof)
|
2018-05-10 04:49:27 -05:00
|
|
|
if err != nil {
|
|
|
|
t.Fatalf("prover %d: failed to verify proof: %v\nraw proof: %x", i, err, proof)
|
|
|
|
}
|
|
|
|
if !bytes.Equal(val, []byte("v")) {
|
|
|
|
t.Fatalf("prover %d: verified value mismatch: have %x, want 'k'", i, val)
|
|
|
|
}
|
2015-09-08 20:35:41 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-05-20 07:45:38 -05:00
|
|
|
func TestBadProof(t *testing.T) {
|
|
|
|
trie, vals := randomTrie(800)
|
|
|
|
root := trie.Hash()
|
|
|
|
for i, prover := range makeProvers(trie) {
|
|
|
|
for _, kv := range vals {
|
|
|
|
proof := prover(kv.k)
|
|
|
|
if proof == nil {
|
|
|
|
t.Fatalf("prover %d: nil proof", i)
|
|
|
|
}
|
|
|
|
it := proof.NewIterator(nil, nil)
|
|
|
|
for i, d := 0, mrand.Intn(proof.Len()); i <= d; i++ {
|
|
|
|
it.Next()
|
|
|
|
}
|
|
|
|
key := it.Key()
|
|
|
|
val, _ := proof.Get(key)
|
|
|
|
proof.Delete(key)
|
|
|
|
it.Release()
|
|
|
|
|
|
|
|
mutateByte(val)
|
|
|
|
proof.Put(crypto.Keccak256(val), val)
|
|
|
|
|
|
|
|
if _, err := VerifyProof(root, kv.k, proof); err == nil {
|
|
|
|
t.Fatalf("prover %d: expected proof to fail for key %x", i, kv.k)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Tests that missing keys can also be proven. The test explicitly uses a single
|
|
|
|
// entry trie and checks for missing keys both before and after the single entry.
|
|
|
|
func TestMissingKeyProof(t *testing.T) {
|
2024-02-13 07:49:53 -06:00
|
|
|
trie := NewEmpty(newTestDatabase(rawdb.NewMemoryDatabase(), rawdb.HashScheme))
|
2020-05-20 07:45:38 -05:00
|
|
|
updateString(trie, "k", "v")
|
|
|
|
|
|
|
|
for i, key := range []string{"a", "j", "l", "z"} {
|
|
|
|
proof := memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
trie.Prove([]byte(key), proof)
|
2020-05-20 07:45:38 -05:00
|
|
|
|
|
|
|
if proof.Len() != 1 {
|
|
|
|
t.Errorf("test %d: proof should have one element", i)
|
|
|
|
}
|
|
|
|
val, err := VerifyProof(trie.Hash(), []byte(key), proof)
|
|
|
|
if err != nil {
|
|
|
|
t.Fatalf("test %d: failed to verify proof: %v\nraw proof: %x", i, err, proof)
|
|
|
|
}
|
|
|
|
if val != nil {
|
|
|
|
t.Fatalf("test %d: verified value mismatch: have %x, want nil", i, val)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// TestRangeProof tests normal range proof with both edge proofs
|
|
|
|
// as the existent proof. The test cases are generated randomly.
|
2020-04-24 06:37:56 -05:00
|
|
|
func TestRangeProof(t *testing.T) {
|
|
|
|
trie, vals := randomTrie(4096)
|
2023-06-19 04:41:31 -05:00
|
|
|
var entries []*kv
|
2020-04-24 06:37:56 -05:00
|
|
|
for _, kv := range vals {
|
|
|
|
entries = append(entries, kv)
|
|
|
|
}
|
2023-08-11 17:04:12 -05:00
|
|
|
slices.SortFunc(entries, (*kv).cmp)
|
2020-04-24 06:37:56 -05:00
|
|
|
for i := 0; i < 500; i++ {
|
|
|
|
start := mrand.Intn(len(entries))
|
2020-09-23 04:44:09 -05:00
|
|
|
end := mrand.Intn(len(entries)-start) + start + 1
|
|
|
|
|
|
|
|
proof := memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(entries[start].k, proof); err != nil {
|
2020-04-24 06:37:56 -05:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(entries[end-1].k, proof); err != nil {
|
2020-04-24 06:37:56 -05:00
|
|
|
t.Fatalf("Failed to prove the last node %v", err)
|
|
|
|
}
|
|
|
|
var keys [][]byte
|
|
|
|
var vals [][]byte
|
|
|
|
for i := start; i < end; i++ {
|
|
|
|
keys = append(keys, entries[i].k)
|
|
|
|
vals = append(vals, entries[i].v)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err := VerifyRangeProof(trie.Hash(), keys[0], keys, vals, proof)
|
2020-05-20 07:45:38 -05:00
|
|
|
if err != nil {
|
|
|
|
t.Fatalf("Case %d(%d->%d) expect no error, got %v", i, start, end-1, err)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-09-23 04:44:09 -05:00
|
|
|
// TestRangeProof tests normal range proof with two non-existent proofs.
|
|
|
|
// The test cases are generated randomly.
|
2020-05-20 07:45:38 -05:00
|
|
|
func TestRangeProofWithNonExistentProof(t *testing.T) {
|
|
|
|
trie, vals := randomTrie(4096)
|
2023-06-19 04:41:31 -05:00
|
|
|
var entries []*kv
|
2020-05-20 07:45:38 -05:00
|
|
|
for _, kv := range vals {
|
|
|
|
entries = append(entries, kv)
|
|
|
|
}
|
2023-08-11 17:04:12 -05:00
|
|
|
slices.SortFunc(entries, (*kv).cmp)
|
2020-05-20 07:45:38 -05:00
|
|
|
for i := 0; i < 500; i++ {
|
|
|
|
start := mrand.Intn(len(entries))
|
2020-09-23 04:44:09 -05:00
|
|
|
end := mrand.Intn(len(entries)-start) + start + 1
|
|
|
|
proof := memorydb.New()
|
2020-05-20 07:45:38 -05:00
|
|
|
|
2020-09-23 04:44:09 -05:00
|
|
|
// Short circuit if the decreased key is same with the previous key
|
2022-08-19 01:00:21 -05:00
|
|
|
first := decreaseKey(common.CopyBytes(entries[start].k))
|
2020-05-20 07:45:38 -05:00
|
|
|
if start != 0 && bytes.Equal(first, entries[start-1].k) {
|
|
|
|
continue
|
|
|
|
}
|
2020-09-23 04:44:09 -05:00
|
|
|
// Short circuit if the decreased key is underflow
|
|
|
|
if bytes.Compare(first, entries[start].k) > 0 {
|
|
|
|
continue
|
|
|
|
}
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(first, proof); err != nil {
|
2020-05-20 07:45:38 -05:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
if err := trie.Prove(entries[end-1].k, proof); err != nil {
|
2020-05-20 07:45:38 -05:00
|
|
|
t.Fatalf("Failed to prove the last node %v", err)
|
|
|
|
}
|
|
|
|
var keys [][]byte
|
|
|
|
var vals [][]byte
|
|
|
|
for i := start; i < end; i++ {
|
|
|
|
keys = append(keys, entries[i].k)
|
|
|
|
vals = append(vals, entries[i].v)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err := VerifyRangeProof(trie.Hash(), first, keys, vals, proof)
|
2020-04-24 06:37:56 -05:00
|
|
|
if err != nil {
|
|
|
|
t.Fatalf("Case %d(%d->%d) expect no error, got %v", i, start, end-1, err)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-05-20 07:45:38 -05:00
|
|
|
// TestRangeProofWithInvalidNonExistentProof tests such scenarios:
|
|
|
|
// - There exists a gap between the first element and the left edge proof
|
|
|
|
func TestRangeProofWithInvalidNonExistentProof(t *testing.T) {
|
|
|
|
trie, vals := randomTrie(4096)
|
2023-06-19 04:41:31 -05:00
|
|
|
var entries []*kv
|
2020-05-20 07:45:38 -05:00
|
|
|
for _, kv := range vals {
|
|
|
|
entries = append(entries, kv)
|
|
|
|
}
|
2023-08-11 17:04:12 -05:00
|
|
|
slices.SortFunc(entries, (*kv).cmp)
|
2020-05-20 07:45:38 -05:00
|
|
|
|
|
|
|
// Case 1
|
|
|
|
start, end := 100, 200
|
2022-08-19 01:00:21 -05:00
|
|
|
first := decreaseKey(common.CopyBytes(entries[start].k))
|
2020-09-23 04:44:09 -05:00
|
|
|
|
|
|
|
proof := memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(first, proof); err != nil {
|
2020-05-20 07:45:38 -05:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(entries[end-1].k, proof); err != nil {
|
2020-05-20 07:45:38 -05:00
|
|
|
t.Fatalf("Failed to prove the last node %v", err)
|
|
|
|
}
|
2020-09-23 04:44:09 -05:00
|
|
|
start = 105 // Gap created
|
|
|
|
k := make([][]byte, 0)
|
|
|
|
v := make([][]byte, 0)
|
2020-05-20 07:45:38 -05:00
|
|
|
for i := start; i < end; i++ {
|
|
|
|
k = append(k, entries[i].k)
|
|
|
|
v = append(v, entries[i].v)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err := VerifyRangeProof(trie.Hash(), first, k, v, proof)
|
2020-05-20 07:45:38 -05:00
|
|
|
if err == nil {
|
|
|
|
t.Fatalf("Expected to detect the error, got nil")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// TestOneElementRangeProof tests the proof with only one
|
|
|
|
// element. The first edge proof can be existent one or
|
|
|
|
// non-existent one.
|
|
|
|
func TestOneElementRangeProof(t *testing.T) {
|
|
|
|
trie, vals := randomTrie(4096)
|
2023-06-19 04:41:31 -05:00
|
|
|
var entries []*kv
|
2020-05-20 07:45:38 -05:00
|
|
|
for _, kv := range vals {
|
|
|
|
entries = append(entries, kv)
|
|
|
|
}
|
2023-08-11 17:04:12 -05:00
|
|
|
slices.SortFunc(entries, (*kv).cmp)
|
2020-05-20 07:45:38 -05:00
|
|
|
|
2020-09-23 04:44:09 -05:00
|
|
|
// One element with existent edge proof, both edge proofs
|
|
|
|
// point to the SAME key.
|
2020-05-20 07:45:38 -05:00
|
|
|
start := 1000
|
2020-09-23 04:44:09 -05:00
|
|
|
proof := memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(entries[start].k, proof); err != nil {
|
2020-05-20 07:45:38 -05:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err := VerifyRangeProof(trie.Hash(), entries[start].k, [][]byte{entries[start].k}, [][]byte{entries[start].v}, proof)
|
2020-09-23 04:44:09 -05:00
|
|
|
if err != nil {
|
|
|
|
t.Fatalf("Expected no error, got %v", err)
|
|
|
|
}
|
|
|
|
|
|
|
|
// One element with left non-existent edge proof
|
|
|
|
start = 1000
|
2022-08-19 01:00:21 -05:00
|
|
|
first := decreaseKey(common.CopyBytes(entries[start].k))
|
2020-09-23 04:44:09 -05:00
|
|
|
proof = memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(first, proof); err != nil {
|
2020-09-23 04:44:09 -05:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(entries[start].k, proof); err != nil {
|
2020-05-20 07:45:38 -05:00
|
|
|
t.Fatalf("Failed to prove the last node %v", err)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err = VerifyRangeProof(trie.Hash(), first, [][]byte{entries[start].k}, [][]byte{entries[start].v}, proof)
|
2020-05-20 07:45:38 -05:00
|
|
|
if err != nil {
|
|
|
|
t.Fatalf("Expected no error, got %v", err)
|
|
|
|
}
|
|
|
|
|
2020-09-23 04:44:09 -05:00
|
|
|
// One element with right non-existent edge proof
|
2020-05-20 07:45:38 -05:00
|
|
|
start = 1000
|
2022-08-19 01:00:21 -05:00
|
|
|
last := increaseKey(common.CopyBytes(entries[start].k))
|
2020-09-23 04:44:09 -05:00
|
|
|
proof = memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(entries[start].k, proof); err != nil {
|
2020-05-20 07:45:38 -05:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(last, proof); err != nil {
|
2020-05-20 07:45:38 -05:00
|
|
|
t.Fatalf("Failed to prove the last node %v", err)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err = VerifyRangeProof(trie.Hash(), entries[start].k, [][]byte{entries[start].k}, [][]byte{entries[start].v}, proof)
|
2020-09-23 04:44:09 -05:00
|
|
|
if err != nil {
|
|
|
|
t.Fatalf("Expected no error, got %v", err)
|
|
|
|
}
|
|
|
|
|
|
|
|
// One element with two non-existent edge proofs
|
|
|
|
start = 1000
|
2022-08-19 01:00:21 -05:00
|
|
|
first, last = decreaseKey(common.CopyBytes(entries[start].k)), increaseKey(common.CopyBytes(entries[start].k))
|
2020-09-23 04:44:09 -05:00
|
|
|
proof = memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(first, proof); err != nil {
|
2020-09-23 04:44:09 -05:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(last, proof); err != nil {
|
2020-09-23 04:44:09 -05:00
|
|
|
t.Fatalf("Failed to prove the last node %v", err)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err = VerifyRangeProof(trie.Hash(), first, [][]byte{entries[start].k}, [][]byte{entries[start].v}, proof)
|
2020-05-20 07:45:38 -05:00
|
|
|
if err != nil {
|
|
|
|
t.Fatalf("Expected no error, got %v", err)
|
|
|
|
}
|
2021-01-22 03:11:24 -06:00
|
|
|
|
|
|
|
// Test the mini trie with only a single element.
|
2024-02-13 07:49:53 -06:00
|
|
|
tinyTrie := NewEmpty(newTestDatabase(rawdb.NewMemoryDatabase(), rawdb.HashScheme))
|
2021-01-22 03:11:24 -06:00
|
|
|
entry := &kv{randBytes(32), randBytes(20), false}
|
2023-04-20 05:57:24 -05:00
|
|
|
tinyTrie.MustUpdate(entry.k, entry.v)
|
2021-01-22 03:11:24 -06:00
|
|
|
|
|
|
|
first = common.HexToHash("0x0000000000000000000000000000000000000000000000000000000000000000").Bytes()
|
|
|
|
last = entry.k
|
|
|
|
proof = memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := tinyTrie.Prove(first, proof); err != nil {
|
2021-01-22 03:11:24 -06:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := tinyTrie.Prove(last, proof); err != nil {
|
2021-01-22 03:11:24 -06:00
|
|
|
t.Fatalf("Failed to prove the last node %v", err)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err = VerifyRangeProof(tinyTrie.Hash(), first, [][]byte{entry.k}, [][]byte{entry.v}, proof)
|
2021-01-22 03:11:24 -06:00
|
|
|
if err != nil {
|
|
|
|
t.Fatalf("Expected no error, got %v", err)
|
|
|
|
}
|
2020-05-20 07:45:38 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
// TestAllElementsProof tests the range proof with all elements.
|
|
|
|
// The edge proofs can be nil.
|
|
|
|
func TestAllElementsProof(t *testing.T) {
|
|
|
|
trie, vals := randomTrie(4096)
|
2023-06-19 04:41:31 -05:00
|
|
|
var entries []*kv
|
2020-05-20 07:45:38 -05:00
|
|
|
for _, kv := range vals {
|
|
|
|
entries = append(entries, kv)
|
|
|
|
}
|
2023-08-11 17:04:12 -05:00
|
|
|
slices.SortFunc(entries, (*kv).cmp)
|
2020-05-20 07:45:38 -05:00
|
|
|
|
|
|
|
var k [][]byte
|
|
|
|
var v [][]byte
|
|
|
|
for i := 0; i < len(entries); i++ {
|
|
|
|
k = append(k, entries[i].k)
|
|
|
|
v = append(v, entries[i].v)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err := VerifyRangeProof(trie.Hash(), nil, k, v, nil)
|
2020-05-20 07:45:38 -05:00
|
|
|
if err != nil {
|
|
|
|
t.Fatalf("Expected no error, got %v", err)
|
|
|
|
}
|
|
|
|
|
2020-09-23 04:44:09 -05:00
|
|
|
// With edge proofs, it should still work.
|
|
|
|
proof := memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(entries[0].k, proof); err != nil {
|
2020-05-20 07:45:38 -05:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(entries[len(entries)-1].k, proof); err != nil {
|
2020-05-20 07:45:38 -05:00
|
|
|
t.Fatalf("Failed to prove the last node %v", err)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err = VerifyRangeProof(trie.Hash(), k[0], k, v, proof)
|
2020-09-23 04:44:09 -05:00
|
|
|
if err != nil {
|
|
|
|
t.Fatalf("Expected no error, got %v", err)
|
|
|
|
}
|
|
|
|
|
|
|
|
// Even with non-existent edge proofs, it should still work.
|
|
|
|
proof = memorydb.New()
|
|
|
|
first := common.HexToHash("0x0000000000000000000000000000000000000000000000000000000000000000").Bytes()
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(first, proof); err != nil {
|
2020-09-23 04:44:09 -05:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
if err := trie.Prove(entries[len(entries)-1].k, proof); err != nil {
|
2020-09-23 04:44:09 -05:00
|
|
|
t.Fatalf("Failed to prove the last node %v", err)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err = VerifyRangeProof(trie.Hash(), first, k, v, proof)
|
2020-05-20 07:45:38 -05:00
|
|
|
if err != nil {
|
|
|
|
t.Fatalf("Expected no error, got %v", err)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// TestSingleSideRangeProof tests the range starts from zero.
|
|
|
|
func TestSingleSideRangeProof(t *testing.T) {
|
2020-05-26 05:11:29 -05:00
|
|
|
for i := 0; i < 64; i++ {
|
2024-02-13 07:49:53 -06:00
|
|
|
trie := NewEmpty(newTestDatabase(rawdb.NewMemoryDatabase(), rawdb.HashScheme))
|
2023-06-19 04:41:31 -05:00
|
|
|
var entries []*kv
|
2020-05-26 05:11:29 -05:00
|
|
|
for i := 0; i < 4096; i++ {
|
|
|
|
value := &kv{randBytes(32), randBytes(20), false}
|
2023-04-20 05:57:24 -05:00
|
|
|
trie.MustUpdate(value.k, value.v)
|
2020-05-26 05:11:29 -05:00
|
|
|
entries = append(entries, value)
|
2020-05-20 07:45:38 -05:00
|
|
|
}
|
2023-08-11 17:04:12 -05:00
|
|
|
slices.SortFunc(entries, (*kv).cmp)
|
2020-05-26 05:11:29 -05:00
|
|
|
|
|
|
|
var cases = []int{0, 1, 50, 100, 1000, 2000, len(entries) - 1}
|
|
|
|
for _, pos := range cases {
|
2020-09-23 04:44:09 -05:00
|
|
|
proof := memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(common.Hash{}.Bytes(), proof); err != nil {
|
2020-05-26 05:11:29 -05:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(entries[pos].k, proof); err != nil {
|
2020-05-26 05:11:29 -05:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
|
|
|
k := make([][]byte, 0)
|
|
|
|
v := make([][]byte, 0)
|
|
|
|
for i := 0; i <= pos; i++ {
|
|
|
|
k = append(k, entries[i].k)
|
|
|
|
v = append(v, entries[i].v)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err := VerifyRangeProof(trie.Hash(), common.Hash{}.Bytes(), k, v, proof)
|
2020-05-26 05:11:29 -05:00
|
|
|
if err != nil {
|
|
|
|
t.Fatalf("Expected no error, got %v", err)
|
|
|
|
}
|
2020-05-20 07:45:38 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// TestBadRangeProof tests a few cases which the proof is wrong.
|
|
|
|
// The prover is expected to detect the error.
|
2020-04-24 06:37:56 -05:00
|
|
|
func TestBadRangeProof(t *testing.T) {
|
|
|
|
trie, vals := randomTrie(4096)
|
2023-06-19 04:41:31 -05:00
|
|
|
var entries []*kv
|
2020-04-24 06:37:56 -05:00
|
|
|
for _, kv := range vals {
|
|
|
|
entries = append(entries, kv)
|
|
|
|
}
|
2023-08-11 17:04:12 -05:00
|
|
|
slices.SortFunc(entries, (*kv).cmp)
|
2020-04-24 06:37:56 -05:00
|
|
|
|
|
|
|
for i := 0; i < 500; i++ {
|
|
|
|
start := mrand.Intn(len(entries))
|
2020-09-23 04:44:09 -05:00
|
|
|
end := mrand.Intn(len(entries)-start) + start + 1
|
|
|
|
proof := memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(entries[start].k, proof); err != nil {
|
2020-04-24 06:37:56 -05:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(entries[end-1].k, proof); err != nil {
|
2020-04-24 06:37:56 -05:00
|
|
|
t.Fatalf("Failed to prove the last node %v", err)
|
|
|
|
}
|
|
|
|
var keys [][]byte
|
|
|
|
var vals [][]byte
|
|
|
|
for i := start; i < end; i++ {
|
|
|
|
keys = append(keys, entries[i].k)
|
|
|
|
vals = append(vals, entries[i].v)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
var first = keys[0]
|
2020-04-24 06:37:56 -05:00
|
|
|
testcase := mrand.Intn(6)
|
|
|
|
var index int
|
|
|
|
switch testcase {
|
|
|
|
case 0:
|
|
|
|
// Modified key
|
|
|
|
index = mrand.Intn(end - start)
|
|
|
|
keys[index] = randBytes(32) // In theory it can't be same
|
|
|
|
case 1:
|
|
|
|
// Modified val
|
|
|
|
index = mrand.Intn(end - start)
|
|
|
|
vals[index] = randBytes(20) // In theory it can't be same
|
|
|
|
case 2:
|
|
|
|
// Gapped entry slice
|
|
|
|
index = mrand.Intn(end - start)
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
if (index == 0 && start < 100) || (index == end-start-1) {
|
2020-04-24 06:37:56 -05:00
|
|
|
continue
|
|
|
|
}
|
2020-05-06 08:33:57 -05:00
|
|
|
keys = append(keys[:index], keys[index+1:]...)
|
|
|
|
vals = append(vals[:index], vals[index+1:]...)
|
2020-04-24 06:37:56 -05:00
|
|
|
case 3:
|
2020-09-23 04:44:09 -05:00
|
|
|
// Out of order
|
|
|
|
index1 := mrand.Intn(end - start)
|
|
|
|
index2 := mrand.Intn(end - start)
|
|
|
|
if index1 == index2 {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
keys[index1], keys[index2] = keys[index2], keys[index1]
|
|
|
|
vals[index1], vals[index2] = vals[index2], vals[index1]
|
2020-04-24 06:37:56 -05:00
|
|
|
case 4:
|
2020-09-23 04:44:09 -05:00
|
|
|
// Set random key to nil, do nothing
|
2020-04-24 06:37:56 -05:00
|
|
|
index = mrand.Intn(end - start)
|
|
|
|
keys[index] = nil
|
|
|
|
case 5:
|
2020-09-23 04:44:09 -05:00
|
|
|
// Set random value to nil, deletion
|
2020-04-24 06:37:56 -05:00
|
|
|
index = mrand.Intn(end - start)
|
|
|
|
vals[index] = nil
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err := VerifyRangeProof(trie.Hash(), first, keys, vals, proof)
|
2020-04-24 06:37:56 -05:00
|
|
|
if err == nil {
|
|
|
|
t.Fatalf("%d Case %d index %d range: (%d->%d) expect error, got nil", i, testcase, index, start, end-1)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// TestGappedRangeProof focuses on the small trie with embedded nodes.
|
|
|
|
// If the gapped node is embedded in the trie, it should be detected too.
|
|
|
|
func TestGappedRangeProof(t *testing.T) {
|
2024-02-13 07:49:53 -06:00
|
|
|
trie := NewEmpty(newTestDatabase(rawdb.NewMemoryDatabase(), rawdb.HashScheme))
|
2020-04-24 06:37:56 -05:00
|
|
|
var entries []*kv // Sorted entries
|
|
|
|
for i := byte(0); i < 10; i++ {
|
|
|
|
value := &kv{common.LeftPadBytes([]byte{i}, 32), []byte{i}, false}
|
2023-04-20 05:57:24 -05:00
|
|
|
trie.MustUpdate(value.k, value.v)
|
2020-04-24 06:37:56 -05:00
|
|
|
entries = append(entries, value)
|
|
|
|
}
|
|
|
|
first, last := 2, 8
|
2020-09-23 04:44:09 -05:00
|
|
|
proof := memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(entries[first].k, proof); err != nil {
|
2020-04-24 06:37:56 -05:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(entries[last-1].k, proof); err != nil {
|
2020-04-24 06:37:56 -05:00
|
|
|
t.Fatalf("Failed to prove the last node %v", err)
|
|
|
|
}
|
|
|
|
var keys [][]byte
|
|
|
|
var vals [][]byte
|
|
|
|
for i := first; i < last; i++ {
|
|
|
|
if i == (first+last)/2 {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
keys = append(keys, entries[i].k)
|
|
|
|
vals = append(vals, entries[i].v)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err := VerifyRangeProof(trie.Hash(), keys[0], keys, vals, proof)
|
2020-04-24 06:37:56 -05:00
|
|
|
if err == nil {
|
|
|
|
t.Fatal("expect error, got nil")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-09-23 04:44:09 -05:00
|
|
|
// TestSameSideProofs tests the element is not in the range covered by proofs
|
|
|
|
func TestSameSideProofs(t *testing.T) {
|
|
|
|
trie, vals := randomTrie(4096)
|
2023-06-19 04:41:31 -05:00
|
|
|
var entries []*kv
|
2020-09-23 04:44:09 -05:00
|
|
|
for _, kv := range vals {
|
|
|
|
entries = append(entries, kv)
|
|
|
|
}
|
2023-08-11 17:04:12 -05:00
|
|
|
slices.SortFunc(entries, (*kv).cmp)
|
2020-09-23 04:44:09 -05:00
|
|
|
|
|
|
|
pos := 1000
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
first := common.CopyBytes(entries[0].k)
|
2020-09-23 04:44:09 -05:00
|
|
|
|
|
|
|
proof := memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(first, proof); err != nil {
|
2020-09-23 04:44:09 -05:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
if err := trie.Prove(entries[2000].k, proof); err != nil {
|
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
2020-09-23 04:44:09 -05:00
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err := VerifyRangeProof(trie.Hash(), first, [][]byte{entries[pos].k}, [][]byte{entries[pos].v}, proof)
|
2020-09-23 04:44:09 -05:00
|
|
|
if err == nil {
|
|
|
|
t.Fatalf("Expected error, got nil")
|
|
|
|
}
|
|
|
|
|
2022-08-19 01:00:21 -05:00
|
|
|
first = increaseKey(common.CopyBytes(entries[pos].k))
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
last := increaseKey(common.CopyBytes(entries[pos].k))
|
2022-08-19 01:00:21 -05:00
|
|
|
last = increaseKey(last)
|
2020-09-23 04:44:09 -05:00
|
|
|
|
|
|
|
proof = memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(first, proof); err != nil {
|
2020-09-23 04:44:09 -05:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(last, proof); err != nil {
|
2020-09-23 04:44:09 -05:00
|
|
|
t.Fatalf("Failed to prove the last node %v", err)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err = VerifyRangeProof(trie.Hash(), first, [][]byte{entries[pos].k}, [][]byte{entries[pos].v}, proof)
|
2020-09-23 04:44:09 -05:00
|
|
|
if err == nil {
|
|
|
|
t.Fatalf("Expected error, got nil")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-05-27 09:37:37 -05:00
|
|
|
func TestHasRightElement(t *testing.T) {
|
2024-02-13 07:49:53 -06:00
|
|
|
trie := NewEmpty(newTestDatabase(rawdb.NewMemoryDatabase(), rawdb.HashScheme))
|
2023-06-19 04:41:31 -05:00
|
|
|
var entries []*kv
|
2020-05-27 09:37:37 -05:00
|
|
|
for i := 0; i < 4096; i++ {
|
|
|
|
value := &kv{randBytes(32), randBytes(20), false}
|
2023-04-20 05:57:24 -05:00
|
|
|
trie.MustUpdate(value.k, value.v)
|
2020-05-27 09:37:37 -05:00
|
|
|
entries = append(entries, value)
|
|
|
|
}
|
2023-08-11 17:04:12 -05:00
|
|
|
slices.SortFunc(entries, (*kv).cmp)
|
2020-05-27 09:37:37 -05:00
|
|
|
|
|
|
|
var cases = []struct {
|
|
|
|
start int
|
|
|
|
end int
|
|
|
|
hasMore bool
|
|
|
|
}{
|
|
|
|
{-1, 1, true}, // single element with non-existent left proof
|
|
|
|
{0, 1, true}, // single element with existent left proof
|
|
|
|
{0, 10, true},
|
|
|
|
{50, 100, true},
|
|
|
|
{50, len(entries), false}, // No more element expected
|
2020-09-23 04:44:09 -05:00
|
|
|
{len(entries) - 1, len(entries), false}, // Single last element with two existent proofs(point to same key)
|
2020-05-27 09:37:37 -05:00
|
|
|
{0, len(entries), false}, // The whole set with existent left proof
|
|
|
|
{-1, len(entries), false}, // The whole set with non-existent left proof
|
|
|
|
}
|
|
|
|
for _, c := range cases {
|
|
|
|
var (
|
2020-09-23 04:44:09 -05:00
|
|
|
firstKey []byte
|
|
|
|
start = c.start
|
|
|
|
end = c.end
|
|
|
|
proof = memorydb.New()
|
2020-05-27 09:37:37 -05:00
|
|
|
)
|
|
|
|
if c.start == -1 {
|
|
|
|
firstKey, start = common.Hash{}.Bytes(), 0
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(firstKey, proof); err != nil {
|
2020-05-27 09:37:37 -05:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
firstKey = entries[c.start].k
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(entries[c.start].k, proof); err != nil {
|
2020-05-27 09:37:37 -05:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
if err := trie.Prove(entries[c.end-1].k, proof); err != nil {
|
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
2020-05-27 09:37:37 -05:00
|
|
|
}
|
|
|
|
k := make([][]byte, 0)
|
|
|
|
v := make([][]byte, 0)
|
2020-09-23 04:44:09 -05:00
|
|
|
for i := start; i < end; i++ {
|
2020-05-27 09:37:37 -05:00
|
|
|
k = append(k, entries[i].k)
|
|
|
|
v = append(v, entries[i].v)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
hasMore, err := VerifyRangeProof(trie.Hash(), firstKey, k, v, proof)
|
2020-05-27 09:37:37 -05:00
|
|
|
if err != nil {
|
|
|
|
t.Fatalf("Expected no error, got %v", err)
|
|
|
|
}
|
|
|
|
if hasMore != c.hasMore {
|
|
|
|
t.Fatalf("Wrong hasMore indicator, want %t, got %t", c.hasMore, hasMore)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-09-23 03:03:21 -05:00
|
|
|
// TestEmptyRangeProof tests the range proof with "no" element.
|
|
|
|
// The first edge proof must be a non-existent proof.
|
|
|
|
func TestEmptyRangeProof(t *testing.T) {
|
|
|
|
trie, vals := randomTrie(4096)
|
2023-06-19 04:41:31 -05:00
|
|
|
var entries []*kv
|
2020-09-23 03:03:21 -05:00
|
|
|
for _, kv := range vals {
|
|
|
|
entries = append(entries, kv)
|
|
|
|
}
|
2023-08-11 17:04:12 -05:00
|
|
|
slices.SortFunc(entries, (*kv).cmp)
|
2020-09-23 03:03:21 -05:00
|
|
|
|
|
|
|
var cases = []struct {
|
|
|
|
pos int
|
|
|
|
err bool
|
|
|
|
}{
|
|
|
|
{len(entries) - 1, false},
|
|
|
|
{500, true},
|
|
|
|
}
|
|
|
|
for _, c := range cases {
|
2020-09-23 04:44:09 -05:00
|
|
|
proof := memorydb.New()
|
2022-08-19 01:00:21 -05:00
|
|
|
first := increaseKey(common.CopyBytes(entries[c.pos].k))
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(first, proof); err != nil {
|
2020-09-23 03:03:21 -05:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err := VerifyRangeProof(trie.Hash(), first, nil, nil, proof)
|
2020-09-23 03:03:21 -05:00
|
|
|
if c.err && err == nil {
|
|
|
|
t.Fatalf("Expected error, got nil")
|
|
|
|
}
|
|
|
|
if !c.err && err != nil {
|
|
|
|
t.Fatalf("Expected no error, got %v", err)
|
|
|
|
}
|
2020-12-14 03:27:15 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// TestBloatedProof tests a malicious proof, where the proof is more or less the
|
2021-04-28 15:09:15 -05:00
|
|
|
// whole trie. Previously we didn't accept such packets, but the new APIs do, so
|
|
|
|
// lets leave this test as a bit weird, but present.
|
2020-12-14 03:27:15 -06:00
|
|
|
func TestBloatedProof(t *testing.T) {
|
|
|
|
// Use a small trie
|
|
|
|
trie, kvs := nonRandomTrie(100)
|
2023-06-19 04:41:31 -05:00
|
|
|
var entries []*kv
|
2020-12-14 03:27:15 -06:00
|
|
|
for _, kv := range kvs {
|
|
|
|
entries = append(entries, kv)
|
|
|
|
}
|
2023-08-11 17:04:12 -05:00
|
|
|
slices.SortFunc(entries, (*kv).cmp)
|
2020-12-14 03:27:15 -06:00
|
|
|
var keys [][]byte
|
|
|
|
var vals [][]byte
|
|
|
|
|
|
|
|
proof := memorydb.New()
|
2021-04-28 14:47:48 -05:00
|
|
|
// In the 'malicious' case, we add proofs for every single item
|
|
|
|
// (but only one key/value pair used as leaf)
|
2020-12-14 03:27:15 -06:00
|
|
|
for i, entry := range entries {
|
2023-06-19 09:28:40 -05:00
|
|
|
trie.Prove(entry.k, proof)
|
2020-12-14 03:27:15 -06:00
|
|
|
if i == 50 {
|
|
|
|
keys = append(keys, entry.k)
|
|
|
|
vals = append(vals, entry.v)
|
|
|
|
}
|
|
|
|
}
|
2021-04-28 14:47:48 -05:00
|
|
|
// For reference, we use the same function, but _only_ prove the first
|
|
|
|
// and last element
|
2020-12-14 03:27:15 -06:00
|
|
|
want := memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
trie.Prove(keys[0], want)
|
|
|
|
trie.Prove(keys[len(keys)-1], want)
|
2020-12-14 03:27:15 -06:00
|
|
|
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
if _, err := VerifyRangeProof(trie.Hash(), keys[0], keys, vals, proof); err != nil {
|
2021-04-28 15:09:15 -05:00
|
|
|
t.Fatalf("expected bloated proof to succeed, got %v", err)
|
2020-09-23 03:03:21 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-11-23 11:28:17 -06:00
|
|
|
// TestEmptyValueRangeProof tests normal range proof with both edge proofs
|
|
|
|
// as the existent proof, but with an extra empty value included, which is a
|
|
|
|
// noop technically, but practically should be rejected.
|
|
|
|
func TestEmptyValueRangeProof(t *testing.T) {
|
|
|
|
trie, values := randomTrie(512)
|
2023-06-19 04:41:31 -05:00
|
|
|
var entries []*kv
|
2021-11-23 11:28:17 -06:00
|
|
|
for _, kv := range values {
|
|
|
|
entries = append(entries, kv)
|
|
|
|
}
|
2023-08-11 17:04:12 -05:00
|
|
|
slices.SortFunc(entries, (*kv).cmp)
|
2021-11-23 11:28:17 -06:00
|
|
|
|
|
|
|
// Create a new entry with a slightly modified key
|
|
|
|
mid := len(entries) / 2
|
|
|
|
key := common.CopyBytes(entries[mid-1].k)
|
|
|
|
for n := len(key) - 1; n >= 0; n-- {
|
|
|
|
if key[n] < 0xff {
|
|
|
|
key[n]++
|
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
|
|
|
noop := &kv{key, []byte{}, false}
|
|
|
|
entries = append(append(append([]*kv{}, entries[:mid]...), noop), entries[mid:]...)
|
|
|
|
|
|
|
|
start, end := 1, len(entries)-1
|
|
|
|
|
|
|
|
proof := memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(entries[start].k, proof); err != nil {
|
2021-11-23 11:28:17 -06:00
|
|
|
t.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(entries[end-1].k, proof); err != nil {
|
2021-11-23 11:28:17 -06:00
|
|
|
t.Fatalf("Failed to prove the last node %v", err)
|
|
|
|
}
|
|
|
|
var keys [][]byte
|
|
|
|
var vals [][]byte
|
|
|
|
for i := start; i < end; i++ {
|
|
|
|
keys = append(keys, entries[i].k)
|
|
|
|
vals = append(vals, entries[i].v)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err := VerifyRangeProof(trie.Hash(), keys[0], keys, vals, proof)
|
2021-11-23 11:28:17 -06:00
|
|
|
if err == nil {
|
|
|
|
t.Fatalf("Expected failure on noop entry")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// TestAllElementsEmptyValueRangeProof tests the range proof with all elements,
|
|
|
|
// but with an extra empty value included, which is a noop technically, but
|
|
|
|
// practically should be rejected.
|
|
|
|
func TestAllElementsEmptyValueRangeProof(t *testing.T) {
|
|
|
|
trie, values := randomTrie(512)
|
2023-06-19 04:41:31 -05:00
|
|
|
var entries []*kv
|
2021-11-23 11:28:17 -06:00
|
|
|
for _, kv := range values {
|
|
|
|
entries = append(entries, kv)
|
|
|
|
}
|
2023-08-11 17:04:12 -05:00
|
|
|
slices.SortFunc(entries, (*kv).cmp)
|
2021-11-23 11:28:17 -06:00
|
|
|
|
|
|
|
// Create a new entry with a slightly modified key
|
|
|
|
mid := len(entries) / 2
|
|
|
|
key := common.CopyBytes(entries[mid-1].k)
|
|
|
|
for n := len(key) - 1; n >= 0; n-- {
|
|
|
|
if key[n] < 0xff {
|
|
|
|
key[n]++
|
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
|
|
|
noop := &kv{key, []byte{}, false}
|
|
|
|
entries = append(append(append([]*kv{}, entries[:mid]...), noop), entries[mid:]...)
|
|
|
|
|
|
|
|
var keys [][]byte
|
|
|
|
var vals [][]byte
|
|
|
|
for i := 0; i < len(entries); i++ {
|
|
|
|
keys = append(keys, entries[i].k)
|
|
|
|
vals = append(vals, entries[i].v)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err := VerifyRangeProof(trie.Hash(), nil, keys, vals, nil)
|
2021-11-23 11:28:17 -06:00
|
|
|
if err == nil {
|
|
|
|
t.Fatalf("Expected failure on noop entry")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-05-20 07:45:38 -05:00
|
|
|
// mutateByte changes one byte in b.
|
|
|
|
func mutateByte(b []byte) {
|
|
|
|
for r := mrand.Intn(len(b)); ; {
|
|
|
|
new := byte(mrand.Intn(255))
|
|
|
|
if new != b[r] {
|
|
|
|
b[r] = new
|
|
|
|
break
|
2018-05-10 04:49:27 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-08-19 01:00:21 -05:00
|
|
|
func increaseKey(key []byte) []byte {
|
2020-05-20 07:45:38 -05:00
|
|
|
for i := len(key) - 1; i >= 0; i-- {
|
|
|
|
key[i]++
|
|
|
|
if key[i] != 0x0 {
|
|
|
|
break
|
2015-09-08 20:35:41 -05:00
|
|
|
}
|
|
|
|
}
|
2020-05-20 07:45:38 -05:00
|
|
|
return key
|
2015-09-08 20:35:41 -05:00
|
|
|
}
|
|
|
|
|
2022-08-19 01:00:21 -05:00
|
|
|
func decreaseKey(key []byte) []byte {
|
2020-05-20 07:45:38 -05:00
|
|
|
for i := len(key) - 1; i >= 0; i-- {
|
|
|
|
key[i]--
|
|
|
|
if key[i] != 0xff {
|
2015-09-08 20:35:41 -05:00
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
2020-05-20 07:45:38 -05:00
|
|
|
return key
|
2015-09-08 20:35:41 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
func BenchmarkProve(b *testing.B) {
|
|
|
|
trie, vals := randomTrie(100)
|
|
|
|
var keys []string
|
|
|
|
for k := range vals {
|
|
|
|
keys = append(keys, k)
|
|
|
|
}
|
|
|
|
|
|
|
|
b.ResetTimer()
|
|
|
|
for i := 0; i < b.N; i++ {
|
|
|
|
kv := vals[keys[i%len(keys)]]
|
2018-09-24 07:57:49 -05:00
|
|
|
proofs := memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
if trie.Prove(kv.k, proofs); proofs.Len() == 0 {
|
2017-10-24 08:19:09 -05:00
|
|
|
b.Fatalf("zero length proof for %x", kv.k)
|
2015-09-08 20:35:41 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func BenchmarkVerifyProof(b *testing.B) {
|
|
|
|
trie, vals := randomTrie(100)
|
|
|
|
root := trie.Hash()
|
|
|
|
var keys []string
|
2019-03-11 10:01:47 -05:00
|
|
|
var proofs []*memorydb.Database
|
2015-09-08 20:35:41 -05:00
|
|
|
for k := range vals {
|
|
|
|
keys = append(keys, k)
|
2018-09-24 07:57:49 -05:00
|
|
|
proof := memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
trie.Prove([]byte(k), proof)
|
2017-10-24 08:19:09 -05:00
|
|
|
proofs = append(proofs, proof)
|
2015-09-08 20:35:41 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
b.ResetTimer()
|
|
|
|
for i := 0; i < b.N; i++ {
|
|
|
|
im := i % len(keys)
|
2020-04-24 06:37:56 -05:00
|
|
|
if _, err := VerifyProof(root, []byte(keys[im]), proofs[im]); err != nil {
|
2016-04-15 04:06:57 -05:00
|
|
|
b.Fatalf("key %x: %v", keys[im], err)
|
2015-09-08 20:35:41 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-24 06:37:56 -05:00
|
|
|
func BenchmarkVerifyRangeProof10(b *testing.B) { benchmarkVerifyRangeProof(b, 10) }
|
|
|
|
func BenchmarkVerifyRangeProof100(b *testing.B) { benchmarkVerifyRangeProof(b, 100) }
|
|
|
|
func BenchmarkVerifyRangeProof1000(b *testing.B) { benchmarkVerifyRangeProof(b, 1000) }
|
|
|
|
func BenchmarkVerifyRangeProof5000(b *testing.B) { benchmarkVerifyRangeProof(b, 5000) }
|
|
|
|
|
|
|
|
func benchmarkVerifyRangeProof(b *testing.B, size int) {
|
|
|
|
trie, vals := randomTrie(8192)
|
2023-06-19 04:41:31 -05:00
|
|
|
var entries []*kv
|
2020-04-24 06:37:56 -05:00
|
|
|
for _, kv := range vals {
|
|
|
|
entries = append(entries, kv)
|
|
|
|
}
|
2023-08-11 17:04:12 -05:00
|
|
|
slices.SortFunc(entries, (*kv).cmp)
|
2020-04-24 06:37:56 -05:00
|
|
|
|
|
|
|
start := 2
|
|
|
|
end := start + size
|
2020-09-23 04:44:09 -05:00
|
|
|
proof := memorydb.New()
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(entries[start].k, proof); err != nil {
|
2020-04-24 06:37:56 -05:00
|
|
|
b.Fatalf("Failed to prove the first node %v", err)
|
|
|
|
}
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(entries[end-1].k, proof); err != nil {
|
2020-04-24 06:37:56 -05:00
|
|
|
b.Fatalf("Failed to prove the last node %v", err)
|
|
|
|
}
|
|
|
|
var keys [][]byte
|
|
|
|
var values [][]byte
|
|
|
|
for i := start; i < end; i++ {
|
|
|
|
keys = append(keys, entries[i].k)
|
|
|
|
values = append(values, entries[i].v)
|
|
|
|
}
|
|
|
|
|
|
|
|
b.ResetTimer()
|
|
|
|
for i := 0; i < b.N; i++ {
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err := VerifyRangeProof(trie.Hash(), keys[0], keys, values, proof)
|
2020-04-24 06:37:56 -05:00
|
|
|
if err != nil {
|
|
|
|
b.Fatalf("Case %d(%d->%d) expect no error, got %v", i, start, end-1, err)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-04-28 14:47:48 -05:00
|
|
|
func BenchmarkVerifyRangeNoProof10(b *testing.B) { benchmarkVerifyRangeNoProof(b, 100) }
|
|
|
|
func BenchmarkVerifyRangeNoProof500(b *testing.B) { benchmarkVerifyRangeNoProof(b, 500) }
|
|
|
|
func BenchmarkVerifyRangeNoProof1000(b *testing.B) { benchmarkVerifyRangeNoProof(b, 1000) }
|
|
|
|
|
|
|
|
func benchmarkVerifyRangeNoProof(b *testing.B, size int) {
|
|
|
|
trie, vals := randomTrie(size)
|
2023-06-19 04:41:31 -05:00
|
|
|
var entries []*kv
|
2021-04-28 14:47:48 -05:00
|
|
|
for _, kv := range vals {
|
|
|
|
entries = append(entries, kv)
|
|
|
|
}
|
2023-08-11 17:04:12 -05:00
|
|
|
slices.SortFunc(entries, (*kv).cmp)
|
2021-04-28 14:47:48 -05:00
|
|
|
|
|
|
|
var keys [][]byte
|
|
|
|
var values [][]byte
|
|
|
|
for _, entry := range entries {
|
|
|
|
keys = append(keys, entry.k)
|
|
|
|
values = append(values, entry.v)
|
|
|
|
}
|
|
|
|
b.ResetTimer()
|
|
|
|
for i := 0; i < b.N; i++ {
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
_, err := VerifyRangeProof(trie.Hash(), keys[0], keys, values, nil)
|
2021-04-28 14:47:48 -05:00
|
|
|
if err != nil {
|
|
|
|
b.Fatalf("Expected no error, got %v", err)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-09-08 20:35:41 -05:00
|
|
|
func randomTrie(n int) (*Trie, map[string]*kv) {
|
2024-02-13 07:49:53 -06:00
|
|
|
trie := NewEmpty(newTestDatabase(rawdb.NewMemoryDatabase(), rawdb.HashScheme))
|
2015-09-08 20:35:41 -05:00
|
|
|
vals := make(map[string]*kv)
|
|
|
|
for i := byte(0); i < 100; i++ {
|
|
|
|
value := &kv{common.LeftPadBytes([]byte{i}, 32), []byte{i}, false}
|
|
|
|
value2 := &kv{common.LeftPadBytes([]byte{i + 10}, 32), []byte{i}, false}
|
2023-04-20 05:57:24 -05:00
|
|
|
trie.MustUpdate(value.k, value.v)
|
|
|
|
trie.MustUpdate(value2.k, value2.v)
|
2015-09-08 20:35:41 -05:00
|
|
|
vals[string(value.k)] = value
|
|
|
|
vals[string(value2.k)] = value2
|
|
|
|
}
|
|
|
|
for i := 0; i < n; i++ {
|
|
|
|
value := &kv{randBytes(32), randBytes(20), false}
|
2023-04-20 05:57:24 -05:00
|
|
|
trie.MustUpdate(value.k, value.v)
|
2015-09-08 20:35:41 -05:00
|
|
|
vals[string(value.k)] = value
|
|
|
|
}
|
|
|
|
return trie, vals
|
|
|
|
}
|
|
|
|
|
2020-12-14 03:27:15 -06:00
|
|
|
func nonRandomTrie(n int) (*Trie, map[string]*kv) {
|
2024-02-13 07:49:53 -06:00
|
|
|
trie := NewEmpty(newTestDatabase(rawdb.NewMemoryDatabase(), rawdb.HashScheme))
|
2020-12-14 03:27:15 -06:00
|
|
|
vals := make(map[string]*kv)
|
|
|
|
max := uint64(0xffffffffffffffff)
|
|
|
|
for i := uint64(0); i < uint64(n); i++ {
|
|
|
|
value := make([]byte, 32)
|
|
|
|
key := make([]byte, 32)
|
|
|
|
binary.LittleEndian.PutUint64(key, i)
|
|
|
|
binary.LittleEndian.PutUint64(value, i-max)
|
|
|
|
//value := &kv{common.LeftPadBytes([]byte{i}, 32), []byte{i}, false}
|
|
|
|
elem := &kv{key, value, false}
|
2023-04-20 05:57:24 -05:00
|
|
|
trie.MustUpdate(elem.k, elem.v)
|
2020-12-14 03:27:15 -06:00
|
|
|
vals[string(elem.k)] = elem
|
|
|
|
}
|
|
|
|
return trie, vals
|
|
|
|
}
|
2022-01-21 07:35:30 -06:00
|
|
|
|
|
|
|
func TestRangeProofKeysWithSharedPrefix(t *testing.T) {
|
|
|
|
keys := [][]byte{
|
|
|
|
common.Hex2Bytes("aa10000000000000000000000000000000000000000000000000000000000000"),
|
|
|
|
common.Hex2Bytes("aa20000000000000000000000000000000000000000000000000000000000000"),
|
|
|
|
}
|
|
|
|
vals := [][]byte{
|
|
|
|
common.Hex2Bytes("02"),
|
|
|
|
common.Hex2Bytes("03"),
|
|
|
|
}
|
2024-02-13 07:49:53 -06:00
|
|
|
trie := NewEmpty(newTestDatabase(rawdb.NewMemoryDatabase(), rawdb.HashScheme))
|
2022-01-21 07:35:30 -06:00
|
|
|
for i, key := range keys {
|
2023-04-20 05:57:24 -05:00
|
|
|
trie.MustUpdate(key, vals[i])
|
2022-01-21 07:35:30 -06:00
|
|
|
}
|
|
|
|
root := trie.Hash()
|
|
|
|
proof := memorydb.New()
|
|
|
|
start := common.Hex2Bytes("0000000000000000000000000000000000000000000000000000000000000000")
|
2023-06-19 09:28:40 -05:00
|
|
|
if err := trie.Prove(start, proof); err != nil {
|
2022-01-21 07:35:30 -06:00
|
|
|
t.Fatalf("failed to prove start: %v", err)
|
|
|
|
}
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
if err := trie.Prove(keys[len(keys)-1], proof); err != nil {
|
2022-01-21 07:35:30 -06:00
|
|
|
t.Fatalf("failed to prove end: %v", err)
|
|
|
|
}
|
|
|
|
|
trie: make rhs-proof align with last key in range proofs (#28311)
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once.
Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key.
So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf.
On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements).
Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders.
2023-10-13 09:05:29 -05:00
|
|
|
more, err := VerifyRangeProof(root, start, keys, vals, proof)
|
2022-01-21 07:35:30 -06:00
|
|
|
if err != nil {
|
|
|
|
t.Fatalf("failed to verify range proof: %v", err)
|
|
|
|
}
|
|
|
|
if more != false {
|
|
|
|
t.Error("expected more to be false")
|
|
|
|
}
|
|
|
|
}
|