Update to the docs (#5106)

* Perform transaction

* Remove lighthouse/beacon/states/{state_id}/ssz

* Update database api example

* Update checkpoint sync

* minor update

* single beacon node

* add info in mev

* Merge remote-tracking branch 'origin/unstable' into testnet

* add builder_boost_factor example

* change to 50 for consistency
This commit is contained in:
chonghe 2024-01-30 11:03:37 +08:00 committed by GitHub
parent 47f05ac60d
commit 020702f8eb
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
5 changed files with 29 additions and 27 deletions

View File

@ -463,20 +463,6 @@ curl -X GET "http://localhost:5052/lighthouse/eth1/deposit_cache" -H "accept: a
} }
``` ```
### `/lighthouse/beacon/states/{state_id}/ssz`
Obtains a `BeaconState` in SSZ bytes. Useful for obtaining a genesis state.
The `state_id` parameter is identical to that used in the [Standard Beacon Node API
`beacon/state`
routes](https://ethereum.github.io/beacon-APIs/#/Beacon/getStateRoot).
```bash
curl -X GET "http://localhost:5052/lighthouse/beacon/states/0/ssz" | jq
```
*Example omitted for brevity, the body simply contains SSZ bytes.*
### `/lighthouse/liveness` ### `/lighthouse/liveness`
POST request that checks if any of the given validators have attested in the given epoch. Returns a list POST request that checks if any of the given validators have attested in the given epoch. Returns a list
@ -515,7 +501,7 @@ curl "http://localhost:5052/lighthouse/database/info" | jq
```json ```json
{ {
"schema_version": 16, "schema_version": 18,
"config": { "config": {
"slots_per_restore_point": 8192, "slots_per_restore_point": 8192,
"slots_per_restore_point_set_explicitly": false, "slots_per_restore_point_set_explicitly": false,
@ -523,18 +509,26 @@ curl "http://localhost:5052/lighthouse/database/info" | jq
"historic_state_cache_size": 1, "historic_state_cache_size": 1,
"compact_on_init": false, "compact_on_init": false,
"compact_on_prune": true, "compact_on_prune": true,
"prune_payloads": true "prune_payloads": true,
"prune_blobs": true,
"epochs_per_blob_prune": 1,
"blob_prune_margin_epochs": 0
}, },
"split": { "split": {
"slot": "5485952", "slot": "7454656",
"state_root": "0xcfe5d41e6ab5a9dab0de00d89d97ae55ecaeed3b08e4acda836e69b2bef698b4" "state_root": "0xbecfb1c8ee209854c611ebc967daa77da25b27f1a8ef51402fdbe060587d7653",
"block_root": "0x8730e946901b0a406313d36b3363a1b7091604e1346a3410c1a7edce93239a68"
}, },
"anchor": { "anchor": {
"anchor_slot": "5414688", "anchor_slot": "7451168",
"oldest_block_slot": "0", "oldest_block_slot": "3962593",
"oldest_block_parent": "0x0000000000000000000000000000000000000000000000000000000000000000", "oldest_block_parent": "0x4a39f21367b3b9cc272744d1e38817bda5daf38d190dc23dc091f09fb54acd97",
"state_upper_limit": "5414912", "state_upper_limit": "7454720",
"state_lower_limit": "8192" "state_lower_limit": "0"
},
"blob_info": {
"oldest_blob_slot": "7413769",
"blobs_db": true
} }
} }
``` ```

View File

@ -41,7 +41,7 @@ With the `--prefer-builder-proposals` flag, the validator client will always pre
lighthouse vc --builder-boost-factor <INTEGER> lighthouse vc --builder-boost-factor <INTEGER>
``` ```
With the `--builder-boost-factor` flag, a percentage multiplier is applied to the builder's payload value when choosing between a With the `--builder-boost-factor` flag, a percentage multiplier is applied to the builder's payload value when choosing between a
builder payload header and payload from the paired execution node. builder payload header and payload from the paired execution node. For example, `--builder-boost-factor 50` will only use the builder payload if it is 2x more profitable than the local payload.
In order to configure whether a validator queries for blinded blocks check out [this section.](#validator-client-configuration) In order to configure whether a validator queries for blinded blocks check out [this section.](#validator-client-configuration)
@ -157,6 +157,7 @@ You can also directly configure these fields in the `validator_definitions.yml`
suggested_fee_recipient: "0x6cc8dcbca744a6e4ffedb98e1d0df903b10abd21" suggested_fee_recipient: "0x6cc8dcbca744a6e4ffedb98e1d0df903b10abd21"
gas_limit: 30000001 gas_limit: 30000001
builder_proposals: true builder_proposals: true
builder_boost_factor: 50
- enabled: false - enabled: false
voting_public_key: "0xa5566f9ec3c6e1fdf362634ebec9ef7aceb0e460e5079714808388e5d48f4ae1e12897fed1bea951c17fa389d511e477" voting_public_key: "0xa5566f9ec3c6e1fdf362634ebec9ef7aceb0e460e5079714808388e5d48f4ae1e12897fed1bea951c17fa389d511e477"
type: local_keystore voting_keystore_path: /home/paul/.lighthouse/validators/0xa5566f9ec3c6e1fdf362634ebec9ef7aceb0e460e5079714808388e5d48f4ae1e12897fed1bea951c17fa389d511e477/voting-keystore.json type: local_keystore voting_keystore_path: /home/paul/.lighthouse/validators/0xa5566f9ec3c6e1fdf362634ebec9ef7aceb0e460e5079714808388e5d48f4ae1e12897fed1bea951c17fa389d511e477/voting-keystore.json
@ -164,6 +165,7 @@ You can also directly configure these fields in the `validator_definitions.yml`
suggested_fee_recipient: "0xa2e334e71511686bcfe38bb3ee1ad8f6babcc03d" suggested_fee_recipient: "0xa2e334e71511686bcfe38bb3ee1ad8f6babcc03d"
gas_limit: 33333333 gas_limit: 33333333
builder_proposals: true builder_proposals: true
prefer_builder_proposals: true
``` ```
## Circuit breaker conditions ## Circuit breaker conditions

View File

@ -1,9 +1,8 @@
# Checkpoint Sync # Checkpoint Sync
Since version 2.0.0 Lighthouse supports syncing from a recent finalized checkpoint. This is Lighthouse supports syncing from a recent finalized checkpoint. This is substantially faster than syncing from genesis, while still providing all the same features. Checkpoint sync is also safer as it protects the node from long-range attacks. Since 4.6.0, checkpoint sync is required by default and genesis sync will no longer work without the use of `--allow-insecure-genesis-sync`.
substantially faster than syncing from genesis, while still providing all the same features.
If you would like to quickly get started with checkpoint sync, read the sections below on: To quickly get started with checkpoint sync, read the sections below on:
1. [Automatic Checkpoint Sync](#automatic-checkpoint-sync) 1. [Automatic Checkpoint Sync](#automatic-checkpoint-sync)
2. [Backfilling Blocks](#backfilling-blocks) 2. [Backfilling Blocks](#backfilling-blocks)

View File

@ -193,3 +193,9 @@ Update the genesis time to now using:
./start_local_testnet.sh -p genesis.json ./start_local_testnet.sh -p genesis.json
``` ```
4. Block production using builder flow will start at epoch 4. 4. Block production using builder flow will start at epoch 4.
### Testing sending a transaction
Some addresses in the local testnet are seeded with testnet ETH, allowing users to carry out transactions. To send a transaction, we first add the address to a wallet, such as [Metamask](https://metamask.io/). The private keys for the addresses are listed [here](https://github.com/sigp/lighthouse/blob/441fc1691b69f9edc4bbdc6665f3efab16265c9b/testing/execution_engine_integration/src/execution_engine.rs#L13-L14).
Next, we add the local testnet to Metamask, a brief guide can be found [here](https://support.metamask.io/hc/en-us/articles/360043227612-How-to-add-a-custom-network-RPC). If you start the local testnet with default settings, the network RPC is: http://localhost:6001 and the `Chain ID` is `4242`, as defined in [`vars.env`](https://github.com/sigp/lighthouse/blob/441fc1691b69f9edc4bbdc6665f3efab16265c9b/scripts/local_testnet/vars.env#L42). Once the network and account are added, you should see that the account contains testnet ETH which allow us to carry out transactions.

View File

@ -67,4 +67,5 @@ exec $lighthouse_binary \
--target-peers $((BN_COUNT - 1)) \ --target-peers $((BN_COUNT - 1)) \
--execution-endpoint $execution_endpoint \ --execution-endpoint $execution_endpoint \
--execution-jwt $execution_jwt \ --execution-jwt $execution_jwt \
--http-allow-sync-stalled \
$BN_ARGS $BN_ARGS