| VMware Blockchain 1.2.0.1 | 06 MAY 2021 | Build 91 Check for additions and updates to these release notes. |
What's in the Release Notes
The release notes cover the following topics:What's New
VMware Blockchain is an enterprise-grade blockchain platform that meets the needs of business-critical multi-party workflows. The VMware Blockchain 1.2.0.1 release includes the following new features and enhancements:
Pruning
High volume settlement transactions occupy a large amount of storage. VMware Blockchain nodes have restricted storage that is not enough to record the entire blockchain history and hence needs to be optimized to cater to relevant key values of the transaction data.
Pruning offers a medium to free up storage in the nodes by deleting stale key values. This process of deleting stale data and securely backing up only key values allows for overall better performance. Pruning is available on both Replica and Client nodes. Replica nodes' pruning windows are configured by the System Operator, while the Client nodes can have their pruning window configured using predefined offset. The DAML execution engine determines the stale key value using the Pruning Service Ledger API endpoint.
Scaling Operations
Support for scaling up deployed node configuration from four nodes to 7 nodes and scaling down from 7 nodes to four nodes. Scaling up allows for better optimization of performance and network space management for new VMware Blockchain nodes. In some instances, the operation also helps improve disaster recovery conditions and fault tolerance. Scaling down allows for the optimization of space by removing unnecessary Replica nodes from the network.
Scaling operations involve assessing the current configuration and the desired configuration-related information. See the Using and Managing VMware Blockchain guide for more implementation details.
View Change Enhancements
The fast path of execution is robust in the presence of intermittent network failures. In a fast path scenario, all is well with a quorum of 3F+1 Replica nodes in agreement. The catching-up process is finely tuned for high efficiency to avoid having Replica nodes connected for an indefinite amount of time.
The fast path of execution is combined in a safe preserving manner with a slow path when up to F Replica nodes cannot participate in the presence of network instabilities. The refactoring of the view change protocol allows the Replica nodes to leave the current view only after a quorum is reached.
Component Versions
The supported domain versions include:
| Domain | Version |
|---|---|
| VMware Blockchain Platform |
1.2.0.1.91 |
| VMware Blockchain Orchestrator |
1.2.0.1.91 |
| DAML SDK |
1.11.1 |
The VMware products and solutions discussed in this document are protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. and its subsidiaries in the United States and other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.
Resolved Issues
- Configured CLIENT_AUTH parameter value is not implemented in the DAML Ledger API
If you change the ClientAuth parameter value to mandatory during the deployment process, the deployed DAML Ledger defaults to the optional value.
- Client node configuration to increase the system performance works with only a single Client node
Workaround: Contact VMware Blockchain support for more information about enhancing Client node configuration performance.
- The --client-auth parameter to enable server-side TLS on the DAML Ledger API is not recognized
The connection to the DAML Ledger API can be either in plain text or encrypted using TLS. By default, the TLS settings require the Client node certificates for mutual TLS (mTLS) authentication. The command line parameter --client-auth to disable Client node authentication is not recognized.
- Storage size might increase without any transactions in the system
With time service, requests are generated every second. All the Replica nodes add seven requests even if there are no transactions in the system.
- The system stops accepting requests after multiple connection resets between TRC and TRS
The TRS gRPC server is allowed 32 threads. After reaching the thread limit, the TRS does not handle any new subscription requests.
You can search the Concord logs for the error message,
"Failed to add update. Consumer too slow".You can search the metrics data for the error message,
vmware.blockchain.concord.trs.stats.gauge, operation="last_sent_block_id" is not changing.
Known Issues
- Upgrade from VMware Blockchain version 1.1 to 1.2 requires special consideration
Upgrade from VMware Blockchain version 1.1 to 1.2 not available.
Workaround: Contact VMware Blockchain support to discuss considerations for an upgrade.
- Concord containers crash after a long-running continuous load
In certain situations during a continuous-running load when using the expression Assert: expression '!isFetching(), Concord containers might exit, causing the Blockchain nodes to be down and out of the quorum.
Workaround: Restart the Concord containers that crashed, wait for the state transfer to complete, and for the Blockchain nodes to rejoin the quorum.
- VMware Blockchain does not support a specific version of the ELK stack
Environment-specific configurations might be required for your default ELK stack settings to ensure that the collected metrics information is accurate.
Workaround: Contact your VMware Blockchain technical specialist for assistance with ELK stack configurations.
- Time across the Replica and Client nodes becomes inaccurate if the NTP service is down or not synchronized
If the NTP service is down or not synchronized, the time across Replica and Client nodes might become inaccurate, leading to data discrepancies or cause errors in the DAML Ledger API.
Workaround: To avoid any DAML Ledger API errors and data discrepancies, you must keep the NTP service up and synchronized to ensure that all the servers running VMware Blockchain reflect the accurate time.
- In rare instances, the Concord containers are unable to start after failing due to metadata inconsistency
Replica nodes might crash, leaving an inconsistent state between blocks and metadata. Replica nodes recover when the mismatch only affects a single block. In workloads when the mismatch spans multiple blocks and block accumulation is disabled, the Replica node fails to start with the following error message in the logs: "Detected more than one block needs to be deleted from the blockchain - unsupported"
Workaround: Complete the following steps:
- Log in to the affected Replica node.
- Run docker concord start to fix the mismatched state.
- Repeat the start process repeats until all the mismatched blocks are fixed.
Every start attempt, the Replica node fixes one mismatched block and exits with an error message. After the last mismatched block is removed, the Replica node starts normally and catches up with the other nodes using state transfer.
- Replica nodes crash during pruning of large data
In certain circumstances, when there are many thin replica clients, there is high activity on the TRS gRPC channel resulting in a memory consumption problem that causes the Replica nodes to crash during the pruning operation.
Workaround: Complete the following steps:
- Stop the daml_ledger_api and daml_index_db containers on all the Client nodes.
- Wait until the pruning operation is complete.
- Start the daml_ledger_api and daml_index_db containers on all the Client nodes.
