VMware Blockchain 1.3.0.3 Release Notes

VMware Blockchain 1.3.0.3 | 21 OCT 2021 | Build 83 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 patch release includes the following fix:

Fixed a problem that prevented clearing the conflict detection cache after the state transfer mechanism was implemented using a callback.

State transfer implementation results in a cache that contains old keys, which is used to detect conflicts in the deployment pre-execution. An inconsistent cache might result in diverging the state of the Replica node.

Component Versions

The supported domain versions include:

Domain	Version
VMware Blockchain Platform	1.3.0.3 build 83
VMware Blockchain Orchestrator	1.3.0.1 build 73
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.3.0.1 to 1.3.0.2 and 1.3.0.3, you can implement the in-place-based upgrade or clone-based upgrade process. See the Perform an In-Place-Based Upgrade or Perform Clone-Based Upgrade instructions in the Using and Managing VMware Blockchain Guide.
• When you upgrade from VMware Blockchain 1.2.0.2 to 1.3.0.2 and 1.3.0.3, implement the clone-based upgrade process. See the Perform Clone-Based Upgrade instructions in the Using and Managing VMware Blockchain Guide.

Resolved Issues

• Incorrect pruning status report after a Replica node restarts

  When restarting a Replica node after the pruning process completes, the restarted Replica node might report an incorrect status when queried using the ./concop prune status command. You can safely ignore this status message.

• Conflict detection cache does not clear after State Transfer mechanism is implemented using callback

  State Transfer implementation results in a cache that contains old keys, which is used to detect conflicts in the deployment pre-execution. An inconsistent cache might result in diverging the state of the Replica node.

• Client nodes are 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 2GB and the data folder is removed due to data corruption. Therefore, any .dar file uploads cause the Client node DAML Ledger API to fail.

• 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.

• The audit.log file overflows, causing the VMware Blockchain node VM to run out of storage space and make the environment unstable

  The /etc/audit/auditd.conf system file has a duplicate entry for max_log_file_action, one entry is ROTATE, and another entry is IGNORE. The duplicate entry values prevent log rotation and trigger the audit.log file to overflow.

Known Issues

• DAML package uploads and Ledger configuration submissions with the same submission_id might cause conflict in the DAML Ledger API's index database, rendering the Client node to become unresponsive

  In certain situations, uploading DAML packages or setting the Ledger time model with a previously used submission_id can cause the Client node to become unresponsive. These operation changes can be executed only by Client node administrators with JSON Web Token containing the admin claim. See the DAML documentation, Access tokens and claims.

  Workaround: Use UUIDs as submission_id for all the DAML package uploads and Ledger configuration submissions. For DAML package uploads, if the UUID is left blank, the Ledger API generates a unique identifier for the submission_id.

• A staggered restart of Replica nodes might cause some nodes into state transfer or, in a rare occurrence, to become non-functional

  When Replica nodes are restarted one after the other, some Replica nodes might enter into state transfer which does not complete. In rare circumstances, the Blockchain might become non-functional due to the Replica nodes not agreeing to a single view.

  Workaround: Selectively perform a backup and restore on Replica nodes that are stuck in state transfer or on all Replicas in case of non-functional Blockchain.

• Using the ActiveContractsService without specifying a template filter to retrieve active contracts is slow on large index databases

  For large databases with more than one billion transaction events recorded in the index database, the query to retrieve all active contracts 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 all active contracts might run into the timeout and abort 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.

• 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 VMware Blockchain node VM and re-deploy the Blockchain.