Fabric transaction cycle

Hyperledger Fabric Transaction Lifecycle

Identity and Membership Setup

The transaction lifecycle in Hyperledger Fabric begins with identity management through X.509 certificates issued by a Certificate Authority (CA). Each network participant - whether an organization, peer node, or user - receives a unique digital identity. These identities are managed through Membership Service Providers (MSPs), which define the rules for authentication and authorization within each organization. The MSP contains cryptographic materials including CA certificates, admin certificates, and node-specific signing keys that enable secure participation in the network.

Network Architecture Components

Fabric's modular architecture consists of several key components working together. Organizations join the network with their own peers (which maintain the ledger), CAs (for identity management), and client applications. The ordering service (comprised of orderer nodes) forms the backbone of the network, responsible for creating the immutable sequence of transactions blocks. This separation of concerns between execution (peers), ordering (orderers), and identity (CAs) provides Fabric with its flexible and scalable architecture.

Chaincode Development Process

Smart contracts in Fabric, called chaincode, contain the business logic that governs transactions. Developers write chaincode in general-purpose languages like Go or JavaScript, defining functions that interact with the ledger state. The chaincode specifies how assets are created, modified, or queried, with functions like InitLedger for initialization and custom functions like TransferAsset for business operations. Chaincode is versioned and can be upgraded without losing the existing ledger state.

Chaincode Deployment Lifecycle

Before execution, chaincode goes through a rigorous four-stage deployment process:

1. Packaging - The code is bundled with its dependencies into a deployable package
2. Installation - The package is installed on all endorsing peers across organizations
3. Approval - Required organizations approve the chaincode definition based on policy
4. Commitment - The chaincode becomes active on the channel after orderer verification

Transaction Endorsement Flow

When a client submits a transaction, it first creates a proposal that is sent to endorsing peers. These peers simulate the transaction by executing the chaincode against their current state, generating a read/write set that shows what would change. The peers then cryptographically sign these results if the simulation meets policy requirements. This endorsement process ensures transactions are validated before being committed to the ledger.

Ordering and Finalization

Endorsed transactions are sent to ordering service nodes, which:

• Gather transactions from across the network
• Arrange them into blocks
• Establish the definitive order of transactions
• Distribute blocks to all peers

Peers then validate each transaction in the block against endorsement policies and current state before appending it to their copy of the ledger and updating the world state.

Advanced Features

Fabric supports sophisticated enterprise requirements through:

• Private Data Collections: Enables confidential transactions between specific organizations
• Access Control: Attribute-based rules govern who can invoke chaincode functions
• Versioning: Chaincode can be upgraded while preserving ledger state
• Plugable Components: Supports different consensus mechanisms and databases

Consensus and Finality

Fabric achieves finality through execute-order-validate architecture:

1. Transactions are first executed and endorsed
2. Then ordered into blocks with deterministic sequencing
3. Finally validated against current state before commitment

This three-phase approach provides high throughput while preventing double-spending and other inconsistencies.

World State Management

The ledger maintains two components:

• Blockchain: Immutable sequence of transaction blocks
• World State: Current value database (LevelDB/CouchDB) for efficient queries

This separation allows for efficient access to current values while maintaining complete transaction history.

Security Model

Fabric's security derives from:

• PKI-based identity with certificate revocation
• Configurable endorsement policies
• Channel-based data isolation
• Cryptographic hashing of all transactions
• Byzantine fault tolerant ordering

These features combine to create an enterprise-grade permissioned blockchain suitable for business networks.

Hyperledger Fabric Transaction Lifecycle

1. Identity Creation and MSP Configuration

What is happening? Fabric uses X.509 certificates for identity. These certs are issued by a Certificate Authority (CA) and represent different users, peers, and orderers in the network. Each organization defines a Membership Service Provider (MSP) to manage these identities.

Technical Components:

• MSP folder structure (per org):

msp/
├── cacerts/            # CA root cert
├── keystore/           # Private ECDSA key
├── signcerts/          # X.509 signing cert
├── admincerts/         # Org admins

Layman Explanation: Think of MSP like your "organizational passport system". The CA is like a passport office, and your certificates are digital passports proving who you are in the network.

2. Network Map and Actor Roles

What is happening? Fabric has a modular architecture. Every participant plays a role:

Layman Explanation: Imagine Org1 and Org2 are banks. Each has a "teller" (peer), a "notary" (CA), and a way to validate and store transactions. The orderer is like a shared accountant who logs all entries in a common ledger.

3. Chaincode (Smart Contract) Development

hello.go (written in Go):

type HelloWorldContract struct {
    contractapi.Contract
}
 
type Message struct {
    Text string `json:"text"`
}
 
func (c *HelloWorldContract) InitLedger(ctx contractapi.TransactionContextInterface) error {
    return ctx.GetStub().PutState("message", []byte(`{"text":"Hello Fabric!"}`))
}
 
func (c *HelloWorldContract) UpdateMessage(ctx contractapi.TransactionContextInterface, newMsg string) error {
    msg := Message{Text: newMsg}
    data, _ := json.Marshal(msg)
    return ctx.GetStub().PutState("message", data)
}

Layman Explanation: This is the program logic deployed to the blockchain. It initializes a message and lets users update it.

4. Package, Install, Approve, Commit (Chaincode Lifecycle)

What is happening? Fabric separates chaincode deployment into lifecycle phases.

4.1 Package Chaincode

peer lifecycle chaincode package hello.tar.gz \
  --path ./hello --lang golang --label hello_1

4.2 Install on Peers

peer lifecycle chaincode install hello.tar.gz

4.3 Approve by Each Org

peer lifecycle chaincode approveformyorg ...

4.4 Commit Chaincode Definition

peer lifecycle chaincode commit ...

Layman Explanation: Imagine writing a company policy, getting department heads to sign off (approve), and then publishing it to everyone (commit).

5. Endorsement Policy (Who Must Approve Transactions?)

Examples:

OR('Org1MSP.peer','Org2MSP.peer')  # Allow either org
AND('Org1MSP.peer','Org2MSP.peer') # Require both orgs

Layman Explanation: It's like saying: "For payments, either the manager or finance must sign" vs "Both manager and finance must sign."

6. InitLedger Transaction

peer chaincode invoke -C mychannel -n hello -c '{"function":"InitLedger","Args":[]}' ...

7. Submit UpdateMessage("Goodbye Fabric!")

Proposal Payload:

{
  "txID": "f9d7...",
  "args": ["UpdateMessage", "Goodbye Fabric!"],
  "creator": "user1@Org1MSP",
  "endorsers": ["peer0.org1", "peer0.org2"]
}

8. World State Update

Before:

{"message": {"text": "Hello Fabric!"}}

After:

{"message": {"text": "Goodbye Fabric!"}}

9. Block Structure

Example:

{
  "number": 7,
  "data": {
    "transactions": [
      {
        "txID": "f9d7...",
        "chaincode": "hello",
        "rwSet": {
          "writes": [
            {"key": "message", "value": "{\"text\":\"Goodbye Fabric!\"}"}
          ]
        },
        "status": "VALID"
      }
    ]
  }
}

10. Chaincode Upgrade (v1 → v2)

peer lifecycle chaincode package hello_v2.tar.gz ...
peer lifecycle chaincode install hello_v2.tar.gz
peer lifecycle chaincode approveformyorg --version 2 --sequence 2
peer lifecycle chaincode commit --version 2 --sequence 2 ...

11. Private Data Collection (PDC)

collections_config.json:

[
  {
    "name": "msgCollection",
    "policy": "OR('Org1MSP.member')",
    "requiredPeerCount": 1,
    "maxPeerCount": 2,
    "blockToLive": 100,
    "memberOnlyRead": true
  }
]

12. Access Control via Attributes (ABAC)

Chaincode Example:

val, ok, _ := ctx.GetClientIdentity().GetAttributeValue("role")
if val != "auditor" { return fmt.Errorf("unauthorized") }

Fabric Ledger Internals

Summary Table

Ethereum vs Hyperledger Fabric - Comparison

Technical Comparison Table

Execution Lifecycle Comparison

Summary Insights

• Ethereum offers a globally synchronized, public execution model with gas metering and strong ecosystem tooling. It emphasizes decentralization, programmability, and composability.

• Fabric is a modular enterprise-grade DLT with configurable privacy, endorsement policies, and deterministic execution. It separates simulation from ordering, enabling fine-grained control.