Celestia currently has hardcoded limits to the block size (in bytes) and square size (in shares). These guardrails are in place to prevent on chain governance from picking a limit that exceeds the capacity of the network. However, in performance based testing we want to continually explore and improve that limit. In the past we have used feature branches where we have modified that limit to run our tests but these cause other complications.
Proposal
Look into using build tags which would allow us to define those limits at compile time.
Using the same technique we could also inject values for the limits. The defaults can remain untouched but in certain cases of testing we can set these bounds when building the binary or the docker image
Summary
Celestia currently has hardcoded limits to the block size (in bytes) and square size (in shares). These guardrails are in place to prevent on chain governance from picking a limit that exceeds the capacity of the network. However, in performance based testing we want to continually explore and improve that limit. In the past we have used feature branches where we have modified that limit to run our tests but these cause other complications.
Proposal
Look into using build tags which would allow us to define those limits at compile time.
celestia-corealready uses build tags for injecting the commit hash. See https://github.com/celestiaorg/celestia-core/blob/ff2bff4a29aec6851499e34b7d84349d8e774dd9/Makefile#L8Using the same technique we could also inject values for the limits. The defaults can remain untouched but in certain cases of testing we can set these bounds when building the binary or the docker image