Several reconfiguration commands are available on the VMware Blockchain platform, allowing the operator to perform reconfiguration actions on the blockchain in a secure and trusted manner.
Reconfiguring VMware Blockchain Nodes
The Replica node reconfiguration commands are sent from an operator console to the Replica Network. The sending node's private key signs the reconfiguration commands. The Replica nodes receive the commands, verify the signature, and send them for consensus. After a consensus is reached, the commands are executed by each of the Replica nodes.
Client nodes might also need to execute reconfiguration commands. These commands are delivered to the Client node using the Daml Ledger. These reconfiguration commands are logged on-chain, and the Client nodes receive them by reading them from the Ledger and executing them by a dedicated execution engine on the Client node.
Most reconfiguration commands require that only N-f nodes agree to execute the command. The Replica nodes that were not part of the consensus, maybe because they were down, can learn about the commands from the Daml Ledger, similar to a slow Replica node that is catching up.
In the case of pruning operation, all the Replica nodes must reach a consensus.
Scaling
VMware Blockchain allows scaling the number of Replica nodes in the network to increase the fault tolerance. For example, VMware Blockchain can have four Replica nodes and withstand one failure. It can also scale up to 200 nodes and withstand 64 failures. The fault tolerance calculation, which is the number of Replica nodes in a deployment, must adhere to the formula of 3f+1, where f stands for failures.
Scaling down VMware Blockchain nodes is also possible when necessary.
The scaling operation is performed using reconfiguration, and the commands are logged on-chain and undergo consensus similar to all the reconfiguration operations. Therefore, the required consensus for scaling Replica nodes is N-f.
Scaling is useful in disaster recovery scenarios. For example, in a 7 Replica node deployment with up to two failures, when rapid recovery is impossible, you can scale down to a 4 Replica node deployment to retain system integrity. After the failed Replica nodes are recovered, the deployment can be scaled back to 7 Replica node deployment.
The recovered Replica nodes must be restored from scratch because when they join the VMware Blockchain deployment, these nodes are assigned a new Blockchain ID.
Key Rotation
Replica or Client node key rotation might be required because the keys were compromised or must be refreshed. The key rotation operation can be initiated using the reconfiguration operation and requires a consensus of N-f replica nodes. See Key Management.
Pruning
Replica or Client nodes have a limited local persistent storage to store the full history of the blockchain. To prevent the local storage from vastly growing, you need to prune the local storage.
Replica node pruning operation must have an N consensus out of N Replica nodes to maintain the Replica Network data integrity. Therefore, the pruning operation can not occur when any of the Replica nodes are down. See VMware Blockchain Pruning Implementation.
Wedge and Unwedge Reconfiguration
The wedge command securely stops the blockchain. After the blockchain is stopped, the operator can perform several reconfiguration commands such as scaling or system maintenance procedures. The operator can use the unwedge command to restart the blockchain. The wedge or unwedge command requires consensus of N-f Replica nodes.
Wedging the blockchain causes all Replica nodes to stop at the same state. After the wedge operation is initiated, the Replica nodes agree on a checkpoint and adjust the Replica Network state to stop at the agreed point. While the system is wedged, the Replica Network can only execute read commands, State Transfer messages, unwedge commands, and any command that does not change the state.
