Stellar
Revisiting the Soroban non-refundable resource fees #1831
Replies: 3 comments 2 replies
-
|
Some concerns have been raised internally regarding the complexity of the proposed approach and the fact that it might not be feasible in the long term. Currently, there is no real surge pricing pressure on the network, so the resource weighting is rather arbitrary. In the future, if there is some measurable pressure caused for a given resource, the fees may be increased just for that resource, which doesn't fit into the approach above. Alternative, and much simpler approach for this iteration, is to just lower all the non-refundable resource fees 4x, and the events+return value fee 2x. The motivation for that is that the resource capacity has grown ~4x since Soroban launch for most resources (some resources went up more or less, but that also has something to do with more or less conservative approaches to different resources on launch). The event cost reduction is just a rather conservative step - there is no limited capacity for this, so we could lower the cost until while it still remains safe enough to prevent abuse. The summary with the transaction costs is available here |
Beta Was this translation helpful? Give feedback.
-
|
Alright makes a lot of sense |
Beta Was this translation helpful? Give feedback.
-
|
This makes a lot of sense conceptually — tying non-refundable fees to per-ledger utilization instead of per-tx limits aligns much better with the real cost to the network. 👍 |
Beta Was this translation helpful? Give feedback.
-
While I appreciate the feedback, we've decided to go in a bit simpler direction for now with a straight up proportional decrease in fees. We will keep the ledger capacity increases in mind going forward - most of the time it would likely make sense to proportionally decrease the fees if the capacity can be safely increased.
I don't think there is significant difference. The most expensive transaction possible with SLP-4 would cost ~0.17 XLM. Any real transaction is likely going to be cheaper than that (it's tricky to max out all dimensions at once). In general, I don't think the precise fee structure makes much difference for batching - e.g. making several updates to the same entry at once is always going to be cheaper vs sending several transactions. But the absolute value of the fees is hard to judge in a vacuum - different protocols may have different thresholds of what fees are acceptable.
Again, irrespective of the exact fee value, it's pretty much impossible to predict what the right values would be (unless we're talking about extremes like having effectively 0 fees). The end goal is really to figure out the lowest resource fees possible that still don't compromise the network. That's why we're trying to reduce the fees in a reasonably conservative fashion - this approach has relatively low risks, as the actual execution time is guarded by per-ledger resource limits.
Long term impact is covered by the rent model, the writes basically cover any modifications to the ledger, not just those that increase the size of the persistent state.
Right now we have some protocols on mainnet that make tens of cross-contract calls, yet the average per-transaction resource utilization is rather low, i.e. the network activity is well within even the existing limits. I'm also not aware of the protocols that reported about being limited by the current resources, but that of course doesn't mean that they don't exist. So my hope is that the increased limit will encourage developers to try and build even more complex protocols, or at least enable more efficient batching for the existing protocols. |
Beta Was this translation helpful? Give feedback.
-
|
Terimaksih 🫶 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Non-refundable resource fees for Soroban resources hasn't been updated since its launch, besides the switch from a dynamic write fee to the static write fee in protocol 23. However, the limits have been changed a few times, and it seems like the network is due to a fee re-calibration. Note, that the rent fees have been recently adjusted in protocol 23 (and lowered the contract data rent fee ~7x), and are not in the scope of this particular discussion.
The goal of the re-calibration is to revisit the approach to setting the non-refundable fees and lower the overall non-refundable fees.
On Soroban launch the non-refundable resource fees have been set such that the transaction that maxes out all the resources will cost 0.3 XLM. Each resource fee then has been scaled proportionally to that resource's per-transaction limit. Since then, the per-transaction limits have been updated several times without a fee adjustment. While we could keep this approach and just re-calibrate the fees with a new maximum fee and up-to-date per-resource scaling, a new approach is proposed here.
Non-refundable resource fees can be thought of as flat fees for ledger utilization, unlike the dynamic fees per computation unit on other blockchains. This is a simplification used for supporting multi-dimensional resource model (dynamic per-resources fees are likely not practical, as every resource needs would have its own fee market, which would make choosing the right bid tricky for the users). The resource fees encourage transactions to correctly specify the necessary resources and thus the fraction of the ledger capacity they will take. If resource fee scaling isn't meaningful (say, from 0 to 100 stroops), then there is effectively no incentive for specifying the appropriate resources - every transaction could just max out every resource and thus reduce the effective ledger throughput.
Given that the non-refundable resource fees represent ledger utilization, the new proposed approach is to base the fee scaling on the per-ledger (and not per-transaction) resource limits. Specifically, a maximum non-refundable resource fee per ledger is defined. The goal is to set it as low as possible while still allowing for some scaling (likely in the range of 0.1-0.5 XLM). Then every resource dimension gets a fee that is a fraction of the maximum ledger fee proportional to the 'weight' of the resource. Weight is just 1 for the most resource, increased for the resources that have long-term impact. The weights can be taken from the current approach: 3x weight for the ledger write KB and 5x for transaction size.
For example, if the total per-ledger fee is 0.5 XLM, and the sum of the resource weights is 12, then the resource fee for a single 1x weight resource dimension would be
0.5 / 12 = 0.042 XLM. So with the current resource limits 600M instructions would cost 0.042 XLM, 500 entry writes would cost 0.042 XLM etc. Per-unit resource costs are then calculated proportionally to the respective resource limit, e.g.0.042 / 500 = 0.000084 XLMper entry write. See the full computation model in the spreadsheet.New approach better corresponds to the role of the non-refundable fees (i.e. payment for the ledger utilization) than the old one. If network can handle more resources per ledger (e.g. due to optimizations of Stellar Core), then the respective fees will go down proportionally. Similarly to the old approach, it's also easy to tune all the fees by adjusting a single number.
Please chime in here if you have any comments on the proposed approach or the overall non-refundable fee structure.
Beta Was this translation helpful? Give feedback.
All reactions