| VMware Blockchain 1.3.0.1 | 05 AUG 2021 | Build 73 Check for additions and updates to these release notes. |
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.3.0.1 release includes the following enhancements:
Performance Enhancements
The blockchain platform can process a significantly higher number of transactions per second compared to previous versions because of several enhancements; new Client Node command batching, post-execution aggregation of blocks, limiting Docker memory, batching consensus messages, and vCPU pinning.
Replica Node Backup and Restore Enhancement
Replica nodes that store multiple terabytes of data can be backed up with minimal downtime, enabled by an enhancement in the backup mechanism, which creates intermittent backups.
Replica Node Signature Key Rotation Via Reconfiguration
To enable adherence to cryptographic best practices by regularly rotating keys, system administrators can rotate the signature keys used by Replica Nodes in the BFT State Machine Replication protocol. The key rotation operation is performed through the reconfiguration framework, accessible via CLI.
Monitoring and Observation
By default, Client and Replica Nodes expose an HTTP endpoint for any metrics collecting tool to pull node-specific monitoring metrics. Users can also configure nodes to push metrics to any metrics collecting tool.
Add and Remove Replica Node Improvement
Additions or deletions of Replica nodes are logged on-chain to increase trust.
Component Versions
The supported domain versions include:
| Domain | Version |
|---|---|
| VMware Blockchain Platform | 1.3.0.1 |
| VMware Blockchain Orchestrator | 1.3.0.1 |
| DAML SDK | 1.14.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.
Upgrade Consideration
When you upgrade from VMware Blockchain 1.2 to 1.3.0.1, implement the clone-based upgrade process. See the Perform a Clone-Based Upgrade instructions in the Using and Managing VMware Blockchain Guide.
Resolved Issues
- Replica node pruning requires 256GB memory allocation for the pruning process to function without failure
With 500,000 transactions or higher, 256GB memory allocation is required for Replica node pruning to execute successfully. Conversely, transactions that are less than 500,000 might succeed with a memory allocation of less than 256GB.
- Upgrade from VMware Blockchain version 1.1 to 1.2 requires special consideration
Special consideration is required when upgrading from VMware Blockchain 1.1 to 1.2. Contact your Blockchain support engineer.
- 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. - 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 deactivated, 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. - 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.
- Concord container health metrics service is not available and displays an error message
Concord container health metrics service displays an error message for an otherwise healthy Concord container. The agent container logs show the following error message:
Concord health check will not be unavailable.
Known Issues
- Client nodes unable to resynchronize data when the data size is greater than 2GB
Client nodes cannot resynchronize data from the Replica nodes when the data is greater than 2 GB and the data folder is removed due to data corruption. Therefore, any .dar file uploads cause the Client node DAML Ledger API to fail.
Workaround: Complete the following steps:
1 - Back up the data in the
/mnt/data/dbfolder periodically.2 - After data loss, restore from the previously backed up data.
- When a deployed VM is created, the VM might not have a private static IP address due to a race condition
In a rare occurrence, a deployed VM might not have a private static IP address when it is created. The problem occurs due to a race condition in the underlying Photon OS.
Workaround: Remove the deployed VM and re-deploy the blockchain.
-
Using the ActiveContractsService to retrieve active contracts without specifying a template filter slows large index databases
For large databases with more than one billion transaction events recorded in the index database, the active contracts query can take a long time to compute the results and respond to the application. As a result, applications with timeouts around the request to receive active contracts might timeout the operation.
Workaround: Applications must provide a template filter for requests to the active contracts service. The template filter guarantees that only necessary and expected data is loaded from the database and transmitted to the application.
