SIMD-0101: Halve Rent

[brooksprumo]

Proposal to halve the cost of rent.

Rendered proposal

[jarry-xiao]

Is a potential drawback of decreasing "rent" (I'll refer to it as storage cost) that it becomes potentially dangerous to increase again in the future? I imagine there are checks in the runtime ensuring that an account's lamport balance is always higher than the required threshold or else it gets garbage collected. The nice part of lowering this value is that the threshold requirements for legacy accounts will still be satisfied.

In the case where this feature flag is activated, is it true that accounts created during this low rent regime could potentially be at risk of garbage collection if the storage cost parameter were to increase in the future?

[brooksprumo]

That's a good callout.

With the Solana Labs code and feature gates as of today, if an account was created with the minimum balance for low rent, and then rent was increased, yes, this account would then begin paying rent as part of rent collection.

Note that the account doesn't immediately get garbage collected. In the example above, if rent were doubled, then the account would have ~1 year before rent collection fully drained the account and caused it to be garbage collected.

Also, I realize that I have made a few assumptions:

1. We won't increase rent. This manifests in the extremely small amount that this SIMD decreases rent. By halving, we basically treat the rent calculations as if 1 SOL == 2 USD. So there's a very large buffer from where SOL is today.

2. Rent collection, the mechanism, will be turned off (see SIMD-0084: Disable rent fees collection #84). So then if we need to raise rent, it won't cause any existing accounts to suddenly start paying rent; they'd just need to top up their balance to meet the new minimum if they wanted to transact with that account.

[cavemanloverboy]

perhaps this idea can be developed in conjunction with account compression. Similar to your proposal: upon some grace period after a potential rent increase, an account with an insufficient deposit is compressed; instead of needing to top up their balance after 1 year they must decompress the account.

[brooksprumo]

perhaps this idea can be developed in conjunction with account compression.

Yep! That's the longer-term project I was referring to.

[mertimus]

they might not be directly impacted by the literal change but they will pay for it with increased reqs and I'm not sure that's trivial — gPA calls would get even worse

[diman-io]

How feasible is it to reprogram this so that it's possible to change this parameter on the fly, without new feature gates? What I mean is that to change this parameter again, it wouldn't be necessary to introduce a new feature gate, but simply to make a decision through voting.
In the near future, each feature gate will need to be coordinated among several clients, which will prolong the process. As a validator, I would prefer to have less dependency on client developers in such matters.

[brooksprumo]

How feasible is it to reprogram this so that it's possible to change this parameter on the fly, without new feature gates?

With the current feature-gate system, I don't know how that could work. I agree it would be better to not require new feature-gates for every rent change. Hopefully there are not many changes though, and instead the longer-term project to handle state economics is in place instead.

Until there, there's work to make an on-chain program that'll handle feature-gate activations. This ensure that feature-gates are activated at the same time/slot/epoch across multiple validator clients. Maybe that can incorporate a way to handle this use-case.

[zpalmtree]

And the network should not cater to lower-spec'd validators.

I don't know if I agree with this, the hardware costs for a minimum spec solana validator are already very high. Don't we want to make it easier for users who are not well capitalized to setup a validator and attract stake? There has to be some balance between hardware costs and performance imo.

So many of the validators I see on solanabeach are huge entities already :(

[t-nelson]

concept nack.

chasing number is not economics.

a more valuable thing should cost more. did we actually make state cheaper somehow or are we going to see a "double rent" when number go back down?

[ripatel-fd]

I oppose this proposal (at least until there is more data) because I believe it is likely to worsen stability of the network.

Virtually all Solana Labs validators are running with >=512GB RAM nodes. Many RPC providers are upgrading to 1024GB nodes due to recent increases in memory requirements. Even the current positive growth is not sustainable. Adopting this proposal will accelerate such growth, as users can allocate twice the amount of space for the same amount of tokens.

RAM is expensive. If those validators cannot afford to upgrade anymore, or cannot acquire hardware fast enough to respond to increased state size, they will run out of memory and crash.

Solana Labs' account database has better NVMe support in recent releases. But NVMe bandwidth is low, and bandwidth is roughly proportional to state size. (If, for example, programs allocate accounts twice the size).

Tangentially related: At extremely high bandwidth requirements, a system with a ton of RAM is cheaper than an array of NVMes due to PCIe bandwidth limitations. Firedancer currently optimizes or maximum transactions per second, therefore has a memory-only database. We're assuming that state growth will eventually become sustainable for in-memory operation, e.g. via segmentation of state into "hot" (RAM) and "cold" (NVMe) regions, and will eventually file a SIMD for such a design.

I think the community should consider this proposal for acceptance only if there are statistics to prove that it is safe to implement:

• How many Solana Labs validators are running with the new disk offload feature?
• What is the current state growth rate? If doubled, how much memory will the Solana Labs validator consume after one year of account allocations at 2x growth rate? (Such could be simulated by forking mainnet into a simulated network, spamming account allocations, and decreasing ticks-per-slot to fast forward)
• What is the current NVMe data rate? If doubled, will it be within reasonable bounds of what the hardware is capable of?

Safety concerns aside, I'm not sure if this is a practical route to go. This change seems to be motivated by a recent change in USD price of rent. (Which has more than doubled over recent months). But if the price decreases/increases drastically again in the future, we will be forced to do another hard fork.

If we establish that the rent price has to change, I'd suggest a dynamic pricing mechanism instead that takes validator feedback into account, as validators are ultimately paying the real world cost of storage.

Lastly, I'd consider the high price of rent an opportunity to fix some inefficient contracts by shrinking accounts. E.g. the "SNS" protocol, which caused users to allocate 2-10kB accounts that are entirely empty.

[bji]

What kind of historical data can we gather to give some insight into the decision factors that would go into deciding what the "correct" minimum balance factor should be? I think I'd like to see some effort to justify a number based on arguments rooted in some kind of data analysis instead of just what feels like an arbitrary "halving" of minimum balances.

I can think of a few ideas off the top of my head, all analyzed as historical trends:

• Account creation rate
  • In number of accounts
  • In bytes of new accounts (the size that accounts are initially created at)
  • In bytes of reallocated accounts (i.e. where accounts eventually "end up" in size)
  • Per program, in as much as this data can be assessed
• Account destruction rate
• Account "abandonment" rate in as much as this can be assessed
• SOL spent on account creation relative to the USDC value of SOL (i.e. do higher prices seem to dampen account creation rate?)
• Account creation rate per TX (to inform prediction of future account creation rate according to growth in end user tx rate)

Other ideas very welcome.

[bji]

Also, I think this SIMD needs to address how "grandfathering" will work. Will already-existing accounts be allowed to withdraw down to the new minimum balance? Or are they grandfathered in, having agreed to a minimum balance at the time they were created, effectively creating a "contract" between themselves and the network that shouldn't be violated later.

[michaelh-laine]

1. I don't believe there is sufficient articulation of the need in this proposal. "Developers are having a tough time" is neither empirical nor substantiated by sources
2. 50% reduction is arbitrary and not supported by specific research why that would be the appropriate value
3. Economic decisions must be subject to governance so I also oppose this out of that principle. A post on the governance forum would be the best place to start this discussion if this proposal is intended to be pursued.

[CalvinMaighan]

1. I don't believe there is sufficient articulation of the need in this proposal. "Developers are having a tough time" is neither empirical nor substantiated by sources
2. 50% reduction is arbitrary and not supported by specific research why that would be the appropriate value
3. Economic decisions must be subject to governance so I also oppose this out of that principle. A post on the governance forum would be the best place to start this discussion if this proposal is intended to be pursued.

As a dApp builder on Solana, I can share a case study for where the need comes from.

I'm the CVO at Ladder Labs. Our products are laddercaster.com (fully on-chain game on Solana) and buddy.link (fully on-chain referrals, domains, and engagement tooling on Solana).

We've re-written both programs from the ground up 4 times each now since 2022. We use all of the latest techniques (besides compression which may help with Buddy v5) and work closely with many other teams on Solana to overcome the current cold-start problem our beloved chain suffers from today.

Our BuddyLink protocol satisfies every constraint for multi-level, multi-attribution, unique usernames, and is used by projects like Star Atlas, who has recently passed $14M in on-chain volume from just over 5,500 referred buddies alone since september 2023. They've paid affiliates $1.5M+ in on-chain rewards, and since integrating with us in a composable way using CPI calls, their revenue has seen a 10x increase.

Since we've integrated them, rent prices have skyrocketed, and are now sitting around $2 per user link. This includes token accounts for SOL, USDC, and usually a third one like ATLAS for the project. Each link created for a new organization or project costs ~$0.30 after initial account setup, which is a little better, but the initial cost has made it impossible for projects like Genopets with its 300k+ users to integrate, as they pay for all of their users' gas to make the experience as smooth as possible, and compliant with the iOS and Android app stores.

Perhaps we could collect other case studies from projects across the ecosystem and measure how much rent costs are impacting our ability to onboard real users to Solana this cycle.

When we price our nano-fees in Laddercaster, we use Pyth with a decentralized crank to peg the SOL fees to $0.01 or $0.001 in some cases. That way fees don't get out of control the way they do with Metaplex NFTs and Solana rent fees which are impacting app builders, and users.