Arcium Docs
arcium.com@ArciumHQ
  • Documentation
  • Developers
  • Introduction
    • Overview of the Arcium Network
    • Key Features & Use Cases
    • Basic Concepts
  • Getting Started
    • How To Use This Documentation
    • Architecture Overview
    • Network Stakeholders
  • Multi-Party eXecution Environments (MXEs)
    • Overview
    • MPC Protocols
    • MXE Encryption
  • Clusters
    • Overview
    • Node Priority List & Alternative Selection Criteria
    • Cluster Forking & Migration
    • Sybil Resistance
    • Incentivization
    • Permissioned Clusters
  • Arx Nodes
    • Overview
    • Configuration and Security
    • Performance and Incentives
  • Computations
    • Computation Tasks
    • Defining & Commissioning Computations
    • Lifecycle of an Arcium Computation
    • Pricing and Incentives
    • Censorship Resistance & Fault Handling
  • Solana Integration & Multichain Coordination
    • Solana Integration: Orchestration and Execution
    • Multichain Expansion
  • Staking
    • Overview
Powered by GitBook
On this page
  1. Computations

Defining & Commissioning Computations

PreviousComputation TasksNextLifecycle of an Arcium Computation

Last updated 2 months ago

In the Arcium Network, to perform computations, they must first be defined as Computation Definitions, which provide a structured framework for execution. Computation Definitions act as blueprints, ensuring that all parameters, authorities, and logic are clearly specified before the computation is instantiated. This process ensures flexibility, scalability, and secure execution.

Every Computation Definition is associated with an (Multi-Party Execution Environment) and consists of the following key components:

  1. Output Specifications: Each Computation Definition includes details about its expected outputs. These specifications define the structure and format of the data that will result from the computation. A limited amount of data can be returned via on-chain finalization transactions (due to inherent Solana transaction size limitations), however additional resulting data can be configured to be returned via pre-defined callback requests.

  2. Versioning and Upgrades: Each definition includes a version field that tracks updates or changes. This ensures backward compatibility and guarantees that instantiated computations are executed on the correct version of the definition. Versioning allows developers to make improvements without disrupting existing operations.

  3. Execution Logic: The computation logic is defined as a circuit.

  4. Access Authority: Computation Definitions specify which parties are authorized to execute them. Authority options include:

    • None: No entity is allowed to execute this definition.

    • Private: A single specified entity has exclusive execution rights.

    • Restricted: A defined list of entities has execution rights.

    • Public: Any entity in the network can execute the computation.

  5. Parameters: Each Computation Definition may include parameters that dictate the inputs required during execution. These parameters fall into two categories:

    • Plaintext: Raw, unencrypted inputs provided at the time of computation commissioning.

    • Ciphertext: Inputs encrypted with a symmetric cipher and passed in at the time of computation commissioning.

  6. Execution Costs: The circuit metadata details the number of arithmetic operations, inputs, and outputs required for execution. This metadata allows for precise cost calculations so that resource requirements can be understood upfront.

Commissioning A Computation

Once a Computation Definition is created, the next step is to commission it for execution. Commissioning involves preparing the computation for the Arcium Network, specifying all required details.

Key steps in commissioning include:

  1. Arguments: The inputs for the computation, corresponding to the parameters defined earlier, are passed at this stage.

  2. Execution Timing: The customer specifies when the computation should be executed, including an optional validity window with timestamps (valid after and valid before) to define its execution timeframe.

  3. Priority Fees: Customers set priority fees to incentivize faster execution, as higher fees take precedence in the network’s mempool.

  4. Callbacks: Bespoke actions triggered after execution are defined as:

    • Success Instructions: Static or dynamic on-chain actions based on successful execution, such as storing outputs or triggering follow-up computations.

    • Failure Instructions: Static on-chain actions taken in the case of failure.

  5. Mempool Handling: Once a computation is commissioned, it is placed in the mempool.

MXE