subspace
No reward for running a timekeeper in the network may lead to centralization
[Low] No reward for running a timekeeper in the network may lead to centralization
Summary
Nobody is likely to run a timekeeper if there is no incentive as it is costly.
Issue details
Running a timekeeper consumes power and requires either CPU resources or the expense of an ASIC. As this does not bring any money to those who invest in a timekeeper, it is unlikely that anyone will run a timekeeper besides the subspace organisation.
Risk
If only very few timekeepers are present and those are likely to be from one entity, the chain will essentially be centralized. Additionally, this increases the risk for a denial of service attacks on the timekeepers.
Mitigation
We suggest implementing incentives for the timekeepers.
Running a timekeeper consumes power and requires either CPU resources or the expense of an ASIC.
The plan is to produce an ASIC and distribute it to the community, it is not expected to be expensive for end user once it exists.
As this does not bring any money to those who invest in a timekeeper, it is unlikely that anyone will run a timekeeper besides the subspace organisation.
The security of the protocol depends on timekeepers, hence statement "it is unlikely that anyone will run a timekeeper besides the subspace organisation" is weak. Either way we will encourage community to run timekeepers and we expect that at mainnet exchanges and other interested parties will also do this. Running it is not that expensive, you just need highest-end consumer CPU (not workstations, those have lower frequencies), ideally heavily overclocked, that uses a bit more than one CPU core on average.
If only very few timekeepers are present and those are likely to be from one entity, the chain will essentially be centralized.
The security model requires at least one online timekeeper. Since anyone can run one it is highly unlikely that there will be zero timekeepers online.
Additionally, this increases the risk for a denial of service attacks on the timekeepers.
True, but again, it is very unlikely that it will be ever possible to knock-out all timekeepers. The only real concern here is high-performance timekeepers with overclocked highest frequency processors. Once those are all offline (which we will likely have fewer of) then security of the protocol will be reduced, it will be possible to outrun honest PoT chain by an attacker, but to attack the protocol they would still have to have more than 50% of the storage.
We suggest implementing incentives for the timekeepers.
This has proven to be very tricky to do and untilmately deemed unnecessary.
@dariolina please provide additional feedback for this issue if I missed something.
This has proven to be very tricky to do and untilmately deemed unnecessary.
Correct me if I'm wrong, but it looks like the most difficult challenge with incentivizing the timekeeper is to make sure that the gossiped PoT are not unbundled and resubmitted by a different party, which ensures that the timekeeper that submitted the proof actually receives the reward. Just signing a PoT is not sufficient since the PoT can be unbundled, resigned and regossiped. One possibility on how you could connect the timekeeper's identity with the actual PoT is to include the timekeeper's public key in the seed, e.g., hash(timekeeper_pub_key || tip.output). The pub key would then be gossiped along the proof. Now the PoT can not be 'unbundled' without recalculating the PoT.
One possibility on how you could connect the timekeeper's identity with the actual PoT is to include the timekeeper's public key in the seed, e.g., hash(timekeeper_pub_key || tip.output). The pub key would then be gossiped along the proof. Now the PoT can not be 'unbundled' without recalculating the PoT.
This is not possible because PoT needs to be deterministic and canonical for the chain. When we mix in something timekeeper-specific, we make every timekeeper generate different proof, which makes no sense for the use case we have here.
One possibility on how you could connect the timekeeper's identity with the actual PoT is to include the timekeeper's public key in the seed, e.g., hash(timekeeper_pub_key || tip.output). The pub key would then be gossiped along the proof. Now the PoT can not be 'unbundled' without recalculating the PoT.
This is not possible because PoT needs to be deterministic and canonical for the chain. When we mix in something timekeeper-specific, we make every timekeeper generate different proof, which makes no sense for the use case we have here.
could you elaborate please why this is not possible? PoT would still be deterministic, everybody could verify them. sure the PoT results would be different but why is this important if a node need to check that PoT is valid anyway?
The PoT output is used as our block challenge. By mixing in a public key, we would basically make it grindable.
We are not blockchain designers. Our point is that there are likely ways to incentivice a timekeeper, but obviously that will introduce risks and changes needed to the protocol. To us it seems like there is no incentive because the problem seems to be too hard to solve and so the easy way is just not to have them. From a user perspective it is more beneficial to run a private timekeeper then to have an advantage at block production. Also it can result in less trust in the chain if there is the need for the project to run honest and public timekeepers so subspace would be less decentralized as advertised and hence not win the hearts of early adopters.
To add to the proposal of my colleague that does not work with how subspace currently is designed: once a PoT is generated the PoT result could be AES encrypted again with the key of the timekeeper and added to the message, so containing slot number, seed, slot_iterations, checkpoints, timekeeper_pubkey, checkpoints_timekeeper_keyed. The overall AES iterations to achieve 1 second of computation could then be assigned 2/3 for PoT and 1/3 for the timekeeper pubkey keyed PoT. I am not saying this is the optimal solution, just putting out there that there are ways that would could potentially work.
I'm not saying it's impossible, rather that we are not considering this something to be solved by mainnet beta since it will require a non-trivial amount of research and does not seem to be critical. For comparison, Chia does not incentivize timelords either. Incentives may be added down the road if we figure out a good way to do it.
From a user perspective it is more beneficial to run a private timekeeper then to have an advantage at block production.
We need to identify what kind of advantage they get in this case then. If they run at the same speed as the rest of the network, which at mainnet will be basically the best case scenario, all they benefit from is cutting the network delay before they get the next proof. They still have to have the space pledged to the network.
I see why would someone want to run a timekeeper to get the proof faster and potentially edge-out someone in announcing new block to the rest of the network in case of an honest fork, but I don't really see the reason to modify the software and not announce the proofs to the rest of the network since there doesn't seem to exist any reward associated with such a behavior.
Also it can result in less trust in the chain if there is the need for the project to run honest and public timekeepers so subspace would be less decentralized as advertised and hence not win the hearts of early adopters.
There is no registration or other restriction to become a timekeeper, any node is --timekeeper away from becoming a timekeeper. I don't see why we would not have many community-run timekeepers just like we have nodes and farmers, even if they do it for themselves, they still help the rest of the network in the process.