Public IPv4s should be unique

[scottyeager]

It's currently possible for a single IPv4 address to be simultaneously:

1. Assigned to a node via a public config for gateway functions
2. Assigned to the pool of rentable IPv4 addresses for the same farm as the previously mentioned node

This creates a problem if both a node and a VM are trying use the same IP address at the same time. Of course the farmer should avoid creating this situation in the first place. However, it's a simple check we can add to avoid a fairly serious problem:

1. When an IPv4 address is added to a public config, check that it's not part of the IP pool for the same farm
2. When an IPv4 address is added to a farm's IP pool, check that it's not assigned to a public config for a node in the same farm

The same farm part is important, because otherwise farmers can falsely add IP addresses to their farm's pool and deny the real owner from using them in a public config.

[sameh-farouk]

I'm not sure if this is already handled from the dashboard or zos side (@AhmedHanafy725 @ashraffouda thoughts?), but from TFChain side, your concern is valid. The current runtime code validates address formats but does not cross-check between the farm IP pool and the node’s public_config. As a result, a duplicate IPv4 address can currently exist across these two locations.

• Current Behavior

  • Farm public IP pool
    Stored as BoundedVec<PublicIP, ConstU32<256>>.
    Since iteration is capped at 256, validating in _add_node_public_config that cfg.ip4.ip is not already in the pool requires only a small, bounded scan.
    This is effectively a constant time complexity and poses no scalability concern.

  • Nodes by farm
    Stored as NodesByFarmID: StorageMap<u32, Vec>.
    This vector can grow with the farm size.
    Implementing an additional safeguard in _add_farm_ip by iterating through all nodes to check if any node.public_config.ip4 matches the new IP — would be O(N_farm_nodes) and could become expensive for large farms.

• Proposed Improvement

  To avoid this costly iteration, we can introduce a new index StorageMap to support O(1) conflict checks.
  This would require a storage migration to populate the index from the existing state.

  Impact:

  • Each operation that sets, updates, or clears a node’s public_config, or moves/deletes a node, would add 1–2 extra storage operations to keep the index in sync.

  • The conflict check itself becomes a single storage read, making the solution efficient and scalable.