CometBFT's default for `BlockParams.MaxBytes` consensus parameter may increase block times and affect consensus participation
Date: 2023-09
Affected: go/github.com/cometbft/cometbft, go/github.com/cometbft/cometbft, go/github.com/cometbft/cometbft
Attack vector: other
Category: vulnerability-disclosure
Severity: Low

## Amulet Security Advisory for CometBFT: ASA-2023-002 **Component**: CometBFT **Criticality:** Low **Affected versions:** All **Affected users:** Validators, Chain Builders + Maintainers # Summary A default configuration in CometBFT has been found to be large for common use cases, and may affect block times and consensus participation when fully utilized by chain participants. It is advised that chains consider their specific needs for their use case when setting the `BlockParams.MaxBytes` consensus parameter. Chains are encouraged to evaluate the impact of having proposed blocks with the maximum allowed block size, especially on bandwidth usage and block latency. Additionally, the `timeout_propose` parameter should be computed using the maximum allowed block size as a reference. This issue does not represent an actively exploitable vulnerability that would result in a direct loss of funds, however it may have a slight impact on block latency depending on a network’s topography. When setting a large `BlockParams.MaxBytes`, there are two main implications: * Increased bandwidth to propagate a block * Increased latency to propagate a block When combined, this may result in less round participation, and in some cases additional rounds may be required to meet the consensus threshold, which could lead to timeouts depending on the topography of a network and environmental factors. These factors can include the number of validators on a network, geographic distribution, networ


Mitigations:

Architectural layers (MAESTRO):