Dedicated node issues #62

Closed
opened 2024-01-22 22:16:43 +00:00 by scott · 4 comments
Owner

There are at least two major problems with the current implementation of dedicated nodes that represent substantial abuse vectors for the Grid.

1. Setting extra fee can be used to evade workloads

Farmers can set and extra fee on their node, intended to represent the value of a GPU or above average hardware quality. If the node is rented, the farmer gets the whole fee.

But when the fee is set, the node is also marked as "dedicated" and that means that no individual VMs can be deployed on the node. It can only be rented as dedicated.

So if a farmer sets some exorbitant extra fee, they can effectively block any workload from ever running on their node. Thus they farm TFT but supply no usable capacity to the Grid.

This can be partially resolved by capping the extra fee. That's not a great solution, however, because farmer can still set the max fee, still blocking shared workloads and making the node less attractive to rent as dedicated.

2. Any TF Chain account can easily and cheaply block the reservation of a dedicated node

See the issue here: https://github.com/threefoldtech/tfchain/issues/742

This one can potentially have a purely technical fix and is marked as planned for 3.14. However, there was no consensus reached in the issue yet about how to address it.

What to do

While it will be possible to roll out a better design in v4 that doesn't recreate these issues, we so far plan to also keep v3 running. Potentially coop based rewards can provide some oversight on issue 1, but I don't see any simple approach here.

There are at least two major problems with the current implementation of dedicated nodes that represent substantial abuse vectors for the Grid. ## 1. Setting extra fee can be used to evade workloads Farmers can set and extra fee on their node, intended to represent the value of a GPU or above average hardware quality. If the node is rented, the farmer gets the whole fee. But when the fee is set, the node is also marked as "dedicated" and that means that no individual VMs can be deployed on the node. It can only be rented as dedicated. So if a farmer sets some exorbitant extra fee, they can effectively block any workload from ever running on their node. Thus they farm TFT but supply no usable capacity to the Grid. This can be partially resolved by capping the extra fee. That's not a great solution, however, because farmer can still set the max fee, still blocking shared workloads and making the node less attractive to rent as dedicated. ## 2. Any TF Chain account can easily and cheaply block the reservation of a dedicated node See the issue here: https://github.com/threefoldtech/tfchain/issues/742 This one can potentially have a purely technical fix and is marked as planned for 3.14. However, there was no consensus reached in the issue yet about how to address it. ## What to do While it will be possible to roll out a better design in v4 that doesn't recreate these issues, we so far plan to also keep v3 running. Potentially coop based rewards can provide some oversight on issue 1, but I don't see any simple approach here.
scott self-assigned this 2024-01-22 22:18:10 +00:00
Owner

Very good points.

Yes it seems coop can fix this by monitoring the nodes in the coop and contact the farmers if the price is unreasonable. Also on a purely utilization rewards scheme, this problem would be "solved" by the market it seems:The demand would not accept such high offer.

Very good points. Yes it seems coop can fix this by monitoring the nodes in the coop and contact the farmers if the price is unreasonable. Also on a purely utilization rewards scheme, this problem would be "solved" by the market it seems:The demand would not accept such high offer.
Owner

@scott @mik-tf Is this something we want to keep open for any reason?

@scott @mik-tf Is this something we want to keep open for any reason?
Owner

I think it is still relevant. Should we move it to engineering? @scott

I think it is still relevant. Should we move it to engineering? @scott
Author
Owner

I think the priority now should be trying to not repeat the same mistakes in v4. The situation with item 1 has in theory been improved somewhat by the fact that farmers now get a cut of revenue on their nodes. We've seen some but only a little evidence that item 1 is being abused.

As for item 2, it's also not affecting us in a big way right now.

So I think for v3, this can be a "jump off that bridge if we come to it" sort of thing.

I think the priority now should be trying to not repeat the same mistakes in v4. The situation with item 1 has in theory been improved somewhat by the fact that farmers now get a cut of revenue on their nodes. We've seen some but only a little evidence that item 1 is being abused. As for item 2, it's also not affecting us in a big way right now. So I think for v3, this can be a "jump off that bridge if we come to it" sort of thing.
scott closed this issue 2025-01-03 23:41:28 +00:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: tfgrid/circle_comms#62
No description provided.