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
  • Censorship Resistance
  • Fault Handling
  • Slashing Mechanisms
  1. Computations

Censorship Resistance & Fault Handling

PreviousPricing and IncentivesNextSolana Integration: Orchestration and Execution

Last updated 2 months ago

The Arcium Network is designed to ensure robust censorship resistance and fault-tolerance, safeguarding computational integrity even in the presence of node failures or malicious behavior.

Below we'll cover a) censorship resistance strategies, b) fault handling, and c) slashing mechanisms.

Censorship Resistance

Censorship resistance is critical for maintaining trust in decentralized systems. In the Arcium Network, nodes cannot selectively block or disrupt computations without facing consequences.

The architecture enforces this through several mechanisms:

  1. Cryptographic Detection of Misbehavior: Nodes attempting to disrupt computations by submitting incorrect data, aborting tasks, or falsely claiming that other Nodes misbehaved can be, with Cerberus for example (Arcium's default ), detected cryptographically. Any deviation from the agreed-upon protocol triggers an automated process to identify the offending node.

  2. Slashing as a Deterrent: Misbehavior results in slashing penalties, which reduce the stake of the offending node. Although malicious transactions can already be detected, this serves as further punishment and compensates for the detection cost.

Fault Handling

Fault tolerance is integral to ensuring that the network operates smoothly, even when nodes fail due to technical issues or malicious intent.

The Arcium Network handles faults through these strategies:

  1. Non-Participation Detection: Non-participation occurs when a node fails to execute its assigned task. The network detects this using communication signals within clusters. If a node does not respond, it is flagged for review. The task can be elevated to a broader set of Nodes (outside the Cluster in question) if consensus cannot be found intra-Cluster.

  2. Cheating Detection: Cheating occurs when a node provides incorrect computation results. The Arcium Network uses cryptographic techniques to identify invalid outputs. This ensures that any attempt to manipulate results is immediately detected and penalized.

Also, as a part of the dispute resolution mechanism, in cases where faults are detected, computations are executed redundantly by other nodes to ensure reliable outcomes. This redundancy ensures that the network remains resilient, even in high-stakes scenarios.

Slashing Mechanisms

The Arcium Network employs slashing penalties to enforce accountability.

There are two main types of slashing:

  1. Non-Participation: Nodes failing to participate in computations face higher penalties due to the greater resource requirement needed to detect and confirm non-participation.

  2. Cheating: Nodes providing incorrect results are penalized based on the size of the computational work they've disrupted.

MPC Protocol