Help Center > > Service Overview> Functions


Updated at: Jun 19, 2019 GMT+08:00

BCS provides the following functions to help you quickly deploy blockchains featuring security, high efficiency, and cost-effectiveness.

Service Deployment

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.

Ledger Storage

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.

Consensus Algorithms

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.

Chaincode Management

You can manage chaincodes on the graphical user interface (GUI) throughout the entire chaincode lifecycle, including coding, debugging, installation, and instantiation.

Blockchain Browser

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.

Application Access

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.

Did you find this page helpful?

Submit successfully!

Thank you for your feedback. Your feedback helps make our documentation better.

Failed to submit the feedback. Please try again later.

Which of the following issues have you encountered?

Please complete at least one feedback item.

Content most length 200 character

Content is empty.

OK Cancel