flint vessel
What should we talk about this week? The meeting is on <t:1719518400:F>
Join the event here: https://discord.gg/AEg8Uucs?event=1253933665235370035
#Agenda for Developer Meeting - 6/27/2024
dry spire
Yep! I'll be showing off the new tx subcommands and using a ledger to sign transactions! And chad I believe will focus on the updates to the bindngs command, which now is mainly for the TS type for a contract and the JS sdk handles the contract client creation from the xdr.
dark sluice
I am interested in any existing work around contract fee simulation and optimization. Has anyone dove deep into this? Is there any work here/subject matter experts that could share?
Like any sort of performance optimization, context is everything; if a customer's typical network speed is x, doesn't matter much if the website loads in x-100 or x-1000...
Curious how, in production on mainnet, if folks have found themselves spending time reducing costs? Are they substantial? Or is it negligible and not a significant spend to justify the time?
IDK if this is interesting to anyone else, so if not, no worries at all!
[Inspiration]: saw what @golden lodge added to stellar.expert and it piqued my curiosity.
stuck yacht
@supple dove has looked into that quite a bit
on the surface, it's definitely worth to store less data or use temp storage if possible. so far storage costs (specifically, writing new data to the storage) make for the biggest fraction of the transaction cost.
dark sluice
Makes sense. Thanks for the info @stuck yacht! Curious about whether instruction reduction has ever been worth pursuing.
I suppose the beauty of all this (and maybe even OribitLen’s work) is we can extract fee trends from existing production contracts 😁
stuck yacht
well, reducing the necessary number of instructions objectively reduces the resource fee. the question really is whether the absolute reduction is worth it. as a data point, 10k instructions cost 25 stroops, so given the 100M instructions per transaction limit any transaction can at most spend 250k stroops (== 0.025 XLM). this is an upper bound of your savings on instructions. realistically, typical contract invocations should consume around 10-20M instructions, which accounts for 25-50k stroops. I think this provides a decent framework to figure out the potential benefit of optimization; I believe that optimizing purely for instructions is not worth it unless it's either trivial (like don't do useless work), or you expect really significant traffic
also, as another data point, creating a new token balance entry for a contracts costs 0.3 XLM for 120 days of rent. that's 2 orders of magnitude more than the maximum instruction costs and that's why I'm suggesting looking at the storage first and foremost
(further updates are much cheaper though)
dark sluice
think this provides a decent framework to figure out the potential benefit of optimization; I believe that optimizing purely for instructions is not worth it unless it's either trivial
Yep, ok, thanks for this context. Yeah does not seem like the juice is worth the squeeze there. I am personally curious if providing a visual of this info is useful for developers (as the first step to optimizing is understanding the current state). Not even sure that's super useful given how cheap instructions are to execute 🤷♂️
I'll do some more of my own research here and see what, if anything here makes much sense to visualize for folks to then understand and consider ways to optimize. Thanks again @stuck yacht!