erigon-pulse/cmd/integration
Mark Holt f2d0118a33
Bor snapshot block production (#8065)
I have added:

```go
{
	ID:          stages.BorHeimdall,
	Description: "Download Bor-specific data from Heimdall",
	Forward: func(firstCycle bool, badBlockUnwind bool, s *StageState, u Unwinder, tx kv.RwTx, logger log.Logger) error {
		if badBlockUnwind {
			return nil
		}
		return BorHeimdallForward(s, u, ctx, tx, borHeimdallCfg, true, logger)
	},
	Unwind: func(firstCycle bool, u *UnwindState, s *StageState, tx kv.RwTx, logger log.Logger) error {
		return BorHeimdallUnwind(u, ctx, s, tx, borHeimdallCfg)
	},
	Prune: func(firstCycle bool, p *PruneState, tx kv.RwTx, logger log.Logger) error {
		return BorHeimdallPrune(p, ctx, tx, borHeimdallCfg)
	},
},
```
To MiningStages as well as Default as otherwise bor events are not added
when the block producer creates new blocks.

There are a couple of questions I have around this implementation:

* Is this the right place to add this
* As the state is also executed when the default stage is processed ther
is some duplicate processing for the block producing node.
* There is a duplicated call to heimdall which could be removed if the
stages share state - but its not clear if we want to do this.
* I don't think the mining stage needs to prune as this will be
replicated in the default iteration

This can be tested using the devnet with the following arguments:

```
--chain bor-devnet --bor.localheimdall --scenarios state-sync
```

This will generate sync events via an ethereum devnet which are
transmitted to bor chain and will be executed at the end of the snapshot
delay, which results in events generated from the bor chain. This tests
the whole sync, block generation, event lifecycle. As it needs to wait
for sprints to end after a sufficient delay it is quite slow to run.
2023-08-30 08:06:09 +01:00
..
commands Bor snapshot block production (#8065) 2023-08-30 08:06:09 +01:00
main.go Move cli root context to erigon-lib (#3294) 2022-01-19 10:49:07 +07:00
Readme.md save 2023-07-29 12:08:38 +07:00

Integration - tool to run Erigon stages in custom way: run/reset single stage, run all stages but reorg every X blocks, etc...

Examples

All commands require parameter --datadir=<datadir> - I will skip it for readability.

integration --help
integration print_stages

# Run single stage 
integration stage_senders 
integration stage_exec  
integration stage_exec --block=1_000_000 # stop at 1M block
integration stage_hash_state 
integration stage_trie
integration stage_history
integration stage_tx_lookup

# Unwind single stage 10 blocks backward
integration stage_exec --unwind=10

# Drop data of single stage 
integration stage_exec --reset     
integration stage_history --reset

# Unwind single stage N blocks backward
integration stage_exec --unwind=N 
integration stage_history --unwind=N

# Run stage prune to block N
integration stage_exec --prune.to=N     
integration stage_history --prune.to=N

# Exec blocks, but don't commit changes (loose them)
integration stage_exec --no-commit
...

# Run tx replay with domains [requires 6th stage to be done before run]
integration state_domains --chain goerli --last-step=4 # stop replay when 4th step is merged
integration read_domains --chain goerli account <addr> <addr> ... # read values for given accounts 

# hack which allows to force clear unwind stack of all stages
clear_unwind_stack

For testing run all stages in "N blocks forward M blocks re-org" loop

Pre-requirements of state_stages command:

  • Headers/Bodies must be downloaded
  • TxSenders stage must be executed
make all
./build/bin/integration state_stages --datadir=<datadir> --unwind=10 --unwind.every=20 --pprof
integration reset_state # drops all stages after Senders stage (including it's db tables DB tables)

For example:

--unwind=1 --unwind.every=10  # 10 blocks forward, 1 block back, 10 blocks forward, ...
--unwind=10 --unwind.every=1  # 1 block forward, 10 blocks back, 1 blocks forward, ...
--unwind=10  # 10 blocks back, then stop
--integrity.fast=false --integrity.slow=false # it performs DB integrity checks each step. You can disable slow or fast checks.
--block # stop at exact blocks
--chaindata.reference # When finish all cycles, does comparison to this db file.

"Wrong trie root" problem - temporary solution

make all
./build/bin/integration stage_hash_state --datadir=<datadir> --reset
./build/bin/integration stage_trie --datadir=<datadir> --reset
# Then run TurobGeth as usually. It will take 2-3 hours to re-calculate dropped db tables

Copy data to another db

1. Stop Erigon
2. Create new db, by starting erigon in new directory: with option --datadir /path/to/copy-to/
(set new --db.pagesize option if need)
3. Stop Erigon again after about 1 minute (Steps 2 and 3 create a new empty db in /path/to/copy-to/chaindata )
4. Build integration: cd erigon; make integration
5. Run: ./build/bin/integration mdbx_to_mdbx --chaindata /existing/erigon/path/chaindata/ --chaindata.to /path/to/copy-to/chaindata/
6. cp -R /existing/erigon/path/snapshots /path/to/copy-to/snapshots
7. start erigon in new datadir as usualy

Clear bad blocks markers table in the case some block was marked as invalid after some error

It allows to process this blocks again

1. ./build/bin/integration clear_bad_blocks --datadir=<datadir>