Admission of MXEs

A number of different configurable behaviours are available for handling the admission of MXEs to a Cluster — the process by which an MXE is allowed to use a specific Cluster.

The default behaviour for a Cluster to be used by an MXE is that all Arx nodes in the Cluster must unanimously agree to admit the MXE. For this admission behaviour, in practice, Arx nodes will usually maintain their own (off-chain) blacklists of MXEs and Computation Customers (who create MXEs) which they are unwilling to do work for, and then automatically accept all other (unidentified) MXE admission requests. In this paradigm, if a single Arx node rejects the admission of a given MXE to their Cluster, then the MXE simply fails (the Computation Customer must find a different Cluster that will accept their MXE).

Alternatively, Clusters may be configured to automatically approve all MXE admission requests (without unanimous Arx node approval), effectively making an Arx node's initial assignment to such a Cluster an open-ended approval of any future MXEs to the Cluster. Finally, Cluster MXE admission behaviour may also be configured to delegate MXE admission decisions to a specific party (e.g. one Node in the Cluster could be tasked with solely approving the admission of MXEs to the Cluster).

These behaviours apply to both single-use and persistent MXEs in the same manner. Computation Customers who require quick access to a new MXE (single-use or persistent) can opt to select either a Cluster that has the automatic MXE admission approval behaviour enabled, or a unanimous-approval Cluster with highly reputable Arx nodes, which will likely respond to the MXE admission request immediately (since high-quality/professional Arx node operators will typically run dynamic MXE admission scripts alongside their Arx node software process).

MXE admission requests that remain unapproved may be withdrawn by Computation Customers after one complete epoch has elapsed.

Last updated