Fablo

Fablo includes several end-to-end test cases that demonstrate different Hyperledger Fabric network configurations. These test cases vary by Fabric version, deployment engine (Docker or Kubernetes), consensus mechanism (Solo, RAFT, or BFT), and specific features like Private Data or TLS. Use these configurations as templates for understanding how Fablo handles different network topologies and capabilities.

| Test case | 01-v2-simple | 02-v2-raft-2orgs | 03-v2-private-data | 04-v2-snapshot | test-05-v3 | test-06-v3-bft | k8s-01-simple |
| :--- | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| Fabric versions | 2.5.12 | 2.4.3 | 2.5.12 | 2.5.12 | 3.1.0 | 3.1.0 | 2.4.7 |
| Engine | Docker | Docker | Docker | Docker | Docker | Docker | Kubernetes |
| TLS | no | yes | no | yes | yes | yes | yes |
| Channel capabilities | v2 | v2 | v2_5 | v2 | v3_0 | v3_0 | v2 |
| Consensus | solo | RAFT | solo | RAFT | RAFT | BFT | RAFT |
| Orderer nodes | 1 | 3 | 1 | 1 | 3 | 4 | 1 |
| Organizations | 1 | 2 | 2 | 1 | 1 | 1 | 1 |
| CA database | SQLite | SQLite | SQLite | Postgres | SQLite | SQLite | - |
| Peer database | LevelDB | LevelDB | LevelDB | CouchDB | LevelDB | LevelDB | LevelDB |
| Peer count | 2 | 2, 2 | 2, 1 | 2 | 2 | 2 | 2 |
| Channels | 1 | 2 | 1 | 1 | 1 | 1 | 1 |
| Node chaincode | yes | yes | yes | yes | yes | yes | yes, CCaaS |
| Node chaincode upgrade | no | yes | no | no | no | no | no |
| Node chaincode endorsement | OR | OR | OR, AND | default | OR | OR | default |
| Private data | no | no | yes | yes | no | no | no |
| Java chaincode | no | yes | no | no | no | no | no |
| Go chaincode | no | no | yes | no | yes | no | no |
| Tools | channel scripts | Fablo REST | - | Fablo REST, Explorer | - | - | fabricopsctl |
| Other Fablo commands | init, reset | stop, start | - | snapshot, prune, restore | - | - | - |

The CCaaS (Chaincode as a Service) approach allows for hot reloading while maintaining container isolation. This is compatible with both TLS and non-TLS setups.

How it works: You use the ccaas chaincode type and configure chaincodeMountPath and chaincodeStartCommand. This mounts your local source code into a CCaaS container, allowing the process inside the container to restart when the mounted code changes.

Benefits:

• Supports both TLS and non-TLS.
• Granular control: only specific chaincodes need to be in hot-reload mode.
• Fablo manages the lifecycle of the CCaaS processes.

// Example CCaaS configuration in fablo-config.json
{
  "name": "chaincode1",
  "version": "0.0.1",
  "channel": "my-channel1",
  "lang": "ccaas",
  "image": "hyperledger/fabric-nodeenv:${FABRIC_NODEENV_VERSION:-2.5}",
  "chaincodeMountPath": "$CHAINCODES_BASE_DIR/chaincodes/chaincode-kv-node",
  "chaincodeStartCommand": "npm run start:watch:ccaas",
  "privateData": []
}

The Fablo configuration is a single JSON or YAML file that defines the Hyperledger Fabric network topology, including network settings, CAs, orderers, organizations, peers, channels, and chaincodes.

To ensure correctness, the config must be compatible with the project's schema. You can validate your configuration using the fablo validate command. You can also generate a basic starting configuration using the ./fablo init command.

The top-level structure consists of four main sections:

• global: Network-wide settings.
• orgs: Definitions for organizations, peers, and orderers.
• channels: Channel definitions and membership.
• chaincodes: Chaincode definitions and deployment settings.

{
  "$schema": "https://github.com/hyperledger-labs/fablo/releases/download/2.6.0/schema.json",
  "global": { ... },
  "orgs": [ ... ],
  "channels": [ ... ],
  "chaincodes": [ ... ]
}

Peer dev mode allows you to run the chaincode process locally on your machine instead of inside a container, speeding up the development cycle.

Requirements & Setup:

1. In fablo-config.json, set global.peerDevMode to true and global.tls to false.
2. Run fablo up. Fablo will approve and commit chaincode definitions but will not start the chaincode containers.
3. Start the chaincode process manually on your local machine.

Trade-offs:

• Pros: Simpler setup; runs locally.
• Cons: Non-TLS only; configuration is global per network; you must start a separate process for every peer you wish to use.

Language Specifics:

• Node.js: Install dependencies and use a watcher (like nodemon) to restart the process on code changes.
• Java: Build using Gradle (shadowJar) and run a local script (like run-dev.sh) that maps to the peer's host port.

# Node.js example: Install and start with watch mode
(cd chaincodes/chaincode-kv-node && nvm use && npm i && npm run start:watch)