Blockchain 19 min read

Ctrip Blockchain Service Platform (CBaaS): Architecture, Fabric Design, and Enterprise Adoption

The article presents Ctrip’s Blockchain Service Platform (CBaaS), detailing its motivation, architecture, and the advantages of using Hyperledger Fabric’s modular design—including contract execution, consensus, permission control, and multi‑chain capabilities—to simplify enterprise blockchain adoption and enable secure, data‑rich on‑chain applications.

Ctrip Technology
Ctrip Technology
Ctrip Technology
Ctrip Blockchain Service Platform (CBaaS): Architecture, Fabric Design, and Enterprise Adoption

Author Biography He Xinming, blockchain technology expert at Ctrip Technology Center Innovation R&D Department, leads the Ctrip blockchain technology platform and is proficient in mainstream open‑source blockchain frameworks.

1. What to Do Before Applying Blockchain in Business?

A Gartner 2018 survey shows that while about 66% of enterprises are interested in blockchain, only ~1% have actually deployed it in production, mainly due to low usability, high development/deployment/operation costs, fragmented frameworks, and lack of implementation experience.

To lower these barriers, Ctrip built a blockchain service platform that abstracts network architecture, framework setup, application integration, and monitoring, providing optimized source code, environments, and usage patterns so business teams can adopt blockchain without deep knowledge of Fabric or Ethereum.

2. Ctrip Blockchain Service Platform (CBaaS) Overview

The platform’s technology stack (see image below) relies heavily on container orchestration (Swarm/K8s) for deploying Fabric and other chain frameworks. It functions as a full‑stack application operating system, integrating development, release, testing, runtime, and operations, and therefore requires flexible PaaS support.

The platform initially supports Hyperledger Fabric as the primary consortium chain, followed by Ethereum for incentive‑driven community applications, and Ctrip’s own CtripChain for future needs.

Fabric’s source code has been extended via a plugin layer (e.g., national cryptography algorithms, PBFT consensus) to enable custom functionality.

3. Choosing a Consortium Chain: Hyperledger Fabric Architecture and Design Philosophy

Fabric’s modular architecture (see image below) includes client SDK, P2P network, consensus engine, smart‑contract execution engine, ledger, and a rich permission system.

3.1 Decoupling the Contract Execution Engine

Unlike Ethereum’s monolithic EVM, Fabric defines a container interface with implementations such as DockerVM, InprocVM, and MockVM, allowing smart‑contract execution to run inside Docker containers and enabling alternative engines (e.g., JVM) via the same interface.

Communication between DockerVM and the peer node uses gRPC, further separating execution from the core node code.

3.2 Decoupling Chaincode Logic

Fabric treats many core processes (endorsement, validation, lifecycle management) as system chaincodes, making them configurable and subject to consensus policies, which enhances flexibility compared to fixed‑function designs.

3.3 Decoupling the Consensus Engine

Fabric separates ordering (transaction sorting) from endorsement (pre‑execution). The ordering service implements a consenter interface, allowing custom consensus algorithms, while endorsement logic resides in system chaincodes that can be swapped.

3.4 Decoupling Permission Control

Fabric’s permission model mirrors enterprise multi‑tenant software: the top‑level MSP represents an organization, under which users and peers have roles (admin, member, peer). Access control lists (ACLs) map identities to resources, and the fabric‑ca component provides PKI‑based identity management.

3.5 Multi‑Chain and Cross‑Chain Design

Fabric introduces the concept of channels, each acting as an isolated ledger (similar to a side‑chain). While channels share ordering nodes, cross‑channel communication is achieved via chaincode calls on common peers; full independent cross‑chain data transfer is not yet supported.

4. Storing Raw Data On‑Chain with Fabric

The article presents a solution where raw (non‑hashed) business data is stored directly on Fabric channels, enabling authorized parties to retrieve precise data without off‑chain leakage. The approach is illustrated with a multi‑party trade scenario, showing how channel isolation and ACLs enforce privacy while preserving auditability.

The solution demonstrates that all transaction steps can be fully on‑chain, eliminating off‑chain processes and providing a trustworthy “data‑as‑trust” machine for financial and other sensitive domains.

Conclusion

By abstracting low‑level blockchain complexities, providing modular, extensible components, and supporting multi‑tenant governance, Ctrip’s CBaaS aims to move blockchain technology out of experimental labs into practical, production‑grade enterprise applications.

Blockchainsmart contractsdistributed ledgerconsortium chainHyperledger FabricCtripCBaaS
Ctrip Technology
Written by

Ctrip Technology

Official Ctrip Technology account, sharing and discussing growth.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.