Measure the transactions. Measure the encoded proposal. Check the epoch boundary. Repeat, because those totals were not guaranteed to match.
I first read Babylon v4.3.1 as a narrow accounting patch. Looking closer, I think it closes an operator-level failure path at the exact moment checkpoint data enters a block proposal.
Before the fix, Babylon’s checkpoint repack budgeted transactions by raw byte length, while CometBFT validated the larger protobuf-encoded proposal. A block could pass the first calculation, fail the second, and crash the proposer at an epoch boundary.
v4.3.1 makes PrepareProposal count the same encoded size that CometBFT enforces. It also adds a final guard that removes trailing non-checkpoint transactions until the proposal validates, keeping the checkpoint while preventing an oversized block from being returned.
The patched chain was tested at real bbn-1 limits with four validators through about ten checkpoint boundaries under transaction-flood conditions, with no proposer crashes.
For an operator, this removes a mismatch the node should never have exported as operational risk. The block builder now has one definition of “fits,” not one estimate before encoding and another after submission.
Babylon’s operator work is often discussed through keys, uptime and BLS duties. None of those matter if checkpoint insertion can stop block production.
This release makes that boundary behave like part of the protocol, not a recurring capacity gamble for the proposer.
@BabylonLabs_io $BABY #baby
I first read Babylon v4.3.1 as a narrow accounting patch. Looking closer, I think it closes an operator-level failure path at the exact moment checkpoint data enters a block proposal.
Before the fix, Babylon’s checkpoint repack budgeted transactions by raw byte length, while CometBFT validated the larger protobuf-encoded proposal. A block could pass the first calculation, fail the second, and crash the proposer at an epoch boundary.
v4.3.1 makes PrepareProposal count the same encoded size that CometBFT enforces. It also adds a final guard that removes trailing non-checkpoint transactions until the proposal validates, keeping the checkpoint while preventing an oversized block from being returned.
The patched chain was tested at real bbn-1 limits with four validators through about ten checkpoint boundaries under transaction-flood conditions, with no proposer crashes.
For an operator, this removes a mismatch the node should never have exported as operational risk. The block builder now has one definition of “fits,” not one estimate before encoding and another after submission.
Babylon’s operator work is often discussed through keys, uptime and BLS duties. None of those matter if checkpoint insertion can stop block production.
This release makes that boundary behave like part of the protocol, not a recurring capacity gamble for the proposer.
@BabylonLabs_io $BABY #baby