status-im
/
nimbus-eth2
mirror of https://github.com/status-im/nimbus-eth2.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Version 23.5.1

This commit is contained in:
Zahary Karadjov 2023-05-18 20:10:12 +03:00
parent 01549f6aa4
commit a167424fc0
No known key found for this signature in database
GPG Key ID: C1F42EAFF38D570F
3 changed files with 53 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
CHANGELOG.md
View File

@ -1,3 +1,49 @@
2023-05-18 v23.5.1
==================
Nimbus `v23.5.1` is a `medium-urgency` point release improving the compatibility of Nimbus with 3rd party validator clients and beacon nodes and introducing the support for incremental pruning. If you are still not using the `--history:prune` option, we recommend testing it in a non-production environment, as it will be enabled by default in our next release.
### Improvements
* The history pruning is now incremental and no longer results in start-up delays when the `--history:prune` option is enabled on an existing node:
https://github.com/status-im/nimbus-eth2/pull/4887
* Nimbus now uses the withdrawal address of the validator as a default choice for the fee recipient address if the user has not provided any value in the configuration:
https://github.com/status-im/nimbus-eth2/pull/4968
* Nimbus now supports the upcoming Capella hard-fork in the Gnosis network:
https://github.com/status-im/nimbus-eth2/pull/4936
### Fixes
* The Capella-related properties `MAX_BLS_TO_EXECUTION_CHANGES`, `MAX_WITHDRAWALS_PER_PAYLOAD`, `MAX_VALIDATORS_PER_WITHDRAWALS_SWEEP` and `DOMAIN_BLS_TO_EXECUTION_CHANGE` were missing from the `/eth/v1/config/spec` REST API end-point:
https://github.com/status-im/nimbus-eth2/pull/4925
* The `/eth/v1/validator/blinded_blocks/{slot}` was supplying incorrectly encoded response when requested to return SSZ data:
https://github.com/status-im/nimbus-eth2/pull/4943
* The safety checks associated with the `--weak-subjectivity-checkpoint` parameter are now compliant with the latest Ethereum specs:
https://github.com/status-im/nimbus-eth2/pull/4923
* The Nimbus validator client was using HTTP pipelining which is not supported by all beacon node implementations:
https://github.com/status-im/nimbus-eth2/pull/4950
* The "Connection to EL node degraded" warning is now printed only after sufficiently persistent connectivity issues with the EL client:
https://github.com/status-im/nimbus-eth2/pull/4960
* After being only briefly disconnected from the execution layer client, the Nimbus beacon node was prematurely setting the `execution_optimistic` flag when returning validator duties:
https://github.com/status-im/nimbus-eth2/pull/4955
* Nimbus now allows the builder to respond 500ms later than the spec-mandated timeout in order to account for possible additional delays introduced by proxies such as mev-boost:
https://github.com/status-im/nimbus-eth2/pull/4964
* During sync committee period transitions, for a brief period of time there was a low risk of producing an invalid sync committee contribution:
https://github.com/status-im/nimbus-eth2/pull/4953
* Nimbus `v23.5.0` introduced an unintended backwards-incompatible change in the parsing of remote keystores which is addressed in this release:
https://github.com/status-im/nimbus-eth2/pull/4967
2023-05-09 v23.5.0
==================

2
beacon_chain/version.nim
View File

@ -18,7 +18,7 @@ const
versionMajor* = 23
versionMinor* = 5
versionBuild* = 0
versionBuild* = 1
versionBlob* = "stateofus" # Single word - ends up in the default graffiti

10
docs/the_nimbus_book/src/suggested-fee-recipient.md
View File

@ -8,20 +8,22 @@ Each validator can have its own fee recipient set or a single recipient may be u
!!! warning
The execution client is not required to follow the fee recipient suggestion and may instead send the fees to a different address — only use execution clients you trust!
If no fee recipient is set up, the transaction fees are sent to the zero address, effectively causing them to be lost.
## Setting the fee recipient
Nimbus supports setting fee recipient per validator, or using defaults in both the validator client and beacon node.
Per-validator fee recipients are set using the [keymanager API](./keymanager-api.md).
Any validator without a per-validator recipient set will fall back to the `--suggested-fee-recipient` option if configured.
Any validator without a per-validator recipient set will fall back to the `--suggested-fee-recipient` option if configured or the withdrawal address of the validator.
For each validator, it selects from the first available, in the following order:
1. the keymanager API per-validator suggested fee recipient
1. The keymanager API per-validator suggested fee recipient
2. `--suggested-fee-recipient` in the validator client
3. `--suggested-fee-recipient` in the beacon node
4. If the validator has an associated [withdrawal address](./withdrawals.md), it will be used a final fallback option.
!!! warning
If none of the above are present, the transaction fees are sent to the zero address, effectively causing them to be lost.
For example, `nimbus_beacon_node --suggested-fee-recipient=0x70E47C843E0F6ab0991A3189c28F2957eb6d3842` suggests to the execution client that `0x70E47C843E0F6ab0991A3189c28F2957eb6d3842` might be the coinbase.
If this Nimbus node has two validators, one of which has its own suggested fee recipient via the keymanager API and the other does not, the former would use its own per-validator suggested fee recipient, while the latter would fall back to `0x70E47C843E0F6ab0991A3189c28F2957eb6d3842`.