Cluster Forking & Migration
As a reminder, Clusters in the Arcium Network are groups of Arx nodes assembled to collectively execute Multi-Party Computation (MPC) operations.
For non-Permissioned Clusters, prior to Cluster activation, one random Arx node from the Network is included in the Cluster's node set. Not explicitly defined by the Computation Customer, this random node is instead independently selected via the Automatic Alternative Node Selection mechanism (see the Sybil Resistance section for more on this process).
The Cluster becomes active for use once all Arx nodes assigned to it approve the assignment, including the randomly selected node. If approval is not unanimous, the Computation Customer, referring to the entity that initiates and commissions computations within the network, may cancel the Cluster formation process after a minimum of one complete epoch has passed. If a single Arx node assigned to a Cluster opts to reject the assignment, then the Cluster creation fails.
Clusters in the Arcium Network are designed to be adaptive to any situation, but there are scenarios where changes in the Cluster composition become necessary.
Two key mechanisms that facilitate this adaptability are:
Cluster Forking: The process where nodes within a Cluster decide to eject an MXE, leading to the formation of a new Cluster that supports the ejected MXE independently.
Cluster Migration: The movement of tasks or nodes from one Cluster to another, either due to planned exits or forced circumstances like downtime, stake reduction or Cluster Forking.
Cluster Forking
Cluster forking occurs when one or more Arx nodes in a Cluster decide to eject a specific MXE from their group. This might happen if the nodes determine that the MXE is involved in undesirable activities (e.g., illegal behavior) or other operational concerns arise. Here’s how the process works:
Initiating a Fork: If an Arx node within a Cluster wishes to eject an MXE, it signals this intent. Other nodes in the Cluster then have until the beginning of the next epoch to either join the ejection or decide to continue supporting the MXE. At the start of the new epoch, a fork occurs only if at least one node opts to continue supporting the ejected MXE. If all nodes agree to eject the MXE, no fork occurs.
Creation of a New Cluster: Nodes that choose to eject the MXE will remain in the original Cluster, while those opting to continue supporting the MXE form a new Cluster. However, nodes supporting the ejected MXE also remain part of the original Cluster, effectively participating in both the new and the old Clusters. The costs associated with creating the new Cluster and migrating the MXE to it are split between the nodes that initiated the ejection.
Maintaining Service Continuity: The original Cluster can continue operating unaffected, providing computational support to other MXEs without disruption. Meanwhile, the new Cluster allows the ejected MXE to continue its operations, isolated from the nodes that no longer wish to participate in its activities.
Cluster Migration
Migration is the process of moving tasks from one Cluster of Arx nodes to another Cluster of Arx nodes.
There are two primary types of migration:
Forced Migration: The automatic reassignment of an Arx node's tasks to replacement nodes when it fails to meet required criteria, such as stake reduction or extended downtime. This ensures continuity within the Cluster. For example, protocol violations (e.g., repeated cheating or extended downtime) might trigger a forced migration, where the failing node’s responsibilities are transferred to other available nodes.
Planned Migration: A pre-arranged transition where an Arx node operator voluntarily steps away from the network, ensuring their tasks are reassigned to replacement nodes without penalties beyond standard migration costs, provided sufficient notice is given. For example, if an Arx node operator plans to exit the network, they can initiate a migration one epoch in advance, allowing a handoff of their workload to other active nodes.
Migration Costs
In a forced migration, the costs are shared proportionally among all stakeholders of the migrating Arx node—the node being removed from its original Cluster. However, these costs are typically minor, reflected as a small reduction in distributed rewards. That said, since forced migrations are always the result of a slashable offense, the actual financial impact extends beyond just migration costs. The node operator and its stakeholders would also incur a larger penalty due to slashing, making forced migrations more costly than planned exits.
In contrast, a planned migration requires the migrating Arx node to cover migration costs from its self-delegation. This ensures that the expenses of reallocating the node’s tasks to new nodes within the network are accounted for, preventing potential service interruptions. New Clusters are formed based on the existing configuration, prioritizing available nodes from the original Cluster’s Node Priority List or employing alternative selection mechanisms.
Last updated