BIT-0018: Distributed subnet ownership #31
Conversation
l0r1s
changed the title
|
|
||
| The separation of profit and governance shares provides maximum flexibility for subnet ownership structures. This allows for scenarios where: | ||
|
|
||
| - **Investors** can receive economic benefits without governance control |
There was a problem hiding this comment.
Investors and Contributors differ - Investors provide capital while Contributors provide work. It'd be good to distinguish those clearly so that we have the language to talk about it later.
| - **Vote buying**: Locked shares prevent vote trading | ||
| - **Sybil attacks**: Share-based voting requires economic stake | ||
| - **Governance capture**: Minimum thresholds and voting strategies provide protection | ||
| - **Time-based attacks**: Expiry blocks prevent indefinite proposals |
There was a problem hiding this comment.
Can't someone time new proposal additions to happen as soon as the previous one is terminated, blocking the ability of the governance body to raise proposals?
This can be potentially addressed by making it so that the closing block pseudo-randomly (based on last valid drand seed?) assigns a preferred voter with share-weighted probability that they are going to be selected to prevent sybil attack where a small shareholder will fracture themselves into a thousand pieces to increase their chances of being selected.
After the previous proposal is terminated, the preferred proposer would have a few blocks during which only they could submit a new proposal.
There was a problem hiding this comment.
Simplified Solution to Governance Attack Prevention
I propose simplifying the solution to this problem. Since proposals already require >10% of voting shares to be created, we can assume an attacker holds <50% of total shares (otherwise, they could simply block any proposal, resulting in complete governance failure).
Mechanism:
Release all voters' shares immediately after proposal execution
Delay the unlock of the proposer's shares for X blocks
This prevents attackers from continuously blocking governance decisions
Attack Limitations:
An attacker could execute at most 4 consecutive proposals by distributing their shares across 4 separate accounts, each holding the minimum 10% threshold required for proposal creation.
Timing Considerations:
The unlock delay must be shorter than the proposal expiry time, ensuring that even delayed proposers can participate in subsequent votes.
This approach maintains voting accessibility while creating a natural cooldown period that prevents malicious actors from monopolizing the governance process.
There was a problem hiding this comment.
but it prevents the small holders from triggering a vote. If no holder has at least 10%, no voting can happen.
|
|
||
| **Process**: | ||
|
|
||
| 1. Owner cut accumulates until `DistributedSubnetProfitInterval` (e.g., every 1000 blocks) |
There was a problem hiding this comment.
lets not introduce a new being, but use the subnet superblock (one epoch block in 20 tempos)
There was a problem hiding this comment.
@ppolewicz I think it has been discussed that there is no concept of "superblock"
|
|
||
| **Process**: | ||
|
|
||
| 1. Alice calls `transfer_profit_shares(distributed_subnet_id, 100, david_hotkey)` |
There was a problem hiding this comment.
Alice signs it with her coldkey
| **Process**: | ||
|
|
||
| 1. Alice creates proposal (40% shares, above 10% minimum) | ||
| 2. Bob votes No (35% shares), Charlie votes No (25% shares) |
There was a problem hiding this comment.
after Bob votes no, the proposal should be terminated already
|
|
||
| - **Creation**: Requires minimum governance shares (configurable using `NewProposalMinShares`, default 10%) | ||
| - **Active**: Only one proposal can be active at a time | ||
| - **Locked Shares**: Proposer's governance shares are locked during proposal |
There was a problem hiding this comment.
this document needs to be revised by an AI to remove multiple mentions of the exact same thing, I'm pretty sure this one appears at least 3 times
| ```rust | ||
| pub enum VotingStrategy { | ||
| ShareProportionMoreThan(Percent), // e.g., X% of total shares | ||
| MembersProportionMoreThan(Percent), // e.g., X% of voting members |
There was a problem hiding this comment.
not in v1. Voting shares percentage only is good enough to start.
There was a problem hiding this comment.
I would even say that MembersProportionMoreThan does not make any sense, as a voter could quite easily sybil attack this vote.
There was a problem hiding this comment.
@vstam1 @ppolewicz That's right, I will remove it entirely and only have it support % of shares
| - The sum of all profit shares must not exceed 1000 (100%) | ||
| - The sum of all governance shares must not exceed 1000 (100%) |
There was a problem hiding this comment.
@ppolewicz I don't think using u64 shares split is needed? Do we have a use case for this?
I got the impression of having at least 0.1% of share is enough for most use case?
|
|
||
| - The sum of all profit shares must not exceed 1000 (100%) | ||
| - The sum of all governance shares must not exceed 1000 (100%) | ||
| - If the sum of shares is less than 1000, the remaining shares are automatically assigned to the subnet owner |
There was a problem hiding this comment.
| - If the sum of shares is less than 1000, the remaining shares are automatically assigned to the subnet owner |
that's very confusing, can we remove it?
|
|
||
| #### Proposal Execution | ||
|
|
||
| When a proposal reaches the required threshold, it is executed automatically and immediately with the permission of the subnet owner. The execution happens as soon as the threshold is reached, without requiring manual intervention. |
There was a problem hiding this comment.
| When a proposal reaches the required threshold, it is executed automatically and immediately with the permission of the subnet owner. The execution happens as soon as the threshold is reached, without requiring manual intervention. | |
| When a proposal reaches the required threshold, it is executed automatically and immediately. The execution happens as soon as the threshold is reached, without requiring manual intervention. |
|
I think the division between Governance shares and Profit shares should be emphasized more in the document |
|
I like the general approach of this BIT. A couple of remarks:
|
|
3 participants
The current Bittensor subnet ownership model creates significant limitations by registering ownership to a single on-chain entity. It offers no native mechanism to distribute ownership rights or rewards, hindering collaborative governance and investor participation.
This PR introduces Distributed Subnet Ownership, a protocol-level solution that allows both economic and governance rights to be fractionalized into on-chain shares. This enables multiple stakeholders to co-own and manage a subnet directly on-chain.
A native implementation provides a standardized, secure, and efficient framework, which is preferable to bespoke smart contract solutions. By integrating this functionality into the protocol, we can strengthen decentralization, improve transparency, and lower coordination costs for subnet operators, contributors, and investors.