Rent Reduction

[igor56D]

What is the fastest, safest, and most effective solution to Solana's high state allocation costs? That's the question this discussion will be focused on.

First, I want to address the status of the current Dynamic Rent and Compression SIMDs. These were intended to solve a broader category of state related problems, including but not limited to the high rent price. Considering the complexity of and controversy surrounding these proposals, a solution focused more specifically on rent reduction will likely be faster and safer to ship.

Non-disruptive rent increase

Before discussing specific solutions, a prerequisite to satisfy the safety requirement is allowing non-disruptive rent increases. Because it's impossible to know exactly what the state demand curve will be ahead of time (or how that demand curve may change), there needs to be an option to increase rent if excessive state growth occurs, without causing significant disruption to the network or the users.

There are two current proposals addressing this:

1. Track the min_balance value at the time of an account's creation in the account metadata. Post-execution balance checks use this value instead of the global constant.
   • The downside is that this requires modifying the account structure -- non-trivial but not necessarily disqualifying.
2. Relax post-execution balance checks (SIMD-0392): that transaction fails if an account has a balance less than both the global constant and the pre-execution balance. If the account was created or reallocated in the transaction, only the global constant is used in the check.
   • This is slightly more game-able than (1) because it allows accounts to always drop their balances when the rent is lowered.

Recovery mechanism

With a solution in place for rent increases, the next problem is when and how to increase rent.

1. Manual intervention: the constant is manually increased (likely through a feature gate that was prepared ahead of time) if excessive state growth is observed by core devs.
2. Supervisory controller SIMD-0389: an integral control is engaged when a threshold growth rate is exceeded. The controller increases the min_balance requirement for new accounts until growth drops back below the threshold.

Both of these proposals include a 10x reduction in the min_balance requirement; they differ only in how they detect and respond to excessive state growth. There are many different ways to implement and configure the controller but the core form is very simple:

// called at the beginning of each slot
// bank.acc is the integral accumulator responsible for tracking how far growth is from the threshold
def update_rent(bank)
   bank.acc = bank.parent.acc
   bank.acc += (bank.parent.state_growth - STATE_GROWTH_THRESHOLD)
   bank.acc = clamp(bank.acc, ACC_MIN, ACC_MAX)
   bank.rent = clamp(bank.parent.rent * f(bank.acc), RENT_MIN, RENT_MAX)

f(x) can be any non-decreasing function, but should be selected such that it provides reasonable updates within the given accumulator range. The output is interpreted as the percentage change from the parent rent to the new rent. For example, if f(x) = 10^-10 x + 1 then f(-1B) = 0.9, f(0) = 1, f(+1B) = 1.1. In this case, the percent change increases linearly from -10% to +10% in this range.

A benefit of the controller approach is that it exposes much more tangible knobs than the status quo:

• STATE_GROWTH_THRESHOLD: the safe growth threshold that, when exceeded, activates the controller. As the client implementations are optimized this value can be increased, allowing for more rent reduction.
• ACC_MIN, ACC_MAX: accumulator bounds. abs(ACC_MIN) can be intuitively understood as the maximum amount of "slack" allowed. For example, if ACC_MIN = -1B then there can be up to 1GB of above target state growth before the controller is engaged. ACC_MAX on the other hand can be interpreted as the maximum growth "debt" that must be repaid with below target growth before rent prices can be reduced again.
• RENT_MIN, RENT_MAX: bounds on the minimum balance requirement for new account allocations. The bank.rent value will converge towards RENT_MIN during normal conditions and grow up to RENT_MAX when the growth threshold is exceeded. This allows for future safe rent reductions by dropping the RENT_MIN value.
• f(x): the update function can be modified in various ways, e.g. more aggressive rent increases when the threshold is exceeded.

Being the one who submitted SIMD-0389, it's probably no surprise that the supervisory controller is my preferred approach, but please respond with any criticisms, alternatives, etc. that come to mind.

[Tamgros]

It's not completely clear to me if STATE_GROWTH_THRESHOLD is a rate of growth or an absolute amount of state. I think both are relevant, so I think any rent changes should take both into account

Said in english, if the amount of state isn't close to being an issue, the growth rate of state in a given epoch isn't as concerning as if the amount of state is already high.

[igor56D]

Only the rate of state growth is being considered by the controller. If the total state size was also a direct factor, we'd either need compression to begin evicting state when a threshold is exceeded or risk persistently elevated rent prices, even at reasonable growth rates. There's no effective way to apply back pressure on total state without eviction.

In any case, limiting the state growth rate indirectly limits the total state size at different points in the future: total_size(t epochs) <= threshold_state_growth * t. While not ideal, this predictability should be sufficient, and no other proposal (besides compression) fully solves this anyway.

[deanmlittle]

Considering the complexity of and controversy surrounding these proposals, a solution focused more specifically on rent reduction will likely be faster and safer to ship.

I agree, if the goal is to safely reduce the price of rent, the most ridiculous, unproductive thing we could do is write a bunch of papers and host lengthy discussions about mechanism design to prevent problems that don't exist.

If the goal is to take practical steps to decrease rent by an amount unanimously deemed safe by our stakeholders today with the aspiration to do even better in the future, my extensive market research on the topic (see below) shows that the threshold should be something like 2x reduction, 5x reduction followed by 10x reduction, starting from a 2x reduction today, with the remaining reductions TBD pending further validation on real software and hardware.

We currently charge orders of magnitude more than the procurement cost of high-performance NVMes we consume data from by pretending it's stored in RAM. Given that, I think it is very silly to focus on how we can increase rent after a mere 10x reduction. We should be putting in the work to answer the following questions instead:

1. Will AccountsDB hold up?
2. Do RPC/infra providers care about this problem? (I asked, they do not, and compression is an even less palatable idea to them)
3. Is it economically palatable to reduce a sizable token sink? (If we are to remain true to our REV-maxxing ethos, putting lamports into the hands of validators through transaction fees is considered more bullish than locking them up in a state bond)

A benefit of the controller approach is that it exposes much more tangible knobs than the status quo:

It is absolutely comical to me that the first thing any of these proposals do to remove the need for our heretical "magic numbers" is to say: "Here's a state growth constant."

If we want to design Rube Goldberg machines and write cool whitepapers, I recommend the following as a more rational starting point:

1. Make a convincing argument to validators and major infra providers that state growth is a problem.
2. Make a convincing argument for what STATE_GROWTH_THRESHOLD should be; something I doubt you'll get any agreement on if you try to go with something objective like the physical limitations of hardware. (It's boring, conservative constants all the way down whether you like it or not.)
3. Cherry pick the most advantageous data you can from when Solana was at $125 vs $250 and plug it into the price elasticity of demand formula. (While imperfect, this is currently the best analog we have to "what would happen if we just halved rent today?" You'll likely find many situations where demand is inelastic to price, and perhaps even inversely correlated.)

If a convincing argument cannot be made that state growth is a real problem and what the "correct" amount of state growth should be, and we are unable to demonstrate high elasticity to price, no mechanistic price controller we could contrive will actually be palatable, relevant or useful.

Just halve the rent. Do it today. Nobody will disagree. Then we look at what we need to do to safely reduce it further. Mechanism design is the wrong focus.

[deanmlittle]

You’re right that “commandeering” this “discussion” is a waste of my time. I have many positions about how you’re wasting yours. Here's my top 10:

1. State growth is positively correlated with SOL price, violating the basic premise of using rent pricing as a disincentive in the first place.
2. Raising rent, for any reason, is a bad idea – It means we didn’t do our homework when lowering it in the first place. We are already many orders of magnitude above our cost basis as is. It is a skill issue at this point.
3. Dynamic rent is a bad idea – It destroys devex, and those of us who’ve been around more than 6 months still get flashbacks from the “good old days.”
4. State growth is not a real problem we're on the cusp of experiencing, and nobody at Anza or among infra providers (read: the ones footing the AWS bill) believes otherwise.
5. Nobody insisting state growth is a real problem can articulate, let alone justify how much state growth is a problem and why.
6. Suggesting that conservative adjustments to our existing constant provides insufficient protection that can only be solved by adding yet another, far more dubious constant with extra steps that destroy devex is a ridiculous non-starter, as anyone who’s ever interacted with people who actually use the chain outside of vesting day would know.
7. Punishing those who showed up late does nothing to disincentivize those who showed up early and caused the "problem".
8. Solana has already seen >2x current state growth during congestion with nothing bad happening. Everyone agrees we could safely halve rent today without needing a plan to double it again later. It’s a tangible fix to a major pain point with no downsides. Not prioritizing this over mechanism design is, quite frankly, extremely suspect.
9. Every relevant core dev suspects a 10x reduction would be just as safe as 2x, but the conservative view is that it’ll take ~2 dev cycles to validate AccountsDB stability under sustained 10x increase in use, which is itself an extremely conservative take on demand elasticity.
10. A second data point post–rent reduction from a simple halving would help to inform future pricing decisions and either vindicate or silence the idea that “rent is only inelastic to price because it's a hidden cost”.

[igor56D]

1. This violates nothing. You're simply touching on the basic observation that the demand curve for state is not fixed (consider BTC and SOL price correlation if this doesn't make sense). I've mentioned this several times as being one of the main reasons we can't predict what will happen after a significant reduction in rent.
2. Your phrasing here is bizarre. The bad idea isn't the increase in rent but the reduction in rent that made the increase necessary in the first place. The state growth threshold parameter gives us an out if it turns out we didn't do a good enough job on the homework.
3. As I already said:

if you're correct that a 10x rent reduction is safe (everyone thinks this is the most likely case btw), the result of the controller approach will be equivalent to a straightforward reduction. The controller is only engaged if the safety growth threshold is exceeded, hence the "supervisory" designation.

4. Already addressed:

Read the original post again. The correct question is, will state growth be a problem if rent is reduced? Answer: we don't know. Therefore, we must reserve the option to increase the rent after it's been decreased.

5. No one can know the exact maximum state growth the network in its current form can handle. We can come up with a conservative lower bound though: say 1-2GB per epoch.
6. Unsubstantiated assertions. How is the constant more dubious? How does this "destroy devex"? You've made no convincing argument for any of this.
7. Are you suggesting that the rent increase will happen too late to respond to an excessive state growth event? If so, explain why. This is something that was considered in the design of the controller.
8. We're targeting a 10x reduction. 2x is insufficient.
9. Explain why this is safer and faster to ship than the alternatives. I don't even disagree with your points; they just support the controller approach as well. The "extremely conservative take on demand elasticity" (10x increase in growth) is what informs the controller's state growth threshold parameter. This is exactly why this constant isn't arbitrary or "dubious" like you say! If we're right and this level of growth isn't exceeded, the controller is never engaged and the rent stays constant. If we're wrong then your proposal is objectively worse. End result is that the controller approach is strictly better in expectation.
10. This data may be useful to a limited degree but it's far from conclusive or authoritative. Rather than blindly tiptoeing into the unknown to test the boundaries, we should put safety measures in place so we can confidently reduce rent more aggressively.

[deanmlittle]

All available data indicates that demand for rent as denominated in USD is, at best, inelastic and, at worst, positively elastic to price. Setting a price floor on an inelastic good as a means of curtailing demand is an economically illiterate idea that doesn’t work.

A price floor that retrospectively punishes non-offending users because some guy uploaded a bunch of JPEGs two days ago is, unequivocally, the dumbest and most unproductive form of this economic illiteracy.

Even if demand for rent were negatively correlated with price – the obvious precondition for such a mechanism to be effective in the first place – no rational validator would choose this mechanism over simply scaling up storage, because storage is extremely cheap, our markup is currently many orders of magnitude above our cost basis, and the alternative could only ever feasibly result in a reduction to their bottom line during times of high fee revenue.

Solana is not Ethereum. It is a REV chain; a system designed to scale at the base layer. Any artificial friction that reduces the flow of lamports from users to validators for doing meaningful work is both anti-scaling and anti-REV. The solution is always to test the limits of the system and make conservative improvements as quickly as possible to scale supply so that validators can do more meaningful work and earn more revenue – not to pontificate on the dubious economics of how we might artificially kneecap demand.

I can only present this to you so many times in so many ways. At some point, it is up to you to recognize that developers – your end customers as a core developer – will not find the added complexity of dynamic rent pricing a palatable change, and validators, the people who will bear the costs of your ideas and are already struggling for revenue with the current downturn, would be irrational to support a mechanism that causes lamports to flow anywhere other than into their own pockets.

[igor56D]

All available data indicates that demand for rent as denominated in USD is, at best, inelastic and, at worst, positively elastic to price. Setting a price floor on an inelastic good as a means of curtailing demand is an economically illiterate idea that doesn’t work.

Ok, I'll spell it out for you since you're clearly not grasping my response to (1). Market conditions that cause a rightward shift in the demand curve for SOL typically also cause a rightward shift in demand for state. There is a correlation between demand for these two different goods, much like for BTC and SOL. Does it make any sense to say that demand for BTC "is, at best, inelastic and, at worst, positively elastic to price"? No, of course not. The change in market conditions simply cause a new equilibrium to form. If there's one thing we can say with complete certainty it's that increasing the rent will not increase state growth ("positively elastic"). I don't know how you can suggest something like that while making accusations of economic illiteracy.

Suggesting that demand for state and rent price are completely causally unrelated is only slightly less ridiculous. The whole reason we want to reduce rent is because people want to create more accounts! So, it would stand to reason that more accounts will be created when rent is reduced... again, this should really go without saying. It's a moot point anyway, because if there somehow turns out to be 0% elasticity, the controller will never be engaged.

A price floor that retrospectively punishes non-offending users because some guy uploaded a bunch of JPEGs two days ago is, unequivocally, the dumbest and most unproductive form of this economic illiteracy.

"retrospectively punishes"??? Are you saying it would take two days to increase rent? The controller's integral accumulator is updated every slot. Did you even read the proposal?

The REV stuff is similarly nonsensical.

I can only present this to you so many times in so many ways

From the very start, you demonstrated a total lack of interest in engaging in good faith. To make matters worse, you clearly made up your mind before even attempting to understand the proposal. It's impossible to have a productive discussion when you're uninformed, pre-occupied with hostile posturing, and ignoring every rebuttal.

I don't know what compelled you to adopt this attitude but I'm done interacting with you. Feel free to get in the last word.

[deanmlittle]

Market conditions that cause a rightward shift in the demand curve for SOL typically also cause a rightward shift in demand for state

You could've stopped typing here.

[t-nelson]

a prerequisite to satisfy the safety requirement is allowing non-disruptive rent increases

why is this a prerequisite? all of the solutions with this constraint are gameable. i don't see a reason not to discuss more intrusive options. the viable ones i see are

• grandfather reads. accounts marked for write must be rent-exempt in post-execution checks or tx fails
• writes treated as above. additionally reads fail pre-execution after account load if not rent-exempt

non-trivial but not necessarily disqualifying.

no. it's disqualifying. anything that requires touching every account is disqualifying

---

i'm generally in favor or making the minimum viable changes to the protocol under any circumstances. as i see it today those are

• figure out what to do with previously rent-exempt accounts when we raise rent (as above)
• actually make the change to reduce lamports_per_byte_year

we can save a controller for when the latter becomes tedious and/or we are actually confident in the mechanical performance of the underlying infrastructure. it is almost certainly the right thing to do, it almost certainly not the right time to do it

[igor56D]

why is this a prerequisite?

The wording I used could be better, I wasn't intending to completely rule out more intrusive options. All else being equal, the less disruptive the better, but there can certainly be other tradeoffs to weigh.

• grandfather reads. accounts marked for write must be rent-exempt in post-execution checks or tx fails
• writes treated as above. additionally reads fail pre-execution after account load if not rent-exempt

Both of these approaches would likely appear as a network outage from the perspective of users if rent were increased. DeFi, for example, would grind to a halt until someone funded the relevant accounts. This can have serious implications for time-sensitive things like liquidations. Wallets would need to be updated to consider the possibility of under-funded token accounts and surface this to users.

Overall, it sounds very painful. I don't see any benefits to either of these approaches that would make up for this drawback, but let me know if I'm missing something.

no. it's disqualifying. anything that requires touching every account is disqualifying

I mainly included that option for completeness. Personally, I'm strongly leaning towards the 0392 approach due to its simplicity. While I disagree that adding a new field to accounts would be disqualifying if account versioning was enabled, I'll just strike that option from the list to avoid muddying the waters.

we can save a controller for when the latter becomes tedious and/or we are actually confident in the mechanical performance of the underlying infrastructure. it is almost certainly the right thing to do, it almost certainly not the right time to do it

Can you elaborate on why you think it's not the right time to add the controller? Is it due to safety, time-to-ship, or efficacy? The way I see it, both approaches involve a 10x reduction in the rent price, the only difference is the controller approach has an additional safeguard built in that allows us to safely reduce rent more aggressively. This is why I emphasized the "supervisory" aspect of the controller: unlike an active controller, it's completely passive if growth remains under the safety threshold.

IMO the controller is quite simple, both conceptually and in terms of implementation (it's a few LoC). Including it shouldn't significantly increase the difficulty of shipping rent reduction. The safeguard allows us to go straight to 10x reduction rather than doing it incrementally, which I'd argue makes it both faster and safer.

[t-nelson]

Can you elaborate on why you think it's not the right time to add the controller? Is it due to safety, time-to-ship, or efficacy? The way I see it, both approaches involve a 10x reduction in the rent price, the only difference is the controller approach has an additional safeguard built in that allows us to safely reduce rent more aggressively. This is why I emphasized the "supervisory" aspect of the controller: unlike an active controller, it's completely passive if growth remains under the safety threshold.

i'm not sure how to justify putting a controller on infrastructure that we do not understand. there is a somewhat embarrassing amount of adhoc, intuitive, guess and check backing the storage implementation in agave today. go look at the code. the api is insane. insane api implies that usage patterns are ill-defined if known at all. unknown usage patterns imply that workloads are ill-defined or unknown. unknown workloads begs to question just how much "designing" can possibly be going on with the internals. this is a function of dubious goal setting from leadership and engineering unwilling to challenge said leadership. all improving today, but we're in the state we're in. regardless, i'd like to see the claims made that we understand this thing well enough to put a controller on it, but not so well as to provide an api.

further, the proposed controller only feeds back a parameter that is wholly irrelevant to scaling solana state. absolute state size won't be a problem until moore's law is cooked. it may become a minor inconvenience to bootstrapping new nodes from scratch, but that is orthogonal to this discussion and actively being addressed.

what anyone familiar with the current implementation is concerned about is the state population size (address count) and growth. this leans heavily on implementation details, not protocol rules. the current, sufficiently performant agave primary accounts index is purely in memory. while memory is expandable, it's not typically trivial as it depends on host inventory and physical access to hardware.
a first pass at falling back to disk proved insufficiently performant. new designs with better goals are being explored today.

until we have a firm foundation and alignment on what the problems actually are, i don't see how we can hope to design functional economics

IMO the controller is quite simple, both conceptually and in terms of implementation (it's a few LoC). Including it shouldn't significantly increase the difficulty of shipping rent reduction. The safeguard allows us to go straight to 10x reduction rather than doing it incrementally, which I'd argue makes it both faster and safer.

in my experience, not defending complexity here, but simple tends to point to either "irrelevant" or "ineffective". as above, i lean toward the latter in this caee. however, if the proposed controller is in fact so simple, the following should be presentable immediately

1. link to draft pr of implementation
2. metrics db link for a test cluster where [1] is deployed
3. link to a repo for test infrastructure exercising [2]
4. link to metrics db where testnet and mainnet dev nodes are pushing would-be controller outputs

these are about the minimum viable exploratory effort required to even start a serious public discussion imo

[igor56D]

i'm not sure how to justify putting a controller on infrastructure that we do not understand

I agree that determining the exact kind of state growth (or index growth) the client implementation can handle is a very difficult problem. It's similar in essence to the average/worst-case CU limit-as-proxy-for-replay-time issue because both the CU limit and the growth rate threshold represent a resource constraint that imperfectly maps onto the realities of validator software/hardware.

What makes things a lot easier here IMO is that the average state growth on mainnet now is 10x lower than a very conservative estimate of what the network can handle. From discussions with accountsdb engineers, 1-2GB per epoch should be no problem. The large gap between demand and capacity provides a lot more wiggle room.

The way I see it, we have to worry about resource usage one way or the other. Will the controller protect against every possible issue caused by a rent reduction? No, but the most likely issue of excessive state/index growth can be mitigated. If something goes wrong that isn't captured by the controller then a manual intervention will be needed, but this is the case for every alternative proposal too.

what anyone familiar with the current implementation is concerned about is the state population size (address count) and growth.

The controller is only concerned with the growth rate, not total state size. The overall growth rate indirectly captures the address count growth rate (bc each new account contributes 128 bytes to the accumulator), though a case can be made to shift the weighting more towards the latter. We can even have the controller target the index growth rate directly rather than the overall rate. The controller configuration is flexible enough to allow for different strategies so lmk if you have any ideas for improvements there.

1. link to draft pr of implementation
2. metrics db link for a test cluster where [1] is deployed
3. link to a repo for test infrastructure exercising [2]
4. link to metrics db where testnet and mainnet dev nodes are pushing would-be controller outputs

1. I already have a PoC implementation, but didn't expect anyone would want to review it until there was more alignment. I'll push it up and share the link.
2. I'll set this up. Is it intended to be a basic sanity check that things don't break or are you expecting to collect some specific data? I'm not sure what kind of workloads would be interesting besides just spamming the cluster with data allocations that cause the controller to engage.
3. 👍
4. This is doable, but I'm curious what you expect to get out of it. What does this give you that [2] doesn't?

I'll try to put this all together ASAP. Thanks for the feedback 🙏

[igor56D]

Pushed up the draft PR and requested a review from but re-sharing here in case anyone else is interested.

[jacobcreech]

In the current state, I do not understand why any of this is needed.

As a developer, I want the minimum viable safe solution possible that can solve developer pain without introducing additional complexity. I've heard multiple core engineers claim confidence that rent, specifically lamports_per_byte_year, could be decreased without disruption. Why do are we required to do any of this at this time?

If the confidence in a decrease being safe is high and it can help us learn what a decrease in rent would do to potentially modeling account address and state growth, why would we not go down that path?

Considering the complexity of and controversy surrounding these proposals, a solution focused more specifically on rent reduction will likely be faster and safer to ship

Perfect. Let's ship it.

[igor56D]

I'm assume your position is to just reduce the rent constant and call it a day. While I believe everyone agrees that the odds are in favor of nothing bad happening, I don't think anyone can make a strong case that those odds are higher than 99%. The top priority is to not take the cluster down, so reasonable safeguards are important. Of course, what exactly those safeguards should be is debatable.

How much state growth the cluster can handle is an engineering question. How state growth (or allocation patterns more broadly) will change as a result of a 10x reduction in rent is an economics question. There's simply no way we can answer this latter question besides taking educated guesses or going off of intuition. IMO this is too high stakes to play fast and loose with.

Perfect. Let's ship it.

In case it wasn't clear, I was specifically referring to the compression stuff in the section you quoted.

[jacobcreech]

How state growth (or allocation patterns more broadly) will change as a result of a 10x reduction in rent is an economics question. There's simply no way we can answer this latter question besides taking educated guesses or going off of intuition. IMO this is too high stakes to play fast and loose with.

We already have guardrails on how fast state growth can happen as per block limitations. This has already been mentioned in other conversations as a good warning sign that we'd be able to act in case of trending towards failure.

I'm not asking for an immediate 10x reduction, only a stair step down to that reduction like we've stair stepped up to 100m CU block caps. Each stair step taught us a lot about how the cluster would handle the new limitation and gave us confidence in the next step.

Let's do the same thing with Rent.

[igor56D]

We already have guardrails on how fast state growth can happen as per block limitations. This has already been mentioned in other conversations as a good warning sign that we'd be able to act in case of trending towards failure.

For context, per block limits are set to 100MB, which translates to roughly 45TB per epoch. This is so high that it's essentially meaningless in the context of sustained state growth. Before you suggest reducing this limit, it's a dead end because static slot-level limits are just poorly suited for limiting longer term aggregate resource usage when usage is very bursty (e.g. if we want to limit per-epoch growth to 2GB than each block must be limited to <5KB, which is ~15 token accounts).

I'm not asking for an immediate 10x reduction, only a stair step down to that reduction like we've stair stepped up to 100m CU block caps.

The rent constant can't be compared to the CU limit because the latter is a resource constraint while the former is an arbitrary fixed resource price. This proposal turns the rent constant into a proper resource constraint (the state growth limit) so we can reason about it in similar ways. Because the resource price is decoupled from the resource constraint, we can reduce it much more aggressively and safely.