go-ethereum/tests/fuzzers
Martin Holst Swende f62c58f8de
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 16:05:29 +02:00
..
abi all: replace uses of ioutil with io and os (#24869) 2022-05-16 11:59:35 +02:00
bitutil tests/fuzzers: fix false positive in bitutil fuzzer (#22076) 2020-12-27 21:58:39 +01:00
bls12381 tests/fuzzers: supply gnark multiexp config, fixes #26669 (#26670) 2023-02-13 08:14:34 -05:00
bn256 tests/fuzzers/bn256: add PairingCheck fuzzer (#27252) 2023-05-16 07:27:54 -04:00
difficulty all: fix docstrings 2022-10-04 09:18:02 +02:00
keystore tests/fuzzers: improve the fuzzers (#21829) 2020-11-13 12:36:38 +01:00
les all: activate pbss as experimental feature (#26274) 2023-08-10 22:21:36 +03:00
rangeproof trie: make rhs-proof align with last key in range proofs (#28311) 2023-10-13 16:05:29 +02:00
rlp test/fuzzers: fuzz rlp handling of big.Int and uint256.Int (#26917) 2023-04-03 05:42:34 -04:00
runtime all: fix spelling mistakes (#25961) 2022-10-11 09:37:00 +02:00
secp256k1 all: update license headers and AUTHORS from git history (#24947) 2022-05-24 20:39:40 +02:00
snap cmd, core, eth, graphql, trie: no persisted clean trie cache file (#27525) 2023-07-04 10:21:06 +03:00
stacktrie trie: remove owner and binary marshaling from stacktrie (#28291) 2023-10-11 06:12:45 +02:00
trie all: activate pbss as experimental feature (#26274) 2023-08-10 22:21:36 +03:00
txfetcher eth: enforce announcement metadatas and drop peers violating the protocol (#28261) 2023-10-10 11:35:51 +03:00
vflux all: replace uses of ioutil with io and os (#24869) 2022-05-16 11:59:35 +02:00
README.md all: fix typos in comments (#21118) 2020-05-25 10:21:28 +02:00

Fuzzers

To run a fuzzer locally, you need go-fuzz installed.

First build a fuzzing-binary out of the selected package:

(cd ./rlp && CGO_ENABLED=0 go-fuzz-build .)

That command should generate a rlp-fuzz.zip in the rlp/ directory. If you are already in that directory, you can do

[user@work rlp]$ go-fuzz
2019/11/26 13:36:54 workers: 6, corpus: 3 (3s ago), crashers: 0, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 3s
2019/11/26 13:36:57 workers: 6, corpus: 3 (6s ago), crashers: 0, restarts: 1/0, execs: 0 (0/sec), cover: 1054, uptime: 6s
2019/11/26 13:37:00 workers: 6, corpus: 3 (9s ago), crashers: 0, restarts: 1/8358, execs: 25074 (2786/sec), cover: 1054, uptime: 9s
2019/11/26 13:37:03 workers: 6, corpus: 3 (12s ago), crashers: 0, restarts: 1/8497, execs: 50986 (4249/sec), cover: 1054, uptime: 12s
2019/11/26 13:37:06 workers: 6, corpus: 3 (15s ago), crashers: 0, restarts: 1/9330, execs: 74640 (4976/sec), cover: 1054, uptime: 15s
2019/11/26 13:37:09 workers: 6, corpus: 3 (18s ago), crashers: 0, restarts: 1/9948, execs: 99482 (5527/sec), cover: 1054, uptime: 18s
2019/11/26 13:37:12 workers: 6, corpus: 3 (21s ago), crashers: 0, restarts: 1/9428, execs: 122568 (5836/sec), cover: 1054, uptime: 21s
2019/11/26 13:37:15 workers: 6, corpus: 3 (24s ago), crashers: 0, restarts: 1/9676, execs: 145152 (6048/sec), cover: 1054, uptime: 24s
2019/11/26 13:37:18 workers: 6, corpus: 3 (27s ago), crashers: 0, restarts: 1/9855, execs: 167538 (6205/sec), cover: 1054, uptime: 27s
2019/11/26 13:37:21 workers: 6, corpus: 3 (30s ago), crashers: 0, restarts: 1/9645, execs: 192901 (6430/sec), cover: 1054, uptime: 30s
2019/11/26 13:37:24 workers: 6, corpus: 3 (33s ago), crashers: 0, restarts: 1/9967, execs: 219294 (6645/sec), cover: 1054, uptime: 33s

Otherwise:

go-fuzz -bin ./rlp/rlp-fuzz.zip

Notes

Once a 'crasher' is found, the fuzzer tries to avoid reporting the same vector twice, so stores the fault in the suppressions folder. Thus, if you e.g. make changes to fix a bug, you should remove all data from the suppressions-folder, to verify that the issue is indeed resolved.

Also, if you have only one and the same exit-point for multiple different types of test, the suppression can make the fuzzer hide different types of errors. So make sure that each type of failure is unique (for an example, see the rlp fuzzer, where a counter i is used to differentiate between failures:

		if !bytes.Equal(input, output) {
			panic(fmt.Sprintf("case %d: encode-decode is not equal, \ninput : %x\noutput: %x", i, input, output))
		}