hyperledger
Amendments to Hyperledger Fabric Technical Charter
Type of change
- Updates to Hyperledger Fabric Technical Charter
Description
The proposed amendments aim to restructure the governance to support an ecosystem of multiple "Sub-Projects" under the Hyperledger Fabric umbrella.
Additional details
The "Fabric Ecosystem Coexistence Model" RFC, which provides the detailed rationale for these charter changes, can be found at: https://github.com/hyperledger/fabric-rfcs/pull/64. The deliberation and voting process for these proposed charter amendments will be conducted in conjunction with the review and approval of this RFC.
@cendhu, thanks for the update, charter. I think we need to have a little more rigorous formulations and definitions.
The proposed governance structure has a significant vulnerability that could enable a small coordinated group to gain control of the ecosystem through Sub-Project proliferation.
The Attack Vector
Step 1: Initial Foothold
- A coordinated group gains influence in 1-2 existing Sub-Projects or gets their members appointed as maintainers
- They now have representation in the TSC and voting power
Step 2: Sub-Project Proliferation
- They create multiple new "Sub-Projects" with minimal functionality (e.g., simple tools, utilities, documentation projects)
- Each new Sub-Project only needs simple majority approval from existing Sub-Project maintainer groups
- As they create more Sub-Projects, they gain more votes to approve subsequent ones
Step 3: Equal Voting Power Exploitation
- Critical flaw: Each Sub-Project gets exactly one vote regardless of:
- Size of codebase
- Number of contributors
- Community activity
- Strategic importance
- A trivial utility project has the same voting power as the core Fabric blockchain
Step 4: Ecosystem Control
- Once they control the majority of Sub-Project votes, they can:
- Block any ecosystem-wide decisions they oppose
- Approve new policies that benefit their interests
- Control the approval/rejection of future Sub-Projects
- Even amend the charter itself (requires supermajority, but achievable with enough Sub-Projects)
Mitigation Strategies the Charter Should Include
-
Weighted Voting: Base voting power on metrics like:
- Number of active contributors
- Commit activity
- Community size
- Strategic importance
-
Higher Approval Thresholds: Require supermajority or TSC approval for new Sub-Projects
-
Activity Requirements: Define clear metrics for "active" status and regular reviews
-
Minimum Viability Standards: Require substantial codebases, community engagement, or strategic value
-
Sunset Mechanisms: Automatic removal of inactive Sub-Projects from voting
@cendhu, thanks for the update, charter. I think we need to have a little more rigorous formulations and definitions.
The proposed governance structure has a significant vulnerability that could enable a small coordinated group to gain control of the ecosystem through Sub-Project proliferation.
The Attack Vector
Step 1: Initial Foothold
- A coordinated group gains influence in 1-2 existing Sub-Projects or gets their members appointed as maintainers
- They now have representation in the TSC and voting power
For now, each sub-project has only one vote, irrespective of its size. Once the number of sub-projects increases, we can evolve to an election model to form a TSC, similar to how it is done in LFDT.
Step 2: Sub-Project Proliferation
- They create multiple new "Sub-Projects" with minimal functionality (e.g., simple tools, utilities, documentation projects)
- Each new Sub-Project only needs simple majority approval from existing Sub-Project maintainer groups
- As they create more Sub-Projects, they gain more votes to approve subsequent ones
A sub-project can have a family of repositories. Creating documentation, tools, or utilities for Fabric-Classic or Fabric-X would not constitute a sub-project. This will be decided on a case-by-case basis with votes.
Are you suggesting a supermajority vote for approving a new sub-project?
Step 3: Equal Voting Power Exploitation
Critical flaw: Each Sub-Project gets exactly one vote regardless of:
- Size of codebase
- Number of contributors
- Community activity
- Strategic importance
A trivial utility project has the same voting power as the core Fabric blockchain
The method followed in LFDT is good. They consider all contributors as voters, and they choose the TSC to manage the LFDT ecosystem. We can do that when we have three or more sub-projects. For now, it is too early and would be too much overhead for just two sub-projects.
Step 4: Ecosystem Control
Once they control the majority of Sub-Project votes, they can:
- Block any ecosystem-wide decisions they oppose
- Approve new policies that benefit their interests
- Control the approval/rejection of future Sub-Projects
- Even amend the charter itself (requires supermajority, but achievable with enough Sub-Projects)
Mitigation Strategies the Charter Should Include
Weighted Voting: Base voting power on metrics like:
- Number of active contributors
- Commit activity
- Community size
- Strategic importance
Higher Approval Thresholds: Require supermajority or TSC approval for new Sub-Projects
Activity Requirements: Define clear metrics for "active" status and regular reviews
Minimum Viability Standards: Require substantial codebases, community engagement, or strategic value
Sunset Mechanisms: Automatic removal of inactive Sub-Projects from voting
We will have to change this charter once the number of sub-projects increases so that we can conduct elections to choose the TSC.
@cendhu thanks, I think we are converging, though, would you agree to define the archiving procedure for the inactive project? Currently, there's no mechanism to remove inactive or abandoned Sub-Projects from voting eligibility, allowing dead projects to maintain voting power indefinitely.
@cendhu thanks, I think we are converging, though, would you agree to define the archiving procedure for the inactive project? Currently, there's no mechanism to remove inactive or abandoned Sub-Projects from voting eligibility, allowing dead projects to maintain voting power indefinitely.
@C0rWin @denyeart @manish-sethi @tock-ibm @yacovm @andrew-coleman @bestbeforetoday @pfi79 @satota2 @ale-linux
A charter should not be overly specific or restrictive. I have read the LFDT charter (https://lf-decentralized-trust.github.io/governance/governing-documents/charter.html) and tried to follow a similar pattern. Hence, defining criteria for inactive projects, inactive maintainers, the number of contributors in sub-projects, the number of maintainers, the number of lines of code, and similar aspects would not be mentioned in the charter. We will have to decide these on a case-by-case basis.
@cendhu thanks, I think we are converging, though, would you agree to define the archiving procedure for the inactive project? Currently, there's no mechanism to remove inactive or abandoned Sub-Projects from voting eligibility, allowing dead projects to maintain voting power indefinitely.
@C0rWin @denyeart @manish-sethi @tock-ibm @yacovm @andrew-coleman @bestbeforetoday @pfi79 @satota2 @ale-linux
A charter should not be overly specific or restrictive. I have read the LFDT charter (https://lf-decentralized-trust.github.io/governance/governing-documents/charter.html) and tried to follow a similar pattern. Hence, defining criteria for inactive projects, inactive maintainers, the number of contributors in sub-projects, the number of maintainers, the number of lines of code, and similar aspects would not be mentioned in the charter. We will have to decide these on a case-by-case basis.
I agree, yet, but it least we can make it well-defined without room for interpretation.
Some of the comments here are getting very detailed. My suggestion is to keep the Charter flexible and high-level. Addition of sub-projects and repositories is a rare event and each one is unique. The TSC should have the freedom to make decisions as they see fit.
Some of the comments here are getting very detailed. My suggestion is to keep the Charter flexible and high-level. Addition of sub-projects and repositories is a rare event and each one is unique. The TSC should have the freedom to make decisions as they see fit.
I completely agree with this.
Some of the comments here are getting very detailed. My suggestion is to keep the Charter flexible and high-level. Addition of sub-projects and repositories is a rare event and each one is unique. The TSC should have the freedom to make decisions as they see fit.
Ok, I can see the point where you might introduce some loosely defined claims open to interpretation, while I do not think this should remain too open or vague. I believe I will be fine if we can agree at very least on the following:
- Decision-Making on Significant Ecosystem-Wide Matters: Decisions on significant ecosystem-wide matters shall require approval from a simple majority of the distinct Maintainer groups of currently recognized and active Sub-Projects. The process is as follows:
and to make a super majority-based decision.
Just an observation but if the new charter is agreed, it should probably move to a new location, rather than live in one of the specific implementation projects. Is https://github.com/hyperledger/governance/tree/main/project-charters the right place? Alternatively, maybe the Fabric expansion would make it worth creating a new "LFDT-Fabric" organisation, with an associated "governance" repo?
I agree with the updates in general and will therefore approve. Charter updates will need to be reviewed by LFDT, and when they do that it will be interesting to see if they can point to other projects with similar sub-project structures for comparison.
Some of the comments here are getting very detailed. My suggestion is to keep the Charter flexible and high-level. Addition of sub-projects and repositories is a rare event and each one is unique. The TSC should have the freedom to make decisions as they see fit.
Ok, I can see the point where you might introduce some loosely defined claims open to interpretation, while I do not think this should remain too open or vague. I believe I will be fine if we can agree at very least on the following:
- Decision-Making on Significant Ecosystem-Wide Matters: Decisions on significant ecosystem-wide matters shall require approval from a simple majority of the distinct Maintainer groups of currently recognized and active Sub-Projects. The process is as follows:
and to make a super majority-based decision.
For the parent Hyperledger/LFDT organization, the addition of new projects has always required a simple majority of TOC. It seems following their precedent of simple majority would make sense.
Just an observation but if the new charter is agreed, it should probably move to a new location, rather than live in one of the specific implementation projects. Is https://github.com/hyperledger/governance/tree/main/project-charters the right place? Alternatively, maybe the Fabric expansion would make it worth creating a new "LFDT-Fabric" organisation, with an associated "governance" repo?
Yeah, there will be many considerations such as this, let's see if LFDT can provide any guidance.
@denyeart @bestbeforetoday Thank you for the detailed reviews. Based on your comments, I realised that TSC formation and the voting process were confusing part. Hence, I have rewritten both of them to make it clear. Further, I have address a other comments too.
While I understand the precedent of simple majority in parent organizations, the unique Sub-Project structure here creates different risk dynamics that warrant consideration. However, I recognize the value of proceeding with appropriate oversight.
I will reserve my final vote pending:
- LFDT review and official position on both this charter amendment and the associated RFC64 "Fabric Ecosystem Coexistence Model"
- LFDT's assessment of the governance model's alignment with broader Hyperledger ecosystem practices
The proposed structure still allows for potential ecosystem manipulation through Sub-Project proliferation, where:
- Each Sub-Project, regardless of scope, contributors, or strategic importance, receives equal voting power
- New Sub-Projects require only simple majority approval, creating a recursive approval mechanism
- No clear safeguards exist against coordinated groups creating multiple minimal projects to gain voting control
The charter co-written with the LFDT legal team has been pushed. Note that this charter will become applicable once we have an approved list of sub-projects.
Therefore, the rules in the existing charter will be followed to accept the first sub-project. After that, a chair will be selected for each new sub-project. Please read the updated charter for more details. We will then update the GOVERNANCE.MD file as specified in the charter.
We expect a few more edits from the LFDT legal team on this charter. Importantly, this charter is no longer a blocker for two existing RFCs, and LFDT has no objection to hosting Fabric-X as a sub-project within the Fabric ecosystem.
Final amendments to the charter are complete. This document was rewritten in collaboration with the LFDT legal team, and we have secured their approval. The revision was required because the legal team identified several portions as being confusing, unclear, and overly complex.
@C0rWin @denyeart @bestbeforetoday @manish-sethi @yacovm @tock-ibm @satota2 @pfi79 @andrew-coleman @ale-linux
Please review the changes.
This document now describes the Ecosystem technical charter, and states that each sub-project has its own TSC and technical charter. However, this document replaces the existing Fabric (sub-project) technical charter. Perhaps this should be renamed something like
Hyperledger_Fabric_Ecosystem_Charter.mdand leave the existingHyperledger_Fabric_Technical_Charter.mdintact?
This document covers both the ecosystem and sub-project level committee. Please refer to section 3. Technical Steering Committees and section 4. ESC/TSC Voting. However, what is missing is the GOVERNANCE.md which would hold the TSC member list from each sub-project. I will add that now.
This document covers both the ecosystem and sub-project level committee. Please refer to section
3. Technical Steering Committeesand section4. ESC/TSC Voting. However, what is missing is theGOVERNANCE.mdwhich would hold the TSC member list from each sub-project. I will add that now.
OK, that makes sense to me. In addition to the GOVERNANCE.md file, perhaps this change should include an update to the Fabric MAINTAINERS.md to retain the Fabric (sub-project) TSC membership information that was previously included in this charter.
Hi @C0rWin
The current version is a major revision that was done under the supervision and guidance of the LFDT team. I believe your comments were on the previous version. This version, I believe, addresses most of your concerns. Please review and consider removing your request for change.
The super majority on this version of the PR, and the lack of new comments in the last two weeks, indicates that we are ready to move on.
Thanks
