CoinVoice has learned that, according to a report by Cointelegraph, a developer posted on GitHub on Thursday indicating that a newly disclosed software vulnerability in the Bitcoin staking protocol Babylon could allow malicious validators to disrupt parts of the network’s consensus process, potentially slowing down block production during critical periods.
This vulnerability affects Babylon’s block signature scheme, namely the BLS voting extension scheme, which is used to prove that validators have reached consensus on a particular block. The flaw allows malicious validators to intentionally omit the block hash field when sending vote extensions, which could lead to validator consensus issues during network epoch boundaries. The block hash field informs validators about which blocks they are actually voting for during the consensus process, and this vulnerability permits omitting this field.
Theoretically, through this vulnerability, malicious validators could cause other validators to crash during key consensus checks at stage boundaries. If multiple validators are affected, it could slow down block generation. There are no reports yet of this vulnerability being actively exploited, but developers warn that if not addressed, it could be abused.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Vulnerabilities found in Babylon staking code may slow down block generation speed
CoinVoice has learned that, according to a report by Cointelegraph, a developer posted on GitHub on Thursday indicating that a newly disclosed software vulnerability in the Bitcoin staking protocol Babylon could allow malicious validators to disrupt parts of the network’s consensus process, potentially slowing down block production during critical periods.
This vulnerability affects Babylon’s block signature scheme, namely the BLS voting extension scheme, which is used to prove that validators have reached consensus on a particular block. The flaw allows malicious validators to intentionally omit the block hash field when sending vote extensions, which could lead to validator consensus issues during network epoch boundaries. The block hash field informs validators about which blocks they are actually voting for during the consensus process, and this vulnerability permits omitting this field.
Theoretically, through this vulnerability, malicious validators could cause other validators to crash during key consensus checks at stage boundaries. If multiple validators are affected, it could slow down block generation. There are no reports yet of this vulnerability being actively exploited, but developers warn that if not addressed, it could be abused.