🧪 Hyperledger Fabric Core Components and Transaction Flow (Experimental Setup)

[apierr]

📦 Container Status

The experimental environment consists of two active Docker containers, corresponding to the core Hyperledger Fabric components:

docker ps

• Orderer container (orderer.example.com)
• Peer container (peer0.org1.example.com)

Both containers are running correctly, indicating that the basic Fabric network is operational and ready for transaction processing experiments.

---

🔷 Orderer Node (orderer.example.com)

🎯 Primary Role: Transaction Ordering and Consensus

The orderer is responsible for ensuring a globally consistent transaction order across the network. Its main functions include:

• ✅ Collecting endorsed transactions from peers
• ✅ Establishing a total order of transactions
• ✅ Packaging ordered transactions into blocks
• ✅ Disseminating blocks to all peers
• ❌ Not executing smart contracts
• ❌ Not validating transaction semantics

The orderer enforces agreement on transaction sequence, not on transaction correctness.

📌 Conceptually, the orderer can be viewed as a synchronization and coordination component that guarantees deterministic ordering.

---

🔷 Peer Node (peer0.org1.example.com)

🎯 Primary Role: Execution, Validation, and Ledger Maintenance

The peer node performs all computation and state management tasks:

• ✅ Executes smart contracts (chaincode)
• ✅ Simulates transactions and produces endorsements
• ✅ Validates transactions against endorsement and validation policies
• ✅ Maintains a local copy of the distributed ledger
• ✅ Cryptographically signs endorsements

Peers are therefore responsible for both computation and data persistence within the blockchain system.

📌 From a functional perspective, the peer acts as both an execution engine and a ledger authority.

---

🔄 Transaction Processing Workflow

The end-to-end transaction lifecycle follows a well-defined sequence:

1. Client → Peer: Transaction proposal submission
   ↓
2. Peer: Chaincode execution and endorsement (ECDSA signature)
   ↓
3. Client → Orderer: Submission of endorsed transaction
   ↓
4. Orderer: Ordering transactions and block creation
   ↓
5. Orderer → Peers: Block dissemination
   ↓
6. Peer: Transaction validation within the block
   ↓
7. Peer: Commitment of valid transactions to the ledger

This separation of responsibilities enables modularity and scalability, while preserving consistency.

---

⚖️ Validation Responsibilities Clarified

The Fabric architecture does not implement a simple “validator vs node” dichotomy. Instead, validation is distributed across components:

Component	Validation Scope	Description
Peer	Transaction validity	Executes chaincode, verifies ECDSA signatures, enforces policies
Orderer	Transaction ordering	Ensures global agreement on sequence, not on content

This design decouples consensus on order from validation of correctness.

---

🔐 Cryptographic Foundations (ECDSA)

Elliptic Curve Digital Signature Algorithm (ECDSA, P-256) is used throughout the system:

• 🔑 Peers sign transaction endorsements
• 🔑 Orderers sign blocks
• 🔑 Clients verify endorsements and block signatures

ECDSA provides authentication, integrity, and non-repudiation across all protocol phases.

---

🏗️ Architectural Context

A simplified architectural view of the deployment is shown below:

┌─────────────────┐
│     Orderer     │  ← Transaction ordering (consensus)
│   (ECDSA sigs)  │
└────────┬────────┘
         │
    ┌────┴─────┐
    │          │
┌───▼───┐  ┌───▼───┐
│ Peer0 │  │ Peer1 │  ← Execution, validation, ledger
│ Org1  │  │ Org2  │     (ECDSA endorsements)
└───────┘  └───────┘

In production-grade deployments, this architecture is typically extended with:

• Multiple orderer nodes for fault tolerance
• Multiple peers per organization for redundancy and load distribution

---

📝 Notes for Paper Integration

• This document serves as a conceptual and architectural reference

• It can be refined into:

  • System Model
  • Experimental Setup
  • Background / Preliminaries sections

• Terminology and structure are aligned with academic blockchain literature

---

If you want, next steps could include:

• ✍️ Conversion into a formal LaTeX paper section
• 📊 Linking this architecture to performance and scalability experiments
• 🔬 Adding threat model or cryptographic assumptions

Just tell me how you want to proceed.