We've released a hot fix, v1.5.12, to improve Fast Finality stability following the Lorentz hard fork.
The Lorentz hard fork halved the block interval, which also doubled the frequency of votes required for Fast Finality. An existing protection limited vote reception to 10 votes per second per peer. This limit, based on the old block time, is now too low.
Version 1.5.12 addresses this by increasing the vote reception limit to 40 votes per second. This adjustment ensures nodes can correctly process the increased vote traffic.
While your node will still function without this upgrade, widespread failure to upgrade could lead to nodes incorrectly rejecting Fast Finality votes. This could prevent validators from collecting enough votes and potentially disrupt the Fast Finality mechanism for the entire network.
To help support the stability of Fast Finality, we recommend upgrading your node to v1.5.12. The upgrade process is simple and only requires replacing your existing binary.
## Description Version 1.5.12 is a hot fix release that includes a single pull request aimed at enhancing the stability of Fast Finality following the Lorentz hard fork. Please upgrade your nodes to v1.5.12 to help strengthen the BSC's Fast Finality mechanism. For this release, simply replacing your binary is sufficient. **About this hot fix**: There was a DDoS protection rule for FastFinality, each remote peer is only allowed to send at most 10 votes per second. The number was calculated based 21 validators in each epoch and 3 seconds block interval, which is equal to 7(21/3) votes per second at most. But after Lorentz hard fork, with 1.5 seconds block interval, the vote frequency would be doubled to 14 votes per second. So the 10 votes per second is no longer valid. v1.5.12 increases it from 10 to 40, so it would be enough even after 0.75s block interval. **Any Risk If Nodes did not upgrade to v1.5.12?** Your node would still be able to work. But as the votes would be broadcasted in the whole BSC P2P network, if most of the nodes incorrectly reject some valid votes due to the rate limit control. Validators may not be able to collect enough votes, then the fast finality would be broken in this case. ## Changelog ### BUGFIX [#3057](https://github.com/bnb-chain/bsc/pull/3057) eth/protocols/bsc: adjust vote reception limit ## Assets | Assets | Sha256 Checksum | | :-----------: |------------| | mainnet.zip | f551e37fa21faf740195ee0c1b7497d704631a12ba8b4d89b3baf4db8df6c476 | | testnet.zip | 042a1884b00e6cd72af5c3e31c5985b9d8a78a29ccc19fb4ba660e0da1e621e7 | | geth_linux | 51698752ed3a2aa721c94b3403cfcc55c2a056f310c50d4609da3e546ddb6d64 | | geth_mac | 0d08a8ae29828b18eb428c9b1346485731da10b0f5c0f4b6b3a4506ca8124dd6 | | geth_windows | b8ddd8436746c499be2a685c82ff98b0bc0e528fac72ec7b004ffd721db58698 | | geth_linux_arm64 | 629a25867298488a05d59b548e4a59e553aafd630e5ec5918b1d6ef6599133f9 |