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
  • Fully-Permissioned Clusters
  • Partially-Permissioned Clusters
  • Public/Non-Permissioned Clusters
  1. Clusters

Permissioned Clusters

PreviousIncentivizationNextOverview

Last updated 1 month ago

Permissioned Clusters allow organizations to control how computational tasks are executed through various customizable setups. This means that organizations can adopt configurations that align with their specific security, compliance, and performance needs.

There are three primary configurations:

  1. Fully-Permissioned: Configured for organizations that operate their own infrastructure exclusively, using only their own internal Arx nodes to ensure data privacy and control.

  2. Partially-Permissioned: A hybrid model that combines an organization's internal nodes with select external nodes to increase computational power while retaining some oversight.

  3. Public/Non-Permissioned: Open to all verified nodes in the Arcium Network, providing a decentralized setup ideal for tasks that don’t require strict node control.

These distinct categories offer varying degrees of decentralization, enabling collaboration on joint computations across different organizational structures, including data analysis and AI model training, without compromising the privacy of individual datasets. Many other use cases exist, such as collaborative research between competitors or confidential data sharing across departments within a corporation.

Fully-Permissioned Clusters

Organizations or institutions may opt to run their own fully controlled Clusters, using only self-operated Arx nodes. This setup allows them to control the infrastructure, ensuring that only trusted nodes execute tasks.

Despite the isolation, fully permissioned Clusters can still leverage the broader Arcium Network's consensus mechanisms for tasks like dispute resolution, base pricing, and secure data processing, ensuring they benefit from network-wide features without sacrificing confidentiality.

Partially-Permissioned Clusters

This is a hybrid model whereby an organization operates some of the nodes within the Cluster, while also incorporating some external nodes as well.

Partially-permissioned Clusters are ideal for use cases where a certain number of outsider nodes (non-internal) are desired to provide oversight to an otherwise fully-permissioned setup.

For example, organizations can train AI models using internal nodes while simultaneously validating results using external nodes to ensure transparency and accuracy.

Public/Non-Permissioned Clusters

These Clusters are open to the wider network of Arx nodes and allow any trusted nodes to join and participate. Although specific criteria can be set, such as geographical restrictions or specific technical requirements, the default configuration ensures broad accessibility.

This configuration is beneficial for projects seeking greater decentralization as it ensures broader participation across the network and reduces the likelihood of collusion or centralized control.

It is especially beneficial for companies with stringent data security requirements, regulatory obligations, or those managing highly sensitive computations. For instance, financial institutions handling confidential customer data might deploy fully-permissioned Clusters to ensure that only their own highly trustworthy Arx nodes process sensitive transactions. Additionally, certain regulations such as or industry-specific compliance requirements may mandate strict control over where and how data is processed, making permissioned clusters a necessity in these scenarios.

Notably, only Public/Non-Permissioned Clusters utilize the random node selection process mentioned in the Overview page, which ensures and promotes decentralization.

GDPR
Sybil resistance