(Apologies, my username appears to be out of sync here on the forums, Iām ācall_me_alā in Discord)
Iām bringing some of my points from Discord here as it seems the more appropriate venue for discussion. Iām very interested in seeing the public version of these tables, and will absolutely read any new information if itās presented there, but after looking at that screenshot a little more, I have fundamental disagreements with the assumptions made to generate those costs, and thus the conclusions that they drive.
Mainly - none of those costs include labor. Please correct me if Iām wrong, but the āTri Region cost per monthā seems like exclusively server hardware cost - leasing or amortized purchase cost+colo. First of all, if thatās the case, it is fairly aggressive for three regions for N+1 (I hope this represents at least 6 total sources for each chain), and thereās 0 accounting for ancillary costs (non-chain infrastructure, like automation servers, monitoring servers, log aggregation servers, communication platforms, etc.). I operate managed backend chain nodes professionally, and I can tell you that doing it right involves more hard costs than just chain servers, and the nature of blockchains means you need more redundancy that you might in other workloads (to provide a service others can rely on).
Secondly, my main point - labor costs. Setting up servers and chains can be helped by modern automation tools (that take time to setup up front and update over time), but ongoing care and feeding is absolutely a requirement that takes (expensive) engineer hours. As anyone who has ran a blockchain node where the performance and sync status is being monitored can tell you, nothing is āset it and forget itā. Again, tools and modern systems can go a long way to get rid of the repetitive work, but the nature of these kinds of operations means there will always be some amount of toil required.
For example, if you are providing a chain node service professionally, and you have everything all setup and running and as lean as possible, you still need an engineer on-call 24x7x365. You can get away with some on-call deadspots in the middle of the night if you architect your system with more redundancy (so definitely n+1, probably n+2 for some chains), but you still need a skilled human ready to respond to alerts (from the monitoring system you setup with time and keep running with money). Chains never stop, there is no ādowntimeā, and realistically you need multiple resources to split because human beings are not good at being āonā all the time.
So basically, I am arguing that the costs presented are not accurate, and taking it a step further, my thesis is that the price is low enough that it will create a obvious financial decision where it makes more sense for ALL large runners to use this service rather than run chains themselves. Iām going to copy my comments from the Discord thread here because they are relevant:
Iād like to discuss the āit will cost 15% of rewards generatedā cost of the service and learn more about how that number was arrived at. Rather than dance around my point, hereās the fear - this service is priced so far below the actual cost-per-relay of some specific chains, that the smart economic choice will be to ALWAYS use CC. For large pokt staking providers in a post-lean world, backend chain hardware and management is probably the single biggest expense, followed by human operations, and only distantly followed by the cost of running the pokt daemon and infrastructure itself. Given that, if an option exists where they can generate at least 85% of the relays as they would running it themselves, and they know that their total chain running costs are >15% of their relay-revenue, why wouldnāt they make the rational choice of using CC for all traffic? So arguably this is a good thing and the idea, removing waste and opening up opportunities to runners who may not be able to justify it themselves. My nightmare scenario comes in here when the large providers also start doing the math and jumping on board. If one of them decides that the costs of running their own outweigh the 15% āopportunity costā of running it themselves, their rational choice will be to use CC as well. In the current economic and tokenomic climate, everyone is looking to optimize expenses to make the most out of the revenue they are pulling in, and this seems like an inevitable choice that will be made.
Now - weāve got a ton of community traffic riding on the CC infrastructure, everyone is pulling in relays, and the people providing the backends to CC will be doing the same arithmetic in their heads. They may make the decision to remove themselves from CC if the additional traffic incur additional costs above and beyond the 15% (which is always a risk with a community/open model, but not insurmountable), but more worryingly, what if the providers also realize that it will be overall more profitable for them to stop providing and start consuming CC? We might put ourselves into short term infrastructure spirals where we as a network hyper-consolidate in different regions for different chains down to JUST the remaining CC providers, only to have to rapidly re-expand if there is a capacity or availability issue, all while showing āhealthyā stake numbers from a network-perspective.
The crux of my argument is this - āThe price per relay should be managed such that it provides room for running chains yourself (when taking into account your own time), and not low enough that it is impossible to match, even with self-hosted, $0/hr labor, bare metal.ā My opinion is that 15% is too low - speaking as a node runner myself, my own expenses are MUCH more lopsided to the backend chains themselves, and if I was exclusively trying to optimize operations for profit, I would never chose to run any backend chains myself and always use CC or CC-like service.