775d222299
## Proposed Changes With proposer boosting implemented (#2822) we have an opportunity to re-org out late blocks. This PR adds three flags to the BN to control this behaviour: * `--disable-proposer-reorgs`: turn aggressive re-orging off (it's on by default). * `--proposer-reorg-threshold N`: attempt to orphan blocks with less than N% of the committee vote. If this parameter isn't set then N defaults to 20% when the feature is enabled. * `--proposer-reorg-epochs-since-finalization N`: only attempt to re-org late blocks when the number of epochs since finalization is less than or equal to N. The default is 2 epochs, meaning re-orgs will only be attempted when the chain is finalizing optimally. For safety Lighthouse will only attempt a re-org under very specific conditions: 1. The block being proposed is 1 slot after the canonical head, and the canonical head is 1 slot after its parent. i.e. at slot `n + 1` rather than building on the block from slot `n` we build on the block from slot `n - 1`. 2. The current canonical head received less than N% of the committee vote. N should be set depending on the proposer boost fraction itself, the fraction of the network that is believed to be applying it, and the size of the largest entity that could be hoarding votes. 3. The current canonical head arrived after the attestation deadline from our perspective. This condition was only added to support suppression of forkchoiceUpdated messages, but makes intuitive sense. 4. The block is being proposed in the first 2 seconds of the slot. This gives it time to propagate and receive the proposer boost. ## Additional Info For the initial idea and background, see: https://github.com/ethereum/consensus-specs/pull/2353#issuecomment-950238004 There is also a specification for this feature here: https://github.com/ethereum/consensus-specs/pull/3034 Co-authored-by: Michael Sproul <micsproul@gmail.com> Co-authored-by: pawan <pawandhananjay@gmail.com> |
||
|---|---|---|
| .. | ||
| beacon_node.sh | ||
| bootnode.sh | ||
| clean.sh | ||
| dump_logs.sh | ||
| ganache_test_node.sh | ||
| kill_processes.sh | ||
| README.md | ||
| reset_genesis_time.sh | ||
| setup.sh | ||
| start_local_testnet.sh | ||
| stop_local_testnet.sh | ||
| validator_client.sh | ||
| vars.env | ||
Simple Local Testnet
These scripts allow for running a small local testnet with multiple beacon nodes and validator clients. This setup can be useful for testing and development.
Requirements
The scripts require lcli and lighthouse to be installed on PATH. From the
root of this repository, run:
make
make install-lcli
Starting the testnet
Modify vars.env as desired.
Start a local eth1 ganache server plus boot node along with BN_COUNT
number of beacon nodes and VC_COUNT validator clients.
The start_local_testnet.sh script takes three options -v VC_COUNT, -d DEBUG_LEVEL and -h for help.
The options may be in any order or absent in which case they take the default value specified.
- VC_COUNT: the number of validator clients to create, default:
BN_COUNT - DEBUG_LEVEL: one of { error, warn, info, debug, trace }, default:
info
./start_local_testnet.sh
Stopping the testnet
This is not necessary before start_local_testnet.sh as it invokes stop_local_testnet.sh automatically.
./stop_local_testnet.sh
Manual creation of local testnet
These scripts are used by ./start_local_testnet.sh and may be used to manually
Start a local eth1 ganache server
./ganache_test_node.sh
Assuming you are happy with the configuration in vars.env, deploy the deposit contract, make deposits,
create the testnet directory, genesis state and validator keys with:
./setup.sh
Generate bootnode enr and start a discv5 bootnode so that multiple beacon nodes can find each other
./bootnode.sh
Start a beacon node:
./beacon_node.sh <DATADIR> <NETWORK-PORT> <HTTP-PORT> <OPTIONAL-DEBUG-LEVEL>
e.g.
./beacon_node.sh $HOME/.lighthouse/local-testnet/node_1 9000 8000
In a new terminal, start the validator client which will attach to the first beacon node:
./validator_client.sh <DATADIR> <BEACON-NODE-HTTP> <OPTIONAL-DEBUG-LEVEL>
e.g. to attach to the above created beacon node
./validator_client.sh $HOME/.lighthouse/local-testnet/node_1 http://localhost:8000
You can create additional beacon node and validator client instances with appropriate parameters.
Additional Info
Adjusting number and distribution of validators
The VALIDATOR_COUNT parameter is used to specify the number of insecure validator keystores to generate and make deposits for.
The BN_COUNT parameter is used to adjust the division of these generated keys among separate validator client instances.
For e.g. for VALIDATOR_COUNT=80 and BN_COUNT=4, the validator keys are distributed over 4 datadirs with 20 keystores per datadir. The datadirs are located in $DATADIR/node_{i} which can be passed to separate validator client
instances using the --datadir parameter.
Starting fresh
Delete the current testnet and all related files using. Generally not necessary as start_local_test.sh does this each time it starts.
./clean.sh
Updating the genesis time of the beacon state
If it's been a while since you ran ./setup then the genesis time of the
genesis state will be far in the future, causing lots of skip slots.
Update the genesis time to now using:
./reset_genesis_time.sh
Note: you probably want to just rerun
./start_local_testnet.shto start over but this is another option.