The VMware Blockchain group is excited to announce the release of VMware Blockchain version 1.4. This release includes support for core business goals, including new transaction performance targets (both trade and non-trade), enhanced security capabilities, improved fault tolerance/recovery operations through automation, and the introduction of cloud-based deployment options. In this blog post, we will walk you through everything version 1.4 has to offer.

In our previous blog, we emphasized VMware Blockchain's sustained focus on delivering a robust, enterprise-grade decentralized trust platform for multi-party applications. We highlighted these critical areas: performance, security, resilience and recoverability, capacity management, scalability and flexibility, and deployment and observability.

In VMware Blockchain v1.4, we targeted unprecedented performance goals that further support our financial-services customers' needs for high-frequency, complex business operations across multiple nodes. Major improvements in the storage, batching, and post-execution layers now enable higher throughput, in terms of transactions per second (TPS).

Resilience and recovery

From inception, our vision was to be the most resilient blockchain offering in the industry, grounded by our Byzantine fault-tolerant (BFT) protocol, which safeguards the system's ability to maintain the correct state and to continue processing transactions - even with the complete failure of any one fault domain (with VMware Blockchain nodes deployed across four fault domains). Building upon this core protocol, we now offer additional resilience and recovery enhancements in v1.4:

  • In order to improve the recovery time objective (RTO) of replica nodes after failure, we have added significant recovery-mechanism improvements that synchronize replica nodes after the nodes encounter downtime. The improved RTO enables the system to quickly recover to full fault tolerance, especially with high-transaction-volume workloads.
  • Enterprises often require nightly backups of transactional systems for various purposes, including creating operational copies to troubleshoot failed business transactions. Nightly maintenance windows are limited and are often incapable of backing up several terabytes from multiple client nodes within these windows. Client node backup time is drastically reduced by allowing the creation of intermittent backups throughout the day.
  • To enable consistent backups in a replicated state-machine environment, the reconfiguration framework allows for replica nodes to pause at a consistent checkpoint (also known as "wedging"). Subsequently, the state of any replica node can be backed up and reused for recovery. After backup completion, the environment can be securely started using an "unwedge" command that simultaneously restarts all the replica nodes.

Enhanced security

Security continues to be our core fundamental North Star. We aim to continuously bolster security against malicious activity with every new release - a commitment that our customers highly value.

  • Building on the BFT state-machine replication (SMR) core, the reconfiguration framework enables configuration changes to occur under the same trust fundamentals as client-initiated transactions. Configuration commands must be signed and undergo consensus before being accepted by the blockchain platform. For recoverability reasons, if some blockchain nodes have failed up to f failures, configuration changes are still performed with the agreement of N-f replica nodes.
  • Transactions originating from client nodes are signed with a unique private key. The signature of these transactions is validated by replica nodes and are optionally persisted on-chain for future retrieval.
  • Private keys and other sensitive configuration information on each VMware Blockchain node are encrypted with a symmetric key. This symmetric key can be stored on the node or on software implementations of the Trusted Platform Module 2.0 (TPM 2.0) standard, known as Virtual Trusted Platform Modules (vTPM), supported by VMware vSphere.
  • A key-rotation module in the reconfiguration framework rotates key pairs used to sign messages in the SMR protocol and those used to sign client node requests.

Frictionless scale

To enable scalability for a variety of configurations and allow better resource management in line with scaling goals, we offer the following enhancements for scalability and flexibility:

  • Client node groups can now be sized independently, with CPU, memory, disk size, and PostgresDB parameters to provide flexibility in client node sizing. This feature allows sizing of nodes based on throughput requirements, which results in better resource management and cost efficiency.
  • Another module in the reconfiguration framework allows operators to add to or remove replica nodes from a blockchain deployment in a trusted, authenticated, and automated fashion.

When customers run complex business transactions at a high throughput rate, they typically generate extremely high volumes of data per day. With limited disk space and the financial implications of tackling this high volume of generated data, optimizing the output has been a high priority for our customers (and for us). We continue to address this pain point in v1.4 by allowing replica node pruning operations to be run as a background process, while the system continues to process client transactions.

Supporting deployment on a selection of infrastructure is a crucial piece of our long-term strategy. With v1.4, we now offer our customers an option to deploy on native AWS EC2 infrastructure, in addition to vSphere-based deployments. For use cases that require an accelerated deployment pathway, the replica and client nodes can now be distributed on EC2 instances.

For further details, reach out to the Blockchain group at ask_vmware_blockchain@vmware.com. To learn more about VMware Blockchain v1.4, please refer to our online product documentation.

Attachments

  • Original Link
  • Original Document
  • Permalink

Disclaimer

VMware Inc. published this content on 01 December 2021 and is solely responsible for the information contained therein. Distributed by Public, unedited and unaltered, on 02 December 2021 02:40:05 UTC.