BCS provides the following functions to help you quickly deploy blockchains featuring security, high efficiency, and cost-effectiveness.
You can purchase resources when deploying a blockchain system, without a need to prepare resources required by the system in advance.
- The deployment time is reduced from days to minutes, and the blockchain network configuration is completed during deployment.
- Underlying technological details are masked. You do not need to care about the underlying technology implementation and platform construction.
- You can create a cross-region consortium blockchain or a private blockchain.
Three types of databases are available for ledger storage, that is, file database (goleveldb), relational database (MySQL), and NoSQL (CouchDB).
- File database: The Fabric native storage mode is used. Historical transaction data is stored in the blockchain, and status data is stored in the LevelDB.
- Relational database: Status data is stored in the MySQL database. Historical transaction data is stored in both the blockchain and MySQL database. This allows fast and rich query of relational database and at the same time, ensures data immutability, a feature of Fabric.
- NoSQL: The CouchDB storage mode supported by the Fabric is used to store transaction data and status data.
BCS supports multiple consensus algorithms for diverse scenarios.
- Solo: A simple consensus algorithm. In a Solo ordering service, only one orderer is available. Therefore, Solo does not support fault tolerance but features quick startup and resource saving. It is recommended for testing.
- Fast Byzantine consensus algorithm (FBFT): A highly available consensus algorithm with superb performance. It requires at least four orderers and tolerates faults at a maximum of (N – 1)/3 orderers, where N indicates the total number of orderers. It is recommended for production environment.
- Kafka (crash fault tolerant): A high-speed consensus algorithm, which tolerates crash faults on just under half of all orderers. It is recommended for production environment.
Consortium Member and Organization Management
- A consortium initiator can dynamically invite other tenants to conveniently and quickly set up a consortium blockchain. Peers of each consortium member run in a separate VPC for independent management, ensuring security and controllability.
- Peer organzations can be dynamically added to a BCS service to avoid impact of insufficient peer organizations configured during service deployment.
Auto Scaling of Nodes
Peers and orderers can be scaled out dynamically based on user requirements, which does not require system reboot.
You can manage chaincodes on the graphical user interface (GUI) throughout the entire chaincode lifecycle, including coding, debugging, installation, and instantiation.
You can query blockchain information required for maintenance in the blockchain browser. The information includes the block quantity, transaction quantity, block details, transaction details, performance, and peer statuses.
Applications can access blockchain networks using software development kits (SDKs), Java database connectivity (JDBC), and RESTful APIs.
- SDK configuration files can be downloaded. After simple configuration, an application can be connected to a blockchain network.
- The JDBC API simplifies data query of applications while retaining data immutability of blockchains.
- Applications can invoke chaincodes through the RESTful API. The policy of multi-organization endorsement is supported.
Monitoring and O&M
BCS connects to the monitoring platform to monitor data and resources in real time and generate alarms and notifications when necessary.
- Automated O&M: BCS actively upgrades the underlying blockchain platform and updates patches to seamlessly integrate with the HUAWEI CLOUD O&M system.
- Enterprise-grade monitoring: Multi-dimensional monitoring is performed on clusters 24/7, and user-defined alarms can be reported through multiple channels.