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: 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, and historical transaction data is stored in both the blockchain and MySQL database.
- NoSQL: A CouchDB database stores transaction 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 organizations can be dynamically added to a BCS service to avoid impact of insufficient peer organizations configured during service deployment.
Auto Scaling of Nodes
Peers 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.
Privacy is ensured within a channel because different members in a channel can have different access permissions. For example, member A can have the permissions to access certain data, but member B, who does not have relevant permissions, cannot access the specified data.
This is different from the privacy ensured through channel isolation because a channel isolates data for members in the channel.
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.
Inter-Blockchain Data Interaction
- Arbitration is introduced for inter-blockchain transaction results. The blockchain data structure is used to manage the inter-blockchain transaction results, ensuring atomicity of the transactions.
- Arbitration nodes only manage the verification results of inter-blockchain transactions and does not touch original transaction data, ensuring independency and security of the transactions.
- Behavior consistency between parties in inter-blockchain transactions is verified, ensuring consistency of the transaction information during distribution (such as in asset transfer).
Currently, only the enterprise and platinum editions support inter-blockchain data interaction. To use this function, submit a service ticket to the customer service.