Node contracts without any resources used

[AhmedHanafy725]

anyone can create a node contract but the contract may not be attached to a deployment and this contract will block the node from being rented as it has a contract. So anyone can create contracts on all nodes (this will cost him only the extrinsic fee) and break the feature of renting a free node without being in a dedicated farm.

Related Issues

• gridproxy report zero contracts for anode listed in dedicated nodes although it has one active contract  tfgrid-sdk-go#175

not sure what should be done in this case but as suggestions:

• the node contract should be paid a periodic fee even if it doesn't have a deployment.
• the node contract should have a lifetime. and if it doesn't have any resource report, it should be deleted.

[DylanVerstraete]

So indeed what is stated above is correct. Whilst the suggestions sound good at first, the problem is quite larger.

1: Having the user pay a periodic fee will not always lead to canceling an empty contract, since this is in the user control. And some users just deploy and forget for indefinete amount of time.

2: Nodecontracts without resources can be wireguard endpoints, as the user can deploy an access point on any node I don't believe the second proposed suggestion is even valid here. Since it will always result in deleting all access points for all users after some period. And even some users could go as far as exploiting the system and always deploy an empty new node contract whenever the old one is expired to eventually block a node from being rented.

The bigger problem here is that the tfchain is used a registry and that it needs to rely on it's clients to be truthful, if we would have tfchain orchestrate work order (reservations) we would have more granular control over what goes where. But I don't believe doing this is also a solution to the above stated problem.

I also don't see any other immediate solution beforehand, I think the concept of dedicated nodes is highly broken on tfchain and whatever workaround we might come up with will lead to even worse user experience.