Should we consider disabling rent auto-bump for now?

[mossy spear]

Reposting as this question was eaten within a different thread.

I have been thinking about which values we should pick for auto bump: how many ledgers to bump, and what should be the limit.

Then I realized that entries are probably going to follow a power low of sorts (because: humans), where most entries on ledger are not going to be very active.

So either we optimize for the many not very active entries:

• autobump should be very aggressive, like bump in 3-6 months increments
• but this increase cost for everybody else by default as it increases the minimum time any entry will be on ledger (therefore increasing its size) even though some entries can probably be migrated to the ESS earlier than that
• it also increases the burden on popular contracts (maybe not as bad?) that have a "warm up" period for new entries, where interactions are much more expensive than needed

Or we optimize for the few very active entries (I think more in line with what we discussed so far):

• autobump bumps by a small number like 64 ledgers
• the autobump limit is also lower, like 1 month
• but in this case, most contracts/wallets have to be written assuming that many entries need to be manually be bumped. Autobump (that does its thing when testing) acts more like a footgun as it gives the impression to contract devs that everything is fine.

In all situations, it also increase cost of wasted rent, as rent is paid even when not needed (up to the limit).

There is a potential additional problem (more like an unknown) that depending on the frequency of autobumps (which is a function of amount and refresh treshold if we decide to add one), the amount of "write churn" in the bucket list increases with "reads" in addition to "writes". With contract data keys in the order of potentially hundreds of bytes, this can add up quickly in terms of overhead.

In short, it's very hard to find a "one size fits all" policy for autobump.

So I am proposing instead to:

• disable autobump when testing contracts -- maybe even consider adding test utilities/infra that allow people to simulate "time passes" so that entries reach their eviction date (therefore allowing people to find issues related to lack of bump). This is probably useful for testing temporary entries.
• disable autobump (autobump by 0 in settings) for launch
  • Contracts and apps will be forced to be written as to not rely on specific autobump numbers (and also force us to provide the right tools for the job)
  • only enable autobump when we have a good understanding of its impact
    • it's possible that we'll find out that a better version of autobump would be to track utilization per entry or something like that
    • it's also possible that we won't need it at all at the protocol layer, and instead iterate on better tooling at the SDK/host function layer

Also, as a bonus, by pushing this to the client, we are very likely to reduce the amount of writes to the bucket list caused by bumps as:

• autobump is "worst case" (as it bumps on every read)
• some apps will likely just bump once every few months (like wallets)
• some dapp developpers will take the responsibility of bumping "infra" (wasm, global state) as to avoid having end users carry on the burden

@naive jolt @sharp verge @empty halo

[empty halo]

I've been advocating for large autobumps previously and still am in favor of that (though no autobumps might be ok-ish as well as everyone will be forced to define 'autobumps' manually).
I don't feel like contract writers would come up with something significantly different. if the entry is not temporary, then it's probably intended to live in ledger for a while and likely only expire when truly abandoned. so it seems like the most straightforward strategy is to fund any new entries with weeks-months of rent. that's especially true for the contract/wasm entries (btw we'd probably need to provide a way to bump these programmaticaly as well, which is a bit annoyng). so I feel like it's expected that entries would cost more initially.
as for periodic bumps, they aren't that different. if the entry is used frequently, then everyone would pay a small amount. if it's used rarely, someone would need to pay more, but chances are this is a per-address entry anyway

[sharp verge]

The autoBump setting can be upgraded without a protocol change, so I'm fine either way. From the users perspective though, having some sort of autobump should reduce friction at launch when there won't be established tools and processes for bumping (and if we're wrong, we can just set it to 0 later).

[naive jolt]

Those tools and processes may not form if we launch with autobumps. So I think we should lean into the inconvenience given that enabling it is so easy a thing to do later.

I believe we discussed that the storage interface would allow contract developers to bump via code in the contract. Would that still be implemented or work, or was that how the auto bumps were going to be calculated? Should we leave that out of the SDK API?

[empty halo]

the state expiration PR already has bump function

[naive jolt]

Could you remind me, what does it do? Does it cause the bump to happen, or set what the auto bump amount will be?

I believe the latter.

If so, will it become a noop now? We should probably at least hide the function in the SDK docs, if not leave it out.

[empty halo]

no, it's nothing to do with autobump. it defines by how much the entry should be bumped

(unless I'm missing some implementation piece ,that is. @sharp verge would probably know better)

[sharp verge]

Yeah the bump_contract_data host function will allow contracts to bump the expiration ledger.