Version 23.5.1

CHANGELOG.md

@@ -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
 ==================
 

beacon_chain/version.nim

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

docs/the_nimbus_book/src/suggested-fee-recipient.md

@@ -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`.