This is a bit of a reduction in nuance, but the unfortunate response here is that sometimes a person doesn’t get the intended result, despite trying to go big.
Tl;dr is “So with this in mind: a node-runner needs to embrace config swapping because it allows the network to recognize their previous efforts and reward them for it when they move to a new machine. New node-runners won’t be penalized for not being older, they just won’t have the history, yet.”
Note: I use config and peerId somewhat interchangeably in the following text, beware they are not necessarily the same, despite commonly used as such-- as a config generates the peerId but can contain other node-related settings
It is what it is: The Qulibrium network vs Hardware
I don’t blame a person for believing that paying more would get a better result. I did as well, initially.
Nobody knew what different hardware would do when Q was being bootstrapped together, let alone how things would play out as more elements of the plan were introduced.
Logic would generally say: more investment in more power = better results. This is true, to some degree even in Quilibrium, but this has fast been proven that there are many factors to the “power” in Q when discussing computing hardware.
As a non-professional participating in something that is not their domain of expertise the key deciding factor to producing better results is to pay attention, ask questions, adapt to stay competitive (or competitive enough), and not take hubris that they, themself, does not always knows better.
Many people were having a dialog going on in both official and unofficial communications and found out that increments on different machines produced different results-- this was no secret that only a few people knew; it was even actively discussed (and encouraged) in the official Telegram.
This is the power of a bunch of people trying to make things work by experimenting and discarding ideas that don’t work and improving/using those that do.
If a person decides to not pay attention to keep on top of current information or does not understand the implications of said information, it’s not anybody’s fault but their own for not following up (with questions) or acting on the knowledge that was available.
Going forward
As for the future, my recommendation for your current situation: Use metrics to evaluate if your current situation makes sense.
Recognize hardware limitations
High-core count CPUs tend to compensate for higher core counts by using lower clock speeds.
This is due to so many cores in a small physical form-factor and need to reduce the amount of heat in order to not blow up.
To some degree this can be combatted with better cooling or under-volting your CPU such that it doesn’t generate as much heat and can reach higher frequencies.
But this only goes so far and hardware will just reach a design threshold of not being able to do any better.
This results in larger-core machines being slower in proof times, in general, than smaller core count (or more integrated like Apple) CPUs.
Change your strategy
This means that these higher-core machines you invested in are not efficient for starting increments where your difficulties are quite a bit higher (and combined with slower proof times means it’s really slow per increment).
It would make sense to buy/rent a few faster machines to increase your increments and migrate those configs over to the higher core count machines after they’ve been built up to reduce the amount of difficulty given.
Adapt
Start swapping your configs (or learn when you should). Because that is actually an integral part of the network-- your configs are not bound to any one machine-- in fact are encouraged to be moved around (usually up or at the least across). Trying to make it ain’t so is just denial of a key component of the network.
I say “key component” because it is. I will address this later.
Fairness in Established vs New Node-Runners
A node-runner gets rewarded for their config’s effective contribution over time to the network. This “effective” part is directly correlated to your hardware decision as well as presence in the network.
This means that a node-runner will earn more for paying attention to what works and what doesn’t.
The network doesn’t care who a node-runner is, just what a particular config does on it, how effective when the config with what the network gives it, and how long your peerId interacts.
All of that is inherently blind to the person. Node-runners get to choose what to run and for how long they run it.
To me, that seems fair enough and doesn’t speak to centralization at all.
To Swap or Not to Swap
As for swapping configs being something the “something that fresh node holders can’t replicate” comment, my response to that is: this is by design.
The network is designed to have an element of seniority and if any fresh node-runner can jump in and immediately start participating in the inner prover-rings this would allow malicious actors to deliberately and consistantly bog the system down.
This would be done by continuously introducing new nodes (with no penalties) into anywhere in the network. They could target any place, anytime, and just overwhelm the system by filling up an entire prover-ring queue with nodes that will not act in good-faith, such that the network will waste time and resources trying to give tasks to these nodes, even with a mix-net. This will result in a badly-degraded network.
To combat this, the network is designed to force a person to participate over a longer period of time by producing a history of good-faith (and accrued cost) before being considered for more important roles in the network. A bad actor just won’t spend the time and effort (as it is cost prohibitive) to spin up and maintain a ton of nodes to just get them all scratched (i.e. penalized beyond being effective anymore) and have to start over.
And even if so, it allows the network to foster a list of proven nodes (i.e. good seniority with few to no penalties) such that if a bad-faith actor did make it high enough in seniority to be able to participate in any given prover-ring, it wouldn’t matter because there will be more good-faith actors than bad, so efficiency of the network is always high.
So with this in mind: a node-runner needs to embrace config swapping because it allows the network to recognize their previous efforts and reward them for it when they move to a new machine. New node-runners won’t be penalized for not being older, they just won’t have the history, yet.