This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

VMware Blockchain 1.5 | 27 JAN 2022 | Build 127

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.5 release includes the following enhancements:

Performance and Time Service Protocol Improvements

Major improvements in the storage, thread management, and message validation processes and optimization in the Byzantine replica conflict detection algorithm result in the system supporting a higher throughput in terms of transactions per second (TPS).

An updated implementation of the Time Service protocol yields better efficiency with less storage consumption.

Resilience and Recovery Enhancements

Starting the Blockchain with only N-f Replica Nodes

Enterprises require a resilient platform to operate seamlessly through possible hardware, software, and other various failures. In cases where up to f Replica nodes on the platform fail, it is now possible to start a blockchain while working in the background to recover them.

Security Improvements

Full Copy Client Data Integrity

To ensure the integrity of all data since genesis is stored in an Object Store attached to the Full Copy Client. Signed checkpoints from the Replica nodes are now stored as part of the metadata in the Object Store. This mechanism provides both proof of origination and tamper detection capabilities for the data in the Full Copy Client.

TLS 1.3 Support

TLS 1.3 is the latest version of the Transport Layer Security (TLS) protocol with a simpler and faster protocol that supports stronger cipher suites. TLS 1.3 is the default version for TLS connections within all VMware Blockchain components. Specifically, the following paths use TLS 1.3:

  • The connection between the application and the Daml Ledger API
  • The connections between Client nodes (BFT client pool) and the Replica Network
  • The connections between Replica nodes

TLS Key Rotation

System administrators can adhere to cryptographic best practices by regularly rotating TLS keys to encrypt connections between Client nodes and the Replica Network and within the Replica Network using the key-rotation module in the reconfiguration framework.

Protection of the Ledger API TLS Key

The ledger API TLS Key is now stored securely, using the same mechanism that handles the protection of the rest of the private keys used by the platform.

Scalability and Flexibility Enhancements

Operator Defined vCPU Pinning

System administrators can define the exact number of vCPUs needed per application running on a VM by manually defining the Replica node vCPU ranges during deployment time. This ability provides better flexibility in the product’s deployment and better utilization of resources.

Error Handling and Logging Improvements

Enhanced debugging and supportability using better error handling capabilities and logging improvements. Reduced log sizes by removing redundant logs, filtering the metrics added into logs, increasing intervals, and much more has led to disk IOPS capacity optimization.

Component Versions

The supported domain versions include:

Domain Version
VMware Blockchain Platform 1.5
VMware Blockchain Orchestrator 1.5
DAML SDK 1.18.0

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 Considerations

  • Implement the clone-based upgrade process only when you upgrade from VMware Blockchain 1.4.0.1 to 1.5. See the Perform Clone-Based Upgrade instructions in the Using and Managing VMware Blockchain Guide.
  • When you upgrade from VMware Blockchain upgrade from 1.4 to 1.4.0.1, 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.

Resolved Issues

  • New -

    Fixed a problem where Full Copy Clients S3 metrics such as In Memory Read Keys and In Memory Read Bytes are not sent using the pull metrics endpoint

    The new S3 Metrics Last saved Block ID, S3 keys transferred, and S3 Bytes transferred replaces the previous metrics in the pull metrics endpoint. The implemented fix in the S3 metrics standardizes the metrics sent through the pull metrics endpoint and any configured push metrics endpoint.

  • New -

    Fixed the problem of using the ActiveContractsService without specifying a template filter to retrieve active contracts, which is slow on large index databases

    Significant performance improvements were made to the ActiveContractsService to accelerate retrieving all the active contracts within large databases with more than one billion transaction events recorded in the index database.

  • Updated Apache log4j to version 2.17 and Wavefront Proxy to version 10.12 to resolve CVE-2021-44228, CVE-2021-45046 and CVE-2021-45105

    For more information on these vulnerabilities and their impact on VMware products, see VMSA-2021-0028.

  • Fixed a problem where the thin replica client metrics were not correctly exposed using Prometheus and therefore were not visible in Wavefront

    The implemented fix displays the thin replica client metrics in Wavefront.

  • Fixed memory limits that were not set correctly

    Incorrect memory limits resulted in a substantial amount of memory being allocated to various Concord containers affecting performance. The fix allows proper allocation of memory limits, improving performance. 

  • Fixed a problem where the thin replica client metrics names were prefixed with the stream type and participant ID, causing the metrics to not appear in Wavefront

    The fix updated the Concord-BFT metrics wrapper for Prometheus to support labels for stream type and participant_id, which resulted in the thin replica client metrics appearing in Wavefront as metric names.

Known Issues

  • Wavefront metrics do not appear after the network interface is deactivated and re-enabled on Replica nodes

    This problem was observed while executing a test case that explicitly deactivated the network interface on Replica nodes and rarely manifested in a production environment.

    Workaround: Restart the telegraf container by running the command, docker restart telegraf for the metrics to appear in Wavefront.

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

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

check-circle-line exclamation-circle-line close-line
Scroll to top icon