Skip to content

identify high priority issue in fabric codebase #257

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.

Sign up for GitHub

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

Open
sahildando wants to merge 3 commits into
base: main
Choose a base branch
from
Open

identify high priority issue in fabric codebase #257

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
214898a
docs: fix README typos and naming consistency
sahildando Apr 12, 2026
1281320
Merge pull request #1 from sahildando/task-title
sahildando Apr 12, 2026
f608d1e
fix(v1): handle MarkFlagRequired errors in flag binding
sahildando May 7, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 9 additions & 9 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,9 +5,9 @@ SPDX-License-Identifier: Apache-2.0

## Motivation

The adoption of Distributed Ledger Technology (DLT) for critical financial infrastructures like digital assets and currencies (e.g., Central Bank Digital Currencies (CBDCs) , stablecoins, tokenized deposits, tokenized bonds/sercurities) is hindered by a significant performance gap. Permissioned blockchains such as Hyperledger Fabric, while conceptually suitable, are limited by architectural bottlenecks in their monolithic peer design and consensus mechanisms, preventing them from achieving the required scale.
The adoption of Distributed Ledger Technology (DLT) for critical financial infrastructures like digital assets and currencies (e.g., Central Bank Digital Currencies (CBDCs) , stablecoins, tokenized deposits, tokenized bonds/securities) is hindered by a significant performance gap. Permissioned blockchains such as Hyperledger Fabric, while conceptually suitable, are limited by architectural bottlenecks in their monolithic peer design and consensus mechanisms, preventing them from achieving the required scale.

`Fabric-X` represents a fundamental re-archicture of [Hyperledger Fabric](https://github.com/hyperledger/fabric) that addresses these challenges end-to-end. The monolithic peer is decompossed into independently scalable microservices for endorsement, validation, and committing. To maximize parallelism, a transaction dependency graph was introduced. It enables safe, concurrent validation of transactions across multiple blocks. Complementing the peer redesign, we have introduced Arma, a novel sharded Byzantine Fault Tolerant (BFT) ordering service that dramatically increases throughput by ordering compact transaction digests rather than full transaction payloads. We have implemented and benchmarked this framework with a UTXO-based CBDC application. Our evaluation demonstrates a peak throughput exceeding 200,000 transactions per second (TPS) — two-orders-of-magnitude improvement over the standard implementation.
`Fabric-X` represents a fundamental re-architecture of [Hyperledger Fabric](https://github.com/hyperledger/fabric) that addresses these challenges end-to-end. The monolithic peer is decomposed into independently scalable microservices for endorsement, validation, and committing. To maximize parallelism, a transaction dependency graph was introduced. It enables safe, concurrent validation of transactions across multiple blocks. Complementing the peer redesign, we have introduced Arma, a novel sharded Byzantine Fault Tolerant (BFT) ordering service that dramatically increases throughput by ordering compact transaction digests rather than full transaction payloads. We have implemented and benchmarked this framework with a UTXO-based CBDC application. Our evaluation demonstrates a peak throughput exceeding 200,000 transactions per second (TPS) — two-orders-of-magnitude improvement over the standard implementation.

Fabric-X proves that permissioned DLTs can be engineered for national-scale payment systems, providing a resilient and highly performant foundation for practical digital assets and currencies deployments and the integration of advanced, computationally intensive features.

Expand All @@ -18,7 +18,7 @@ Figure below shows the high-level architecture differences between `Fabric Class

![Fabric Classic vs Fabric-X](./diagrams/Fabric_vs_Fabric-X.png)

Before we dive deep into the **differences**, we we would like to emphasize **similarities**:
Before we dive deep into the **differences**, we would like to emphasize **similarities**:

**Similarities**
1. **Transaction lifecycle** - "Execute - Order - Validate"
Expand All @@ -27,7 +27,7 @@ Before we dive deep into the **differences**, we we would like to emphasize **si
4. **Membership service provider** - is Fabric-cryptogen and Fabric-CA compatible
5. **Consensus type and API** - ordering cluster provides BFT guarantees and offers same broadcast block GRPC API

**Differencies**
**Differences**
1. **Programming model** - classical Fabric primarily uses chaincodes to simulate transaction execution. In Fabric-X, we replace chaincodes with peer-to-peer transaction negotiation protocols built on [Fabric-Smart-Client](https://github.com/hyperledger-labs/fabric-smart-client) and [Fabric-Token-SDK](https://github.com/hyperledger-labs/fabric-token-sdk). This shift enables interactive protocols between participants, aligning with patterns already present in legacy systems.
2. **Peer decomposition** - in classical Fabric, peers handle transaction validation, commitment, and notification, among other responsibilities. This monolithic architecture limits scalability, especially when certain components become bottlenecks. In Fabric-X, we decompose the peer by offloading validation, commitment, and notification into independent, scalable microservices.
3. **Ordering service** - classical Fabric offers the following ordering service implementations: SmartBFT and RAFT. We propose an implementation based on [Arma protocol](https://arxiv.org/abs/2405.16575) a high performance distributed BFT consensus.
Expand Down Expand Up @@ -57,7 +57,7 @@ Code and more details can be found under [Fabric-X-Orderer Github repository](ht

### Fabric-X-Committer

Fabric-X-Commiter is responsible for post-ordering transaction processing. It has a microservice architecture comprised of the following subcomponents: sidecar, coordinator, validator-committer, verification service, query service.
Fabric-X-Committer is responsible for post-ordering transaction processing. It has a microservice architecture comprised of the following subcomponents: sidecar, coordinator, validator-committer, verification service, query service.

- **Sidecar** is a middleware component designed to operate between an Ordering Service and the Coordinator component. Its primary function is to reliably manage the flow of blocks, ensuring they are fetched, validated, persisted, and delivered to downstream clients.
- **Coordinator** service acts as the central orchestrator of the transaction validation and commit pipeline. It sits between the Sidecar and a collection of specialized verification, validation and commit services. Its primary role is to manage the complex flow of transactions, from initial receipt to final status reporting, by leveraging a transaction dependency graph to maximize parallel processing while ensuring deterministic outcomes.
Expand All @@ -67,7 +67,7 @@ Fabric-X-Commiter is responsible for post-ordering transaction processing. It ha

Figure below demonstrates the Fabric-X-Committer architecture.

![Fabric-X-Commiter architecture](./diagrams/Fabric-X-Committer.png)
![Fabric-X-Committer architecture](./diagrams/Fabric-X-Committer.png)

Code and more details can be found under [Fabric-X-Committer Github repository](https://github.com/hyperledger/fabric-x-committer).

Expand All @@ -77,7 +77,7 @@ To set up the network yourself, follow the tutorial in the [sample deployment sc

### Version compatibility matrix

| Orderer | Commiter | Ansible collection | Fabric CA | Fabric Smart Client | Sample Application |
| Orderer | Committer | Ansible collection | Fabric CA | Fabric Smart Client | Sample Application |
| :----: | :----: | :----: | :----: | :----: | :----: |
| v0.0.21 | v0.1.7 | v0.5.5 | v1.5.15 | v0.8.2 | v0.0.8 |

Expand All @@ -95,11 +95,11 @@ To set up the network yourself, follow the tutorial in the [sample deployment sc
- [Sample token application](https://github.com/iliecirciumaru/fabric-x/tree/main/samples/tokens)
- [Fabric/Fabric-X monthly calls on the 3rd Wed of the month](https://zoom-lfx.platform.linuxfoundation.org/meetings/fabric?view=month)
- [Fabric-X Blog](https://www.lfdecentralizedtrust.org/blog/new-major-contribution-to-hyperledger-fabric-purpose-built-implementation-for-next-gen-digital-assets)
- [Fabric-X whitepaper](https://eprint.iacr.org/2023/1717.pdf) - detailed description of the Fabric-X. Explains motivation,implementation details and presents performance benchmarks
- [Fabric-X whitepaper](https://eprint.iacr.org/2023/1717.pdf) - detailed description of the Fabric-X. Explains motivation, implementation details and presents performance benchmarks
- [Fabric-X Committer](https://github.com/hyperledger/fabric-x-committer) Github repository
- [Fabric-X Orderer](https://github.com/hyperledger/fabric-x-orderer) Github repository
- [Fabric-Token-SDK](https://github.com/hyperledger-labs/fabric-token-sdk) and [Fabric-Smart-Client](https://github.com/hyperledger-labs/fabric-smart-client) Github repositories
- [Fabrix-X Common](https://github.com/hyperledger/fabric-x-common) Github repository - contains new CLIs and protobuf, and code shared between the orderer and committer
- [Fabric-X Common](https://github.com/hyperledger/fabric-x-common) Github repository - contains new CLIs and protobuf, and code shared between the orderer and committer
- [Sample deployment scripts](https://github.com/LF-Decentralized-Trust-labs/fabric-x-ansible-collection)
- [Fabric-X Client SDK](https://github.com/hyperledger/fabric-x-sdk/)
- [Fabric-X EVM](https://github.com/hyperledger/fabric-x-evm)
Expand Down
8 changes: 6 additions & 2 deletions tools/fxconfig/internal/cli/v1/flags.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,9 @@ type policyFlag string
func (f *policyFlag) bind(cmd *cobra.Command) {
cmd.Flags().StringVar((*string)(f), "policy", "",
"Endorsement policy (e.g., \"OR('Org1MSP.member')\" or \"AND('Org1MSP.member', 'Org2MSP.member')\")")
_ = cmd.MarkFlagRequired("policy")
if err := cmd.MarkFlagRequired("policy"); err != nil {
panic(err)
}
}

// versionFlag represents a namespace version number flag.
Expand All @@ -29,7 +31,9 @@ type versionFlag int
func (f *versionFlag) bind(cmd *cobra.Command) {
cmd.Flags().IntVar((*int)(f), "version", 0,
"Current namespace version (required for updates to prevent conflicts)")
_ = cmd.MarkFlagRequired("version")
if err := cmd.MarkFlagRequired("version"); err != nil {
panic(err)
}
}

// namespaceDeployFlags groups flags for namespace deployment operations.
Expand Down