Hyperledger Fabric 0.6/1.0/1.1版本差异及0.6至1.1迭代核心技术咨询

Great question! Let’s dive into the key differences between Hyperledger Fabric 0.6, 1.0, and 1.1, plus the core goals, critical updates, and architectural shifts you’ll encounter when upgrading from 0.6 to 1.1.

0.6 vs. 1.0: The Monolith to Modularity Shift #

• Core Architecture: 0.6 was a tight, monolithic design where all core components (orderer, peer, membership services) ran in a single process. This made scaling and customizing the network a real challenge. 1.0 completely reworked this into a modular architecture with distinct, independent services—Orderer, Peer, Membership Service Provider (MSP), and Certificate Authority (CA)—letting you scale each service separately and adapt the network to enterprise needs.
• Chaincode Execution: In 0.6, chaincode ran directly within the peer process, offering little isolation between smart contracts. 1.0 introduced Docker containerized chaincode execution, where each chaincode runs in its own sandbox. This boosts security (a compromised chaincode can’t take down the peer) and resource management.
• Consensus Options: 0.6 only supported PBFT (Practical Byzantine Fault Tolerance), which is great for trustless environments but not ideal for simpler, permissioned networks. 1.0 added pluggable consensus: Solo (for testing), Kafka-based ordering, and laid the groundwork for Raft in 1.1. This lets you pick the right consensus model for your network’s trust and performance requirements.
• Identity Management: 0.6 had a basic membership service with limited access control. 1.0 formalized MSPs, which enable fine-grained access control and support for external Certificate Authorities—critical for enterprise-grade identity management and compliance.

1.0 vs. 1.1: Polishing for Production #

• Raft Consensus: The biggest addition in 1.1 was the Raft consensus protocol as a production-ready alternative to Kafka. Raft is simpler to operate (no need for a separate Kafka/ZooKeeper cluster) and provides crash fault tolerance with strong consistency, making it perfect for smaller to medium-sized permissioned networks.
• Private Data Collections: A game-changer for enterprise use cases—this feature lets subsets of network participants share sensitive data without exposing it to the entire network. It solves a major privacy pain point that 1.0 couldn’t address natively.
• Chaincode Lifecycle Improvements: 1.0 had a bare-bones lifecycle (install, instantiate). 1.1 added chaincode package signing and a structured workflow (package → install → approve → commit), giving organizations full control over who can deploy chaincode and ensuring the integrity of deployed smart contracts.
• Performance Boosts: 1.1 included optimizations like parallel transaction validation, more efficient gossip protocol for peer-to-peer communication, and reduced commit latency. These changes significantly improved network throughput and responsiveness.

Core Goals of Source Code Modifications #

When moving from 0.6 to 1.1, the core goals driving code changes were:

• Modularity & Scalability: Break down the monolithic codebase into independent services to support larger, more distributed networks that can grow with enterprise needs.
• Security Hardening: Isolate chaincode execution, formalize identity management, and add safeguards like chaincode signing to mitigate security risks inherent in 0.6’s tight coupling.
• Enterprise Readiness: Add features that address real-world enterprise requirements—private data, flexible consensus, and robust chaincode lifecycle management—to make Fabric suitable for production deployments.
• Maintainability & Extensibility: Refactor code to be more modular, making it easier to add new features (like Raft) and maintain existing components without breaking the entire network.

Most Critical Update Logs #

0.6 → 1.0 #

• Split the monolithic process into distinct Orderer, Peer, MSP, and CA services.
• Introduced Dockerized chaincode execution with sandbox isolation.
• Added pluggable consensus frameworks (Solo, Kafka).
• Formalized MSP for identity and access control.

1.0 → 1.1 #

• Added production-ready Raft consensus protocol.
• Implemented private data collections for subset data sharing.
• Enhanced chaincode lifecycle with package signing and multi-organization approval workflows.
• Optimized transaction validation, gossip protocol, and commit latency for better performance.

Architectural Shifts #

• Service Decoupling: The most dramatic shift from 0.6 to 1.0 was moving from a single binary to separate services. Each service can be scaled independently, and organizations can run their own peers while participating in a shared orderer network (or host their own orderers). This required a complete rewrite of core component interactions.
• Chaincode Execution Overhaul: 0.6 ran chaincode directly in the peer process; 1.0+ uses Docker containers for each chaincode. This meant rewriting the peer’s chaincode management logic to handle container orchestration, deployment, and communication between peers and chaincode containers.
• Consensus Layer Refactoring: 0.6’s hardcoded PBFT was replaced with a pluggable consensus framework in 1.0. This allowed the addition of Raft in 1.1 without rewriting the entire orderer service, making future consensus updates much easier.
• Identity as a Core Component: MSPs became a foundational part of the network in 1.0, replacing 0.6’s basic membership service. This required changes across all services to enforce MSP-based access control for transactions, chaincode operations, and network administration.

内容的提问来源于stack exchange，提问作者Jim Green