-
Notifications
You must be signed in to change notification settings - Fork 236
Kappa only set root #1949
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: devnet-ready
Are you sure you want to change the base?
Kappa only set root #1949
Conversation
merge conflict |
Can we please not merge this? Kappa is good for subnet owners to be able to set for commodity-based subnets. Without being able to set a low kappa, you can't make a subnet where miners can only provide a commodity to a single validator. They should have the freedom to do this. For example. on subnet 51 I want a low kappa so that miners can provide just 1 GPU to 1 validator and still get incentive. This is impossible if you force kappa to .5. There must be a kappa stake dominating validator in order for a miner that should get paid to be able to get paid. I don't want that and I'm sure other subnet owners don't want that either. Subnet owners should have more power, not less, in order to get their commodity to be economically viable and productionizable. If we make this change and stop allowing miners to get paid for providing commodities to less than kappa stake weighted validators, it creates a hole in the system. #STOPTAKINGAWAYSUBNETOWNERRIGHTS |
Can we please stop taking away subnet owner rights? This is a bad idea to merge for many reasons. If this is merged, this destroys the ability for subnet owners and miners to have more freedom about how they should allocate, and get paid, for the commodities they provide to the validators. Why do we want to do this? Rhef wants to do this because he thinks that if he keeps taking away more and more rights from subnet owners, he will eventually be able to stop any subnets from scamming. This is an impossible cat and mouse game to win. They will always be able to change hyperparams, change the validator code, create hidden/obfuscated links in their code, bias their own miners by having privledged information, among a myriad of other potential other subnet owner exploits. So, with this in mind, we should let the ones who are going to scam scam, and let the market do it's job to push those subnets to 0. This was the whole point of dtao. Give subnet owner more control because they know their industry and market best. Rhef does not know the market better than every subnet owner for their own subnets. For example, on subnet 51, I want miners to be able to provide just 1 GPU to 1 validator, and get paid by that validator. This change would make that impossible to do anymore even though that miner should be getting paid. It creates a system that unfavorably biases kappa stake dominant validators. Which only paves the way for more exploits. Becase now, the only way for a miner to get paid for providing 1 GPU is if 1 validator has more than kappa stake. That should not be a requirement for a subnet to operate in an economically viable manner. There needs to be more levers that subnet owner can pull in order to bring the market to profitability instead of less. Taking away subnet owner rights will make it slightly harder to scam, but at the same time, much more difficult to bring a product to profitability. What do you prefer? I prefer being able to make my subnet work. Please stop this trend of making more params root only or creating restrictions on the ranges that they can set. #STOPTAKINGAWAYSYBNETOWNERRIGHTS |
oh sorry I thought my comment got deleted so I rewrote it, ignore the redundancy please |
@ppolewicz pls check comments from @surcyf123 . |
KappaCanSetByOwner::<T>::get(netuid) | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if this is needed, the code called inside the function is explicit enough?
|
||
/// Set if Kappa can be set by owner | ||
/// | ||
/// # Arguments | ||
/// | ||
/// * `netuid` - The unique identifier for the subnet. | ||
/// * `can_set` - Whether Kappa can be set by owner. | ||
/// | ||
/// # Effects | ||
/// | ||
/// * Update the KappaCanSetByOwner storage. | ||
pub fn set_kappa_can_set_by_owner(netuid: NetUid, can_set: bool) { | ||
KappaCanSetByOwner::<T>::insert(netuid, can_set); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if this is needed, the code called inside the function is explicit enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
small comments, my other question is why do we want to control if a subnet owner can update kappa or not? isn't kind of restrictive to depends on root to allow that?
Description
According to the #1938, kappa only set by root.
Related Issue(s)
Type of Change
Breaking Change
If this PR introduces a breaking change, please provide a detailed description of the impact and the migration path for existing applications.
Checklist
cargo fmt
andcargo clippy
to ensure my code is formatted and linted correctlyScreenshots (if applicable)
Please include any relevant screenshots or GIFs that demonstrate the changes made.
Additional Notes
Please provide any additional information or context that may be helpful for reviewers.