VMware Blockchain 1.1.0.1 | 04 FEB 2021 | Build 84 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
• Component Versions
• Resolved Issues
• Known Issues

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.1 release includes the following new features and enhancements:

Cloning

When certain business transactions fail or result in unexpected results, customers can troubleshoot these issues in a temporary blockchain deployment, which is created from a specified production blockchain state. After the completion of data backup, the restore command is used to create clone blockchain deployment.
This cloned blockchain has a unique topology of Replica and Client nodes. It starts from the same state as the original blockchain. New private keys are created and assigned during the deployment of the cloned blockchain to avoid the sharing of private keys or certificates between the cloned and original blockchain deployment.

Backup

Backing up the blockchain state is a prerequisite for cloning. In the 1.1release, the backup process allows users to backup every Replica node in the Replica Network and the Client nodes in the Client group. The System Administrator can back up every data center that is being used, regardless of how many Replica nodes or Client nodes present in the datacenter. This capability avoids situations where a blockchain state backup must be sent from one datacenter to another over the network especially considering the amount of time required for large datasets.

WEDGE Command

The WEDGE command is issued for all Replica nodes to make them stop processing new commands. The stopping point is agreed by all Replica nodes using the consensus protocol and the entire Replica Network stops processing commands at the same checkpoint. This action causes all Replica nodes to maintain the same state. After the Replica Network goes offline, the System Administrator backs up every Replica node in the network.

Monitoring Metrics

Instead of receiving metrics from Replica and Client nodes, customers now can access the metrics and have control over filtering, tagging, and indexing the available metrics. 

Security 

All internal communication of the VMware Blockchain platform components is protected by TLS. The same level of protection is now applied to the DAML Ledger API connections established between the DAML ledger API server and its clients. Also, the connection between the Client node and the Replica Network is now secured with a TLS 1.2 connection. This includes the read and write requests. 

Full Copy Client

Blockchain deployment supports data archiving the full ledger history to one or more ObjectStores using a Full copy client. This Full copy client’s role is to receive data stored on the blockchain and save it in the ObjectStore - in a trusted manner. Each Full copy client has its own set of private and public TLS Keys.

The public key of each Full copy client is known to the Replica Network. When a command is executed on the Replica Network, the result of the command execution is a key-value pair that is sent to the Full copy client over a TLS connection and written into the ObjectStore. In case the Full copy client goes offline for some time, once it is back online, it catches up with the missed data using the State Transfer protocol.

Mutual TLS (mTLS)

Ledger API connections established between the DAML Ledger API server and its Client nodes now have TLS protection. Additionally, any connection between the Client node and the Replica Network is secured with a TLS 1.2 connection. This includes both read and write requests.

Component Versions

The supported domain versions include:

Domain	Version
VMware Blockchain Platform	1.1.0.1
VMware Blockchain Orchestrator	1.1.0.1
DAML SDK	1.8.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

• Cannot submit DAML transactions right after deployment

  If you submit a DAML transaction before the entire system is up and running, you receive the following error message from the DAML Ledger API,  UNAVAILABLE: The ledger configuration is not available.

  Workaround: Complete the following steps:

  1. Run the DAML transaction.
  2. Check if the transaction completes successfully.
  3. Verify that the key generation is completed successfully.
  4. Verify that in the Concord logs, all the replica node exchanged keys can start accepting messages.
  5. If the transaction fails, restart the DAML Ledger API and resubmit your DAML transaction.
• In rare cases, a Replica node might remain in an infinite state transfer loop regardless of the incoming rate

  If the Concord logs on a given node indicate to remain in the state transfer mode with a block gap up to 300, then state transfer is in an infinite loop. The blockchain system continues to function if 2f+1 Replica nodes are in consensus.

  Workaround: Complete the following steps:

  1. In the Concord logs, search for the Start fetching checkpoint entry.
     The block gap is the difference between the newCheckpoint.lastBlock:2352173 and lastReachableBlockNum:2351979.
  2. Refer to the instructions in the Backup and Restore run book to restore the state from another Replica node.
• 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.

  Workaround: None

• When you disconnect and connect a Replica node from the network, the disconnected Replica node might show up in the advanced view

  When you disconnect and connect a Replica node from the network, the disconnected Replica node might show up in an advanced view. After the Replica is connected, the Replica node initiates the state transfer and remains in the previous view.

  Workaround: Complete the following steps:

  1. Use Wavefront to verify that the state transfer has been completed.
  2. If the Replica is in the advanced view, induce a view change.
  3. If the state transfer is in an infinite loop, refer to the instructions in the Backup and Restore run book to restore the state from another Replica node.
• A Replica node might remain in the state transfer mode if the average incoming rate is less than the default state transfer rate

  A Replica node might not recover from the state transfer mode if the average incoming rate is less than 25 blocks per second.

  Workaround: Complete the following steps:

  1. Use the metric receivedStateTransferMsgs per second to verify the incoming transaction rate.
  2. Stop or slow the incoming traffic to allow the Replica node to catch up or refer to the instructions in the Backup and Restore run book to restore the state from another Replica node.

Known Issues

• Possible performance degradation after continuous high transaction load for an extended time frame

  Running a blockchain deployment under a continuous high transaction load for over 30 hours could lead to an observable degradation in the throughput performance of the system.

  Workaround: None

• VMware Blockchain does not support a specific version of the ELK stack

  Environment specific configurations might be required to 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.

• 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 DMAL Ledger defaults to the optional value.

  Workaround: The optional client auth works with both empty and mTLS values. The DAML Ledger API can be configured to communicate over TLS or over plain text depending on whether the files are provided.

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

  Workaround: Either use certificates for the applications connecting to the  DAML Ledger API or disable TLS altogether.