Yes it’s fine, proportional but bounded.
We need back pressure anyway so right now the parachain team suggests we apply back pressure all the way to backing right away.
Any validator has more approvals assignments than backing jobs, so we’d wondered if validators could reject some of their approval checker assignments. Yet, we’ve never figured out how this impacts security, so probably a bad idea.
Instead, we now suggest overloaded nodes simply delay their own backing work, which brings no soundness consequence. It’s also a reason to have smaller backing groups, so the system feels the back pressure sooner, which should improve performance but harm liveness.
In principle, we could even eliminate backing groups all together: We define a random permutation V of the validator indices based upon the epoch randomness and relay parent block height mod 3 or whatever. We separately maintain a list C of parachains weighted and sorted by their likelihood of buying a slot. Your parachain_index is your location in C, which we map into V. Alfonso maybe knows approximation for this packing problem, but one dirt simple one goes:
let d = parachain_index / num_validators;
let i = parachain_index % num_validators;
let backer_zero = if d % 2 = 0 { i } else { num_validators - i - 1 }
let backer = (backer_zero + backer_priority) % num_validators;
We access any backer we like in V by increasing backer_priority, but cost increases rapidly as backer_priority increases, so parachains should typically send to backer_zero or accept being back pressured if backer_zero feels overloaded right now.
It’s free to maintain V of course, and even simple using this I’ve no idea how even define the weighting in C, much less maintain C itself. We could just move parachains around in C whenever the produce a parablock I guess.