Skip to content

v1.29.0
Compare
Choose a tag to compare
@brbrr brbrr released this 07 Oct 09:12
1.29.0
10412d1
This commit was signed with the committer’s verified signature.
brbrr Yaroslav Kukharuk
SSH Key Fingerprint: ZZLrij6mhNrVeQyPUwE9x96IU2N37+ecvU2poXAAzAc Learn about vigilant mode.

Major Highlights

Breaking changes

Configuration flag Discovery.Discv5Enabled is replaced with a more generic flag: Discovery.DiscoveryVersion with V4 as a default value. To enable v5 discovery, use the following: --Discovery.DiscoveryVersion=V5 .

Heuristic transaction censorship detection

We have introduced heuristics-based censorship detection in the Nethermind client. Censorship is detected using two kinds of heuristics, namely, high-paying transaction censorship and address censorship.

In the former, a block is marked potentially censored if the highest non-blob transaction included in the block is worse than the best non-blob transaction available in the pool. The latter, which could also be opted out of, requires specifying a list of addresses that we want to track censorship for. We count the number of tracked addresses to which transactions better than the worst non-blob transaction in the block is sent. If the number of such addresses in the block is less than half the number of these addresses in the pool, we mark the block as potentially censored. If two consecutive blocks are flagged as potentially censored, regardless of the kind, we detect censorship.

Detection of censorship sets the ShouldOverrideBuilder flag to true which acts as a circuit-breaker and communicates to the beacon node that it should fall back to local execution instead of relying on the builder's block.

Performance improvements

On Windows block validation performance used to degrade over several hours due to the default native allocator used by RocksDB. In #7418 we changed this to use the newer SegmentHeap that was introduced in Windows 10 and you can see there is now no throughput degradation over-time and Nethermind maintains a very high tip of chain processing speed.
Ethereum-throughput

Base and Ethereum target MGas/s chain speed are added for reference above.

With this change, as well as 25 other performance improvements, Nethermind maintains a throughput an order of magnitude higher than even Base’s current gaslimit on a gaming or high end workstation PC (with locally PCIe attached Samsung 990 Pro NVMes).

This is also reflected in the end to end new payload processing; receiving and parsing the Json request from the consensus client to producing the validated Json response per block on average in under 20ms.

Slot time for mainnet is 12000ms, and ideally without ePBS the EL should complete in under 4000ms; with ePBS it has the full slot to complete. So Nethermind; on this setup, even at max time is completing the block with 98% of headroom remaining.

image (2)

  • Reduced memory during Archive, Full Sync and head catchup
  • Introduced idle memory cleanup if waiting for new blocks from consensus layer; which can happen during head catchup, depending on consensus peering
  • Introducing a new Macro Op: EXTCODESIZE+POP which was a common pattern during the Shanghai DoS attacks; however the opcode pair combination can also be evaluated to a NOP not requiring to access the account or code for the address referred to.
  • Non-allocating key generation for In64 keys; this becomes impactful as these sync modes process more than 3000 blocks per second.
  • Calculate all the receipts’ blooms together in parallel
  • Fast wait-free and lockless Keccak cache; applied in a targeted manner (as most Keccaks are random), where the same address or UInt256 is keccak’d multiple times.
  • Further improvements to data prewarming for the transaction pipeline processing.

Changelog

New features

Bug fixes and stability

Optimizations:

Other changes

New Contributors

Full Changelog: 1.28.0...1.29.0-rc

Contributors

rubo, Scooletz, and 14 other contributors
Assets 8
Loading