Modify other constants based on decreased block time #3959
Comments
Mempool TTL duration// TTLDuration, if non-zero, defines the maximum amount of time a transaction
// can exist for in the mempool.
//
// Note, if TTLNumBlocks is also defined, a transaction will be removed if it
// has existed in the mempool at least TTLNumBlocks number of blocks or if it's
// insertion time into the mempool is beyond TTLDuration.
TTLDuration time.Duration `mapstructure:"ttl-duration"`
// TTLNumBlocks, if non-zero, defines the maximum number of blocks a transaction
// can exist for in the mempool.
//
// Note, if TTLDuration is also defined, a transaction will be removed if it
// has existed in the mempool at least TTLNumBlocks number of blocks or if
// it's insertion time into the mempool is beyond TTLDuration.
TTLNumBlocks int64 `mapstructure:"ttl-num-blocks"`Currently this config is local per validator. These values are the defaults: ttl-duration = "1m15s"
ttl-num-blocks = 5 Since block time is decreasing from 12 seconds to 6 seconds, the earliest something will be pruned from mempool is 5 * 6 seconds = 30 seconds. We may consider increasing ttl-num-blocks from 5 to 12 so that ttl-duration and ttl-num-blocks roughly matches. Proposal[in v3] update the default ttl-num-blocks to 12. Evidence MaxAgeNumBlocks120960 blocks * 12 seconds per block = 1451520 seconds = 16.8 days we don't need to modify this parameter because evidence is only considered expired after 21 days and 120960 blocks (see here). Since 21 days remains intact, evidence won't be pruned prematurely. Proposal[not blocking v3] make the evidence params non governance modifiable and hard-code them to matching values ~21 days. See https://github.com/celestiaorg/CIPs/blob/main/cips/cip-16.md x/ibc MaxExpectedTimePerBlock// Params defines the set of Connection parameters.
type Params struct {
// maximum expected time per block (in nanoseconds), used to enforce block delay. This parameter should reflect the
// largest amount of time that the chain might reasonably take to produce the next block under normal operating
// conditions. A safe choice is 3-5x the expected time per block.
MaxExpectedTimePerBlock uint64 `protobuf:"varint,1,opt,name=max_expected_time_per_block,json=maxExpectedTimePerBlock,proto3" json:"max_expected_time_per_block,omitempty" yaml:"max_expected_time_per_block"`
}Currently our The parameter was added in cosmos/ibc-go#171. Related to cosmos/ibc#552. Reached out to IBC team about it. Update: the IBC team informed us that the parameter is rarely used. On Mainnet Beta, all connections have a delay period of 0 which means the feature isn't used. ProposalSince the delay period feature isn't used on any active IBC connections on Mainnet Beta, I recommend we don't modify |
Motivation in the **Mempool TTL duration** section of #3959 (comment) ## Description Modify the default consensus node config for mempools so that: - TTLNumBlocks from 5 to 12 because 12 six second blocks = 72 seconds which is comparable to the existing 75 second TTLDuration. - ~~MaxTxBytes from approx 7.5 MiB to 8 MiB because it's easier to understand and communicate~~ - ~~MaxTxsBytes from approx 37.6 MiB to 40 MiB because it's easier to understand and communicate~~ ## Testing `make install && ./scripts/single-node.sh` then cat the config ```toml version = "v1" ttl-duration = "1m15s" ttl-num-blocks = 12 ```
Context
Originally posted by @jcstein in #3953 (comment)
Problem
The constant
GoalBlockTimeis used:#3882 proposes decreasing block times from 12 to 6 seconds.
Proposal
Re-evaluate if those constants need to be modified if we decrease block time from 12 to 6 seconds.
The text was updated successfully, but these errors were encountered: