Basic Concepts and Terminology

Naming: Arcium and Arx

While the Network is called the Arcium Network, "an Arx node" refers to a single MPC Node in the Arcium Network (as in "I run my own Arx"). The Arcium and Arx terms are derived from Latin, meaning fortification and protection. The term "Arx" draws directly from the Latin "arx", meaning "fortress" or "citadel", symbolizing each node as a strong, secure point within the Network. "Arcium" is the genitive plural form of "arx", hence translating to "of the citadels" or "of the fortresses". This means "Arcium Network" is the network of the fortresses.

Together, these concepts form "Arcium", a name aptly representative of a collective fortification system, highlighting the Network's robust security architecture and the resilient and cooperative strength of its components.

In the Arcium Network, each Arx node plays a crucial role in maintaining the integrity and security of the whole system, much like individual fortresses within a fortified city. But the power and strength of each Arx node only arises from it being part of the Network. An isolated Arx node might not be strong on its own, the resilience and power it has stems from its membership in the decentralized Arcium Network and hence being able to leverage the Network.

Multi-Party Computation (MPC)

Secure Multi-Party Computation (MPC) is a cryptographic technique that allows multiple parties to jointly compute a function over their individual inputs while keeping those inputs private from one another. MPC enables parties to derive a shared result without revealing their individual data, preserving privacy and security during computation.

General MPC

A typical MPC workflow consists of multiple participants who possess private data that they wish to keep confidential. Initially, all parties agree on a specific function to be computed jointly. They then convert their private data into a secret-shared form, distributing pieces of this data among other participants without revealing the original data. Each party performs calculations on the received pieces according to the predefined function. This involves a series of communication rounds where parties exchange computed results while maintaining the confidentiality of their inputs. Finally, the results from each participant are combined to obtain the final output, and in doing so no individual inputs are revealed, yet the correct computation outcome is provided for all parties.

MPC Protocols

MPC protocols vary mainly due to differences in their underlying cryptographic techniques, performance characteristics, and security assumptions, tailored to specific application needs. Garbled Circuits (GC), for example, encrypt functions into "garbled" versions that parties evaluate using encrypted inputs, optimal for boolean operations. Secret Sharing protocols, like SPDZ and BDOZ, distribute pieces of each input among parties, who then perform computations on shared fragments; these are well-suited for arithmetic computations and offer robustness against different numbers of dishonest participants. Each protocol type balances trade-offs between computation cost, communication overhead, and the level of security provided (e.g. against passive or active adversaries).

The Arx MPC Approach

As with most state-of-the-art MPC protocols, Arx nodes execute computations in two separate phases: a slower preprocessing phase, where "fuel" is produced, and a fast online phase, where the computation is actually executed and that fuel is consumed. As the "fuel" is independent of the computation, it can be produced in advance and therefore be ready as soon as a user requests a computation, leading to blazingly fast execution times. Computations are secure as long as one or more MPC participants are honest, and can be made to guarantee an output, eliminating the possibility of censorship. This can be achieved through a combination of non-participation prevention protocols as well as identifiable abort MPC (ID-MPC), which allows players to identify and impute malicious behavior to a specific peer. Combined with slashing and other game-theoretic mechanisms, attempts at censorship effectively become futile, and their cost extremely prohibitive.

Secret Sharing

Secret Sharing is a cryptographic method used to distribute a secret amongst a group of participants, each of whom is allocated a share of the secret. The key concept is that the secret can only be reconstructed when a sufficient number of shares are combined together; individually, the shares reveal no information about the original secret. This technique enables multiple parties to jointly compute a function over their data without exposing their individual inputs. The computation is done on the shares rather than on the data directly, allowing for collaborative calculations while maintaining data privacy. Different secret-sharing schemes may be employed depending on the security requirements and the threshold number of parties needed to reconstruct the secret.

Threshold Encryption

Threshold Encryption is a form of encryption that divides the ability to decrypt a message among multiple parties. In threshold encryption schemes, the decryption key is split into several shares, and a predefined minimum number of these shares, known as the "threshold", is required to decrypt the message successfully. This setup ensures that no single party has complete control over the decryption process, enhancing security by distributing trust among multiple participants. Threshold encryption is particularly useful in scenarios requiring high levels of data security and fault tolerance, where collaboration among multiple parties is necessary to access sensitive information. The process not only secures the encrypted data, but also provides a robust mechanism against the compromise or failure of any individual participant.

Fully Homomorphic Encryption (FHE)

Fully Homomorphic Encryption (FHE) is a type of encryption that enables computations to be carried out on ciphertexts (encrypted data) without needing to decrypt first. The results of such computations remain encrypted and can only be decrypted by the owner of the decryption key. This technology ensures that sensitive data can be processed securely and privately, opening up new possibilities for secure computing and data analysis.

Trusted Execution Environments (TEEs)

Trusted Execution Environments (TEEs) are secure areas of a processor that provide a higher level of security compared to the normal operating environment. TEEs protect the confidentiality and integrity of the code and data loaded within them from other software processes running on the device, including the operating system.

Different types of TEEs exist, like Intel's Software Guard Extensions (SGX), ARM's TrustZone, and AMD's Secure Encrypted Virtualization (SEV). They all provide hardware-based security features, each with unique implementations. Intel SGX offers strong isolation for selected code and data in private memory areas called enclaves, while ARM TrustZone partitions the processor into secure and non-secure states, creating a protected area for sensitive operations. AMD SEV focuses on encrypting virtual machine memory to protect against host attacks.

However, a common disadvantage of TEEs is their vulnerability to sophisticated side-channel attacks, as well as being challenging to integrate due to their complex requirements for code and operational management.

Zero-Knowledge Proofs (ZKPs)

Zero-Knowledge Proofs (ZKPs) are cryptographic protocols that enable a prover to prove to a verifier that a given statement is true, without conveying any additional information apart from the fact that the statement is indeed true. Commonly used schemes called SNARKs (Succinct Non-interactive ARguments of Knowledge) are also used to prove statements succinctly, meaning verifying them is typically very fast (at least sublinear in the size of the computation). The Arcium Network uses both the zero-knowledge and succinctness properties at various levels of its stack, for example in order to constrain hidden computation inputs or to provide succinctly verifiable outputs.

Secure Channels

A Secure Channel is a communication pathway that provides confidentiality, data integrity, and authentication to the messages being transmitted over it. This is typically achieved through the use of cryptographic techniques and protocols that ensure only authorized parties can access and read the data transmitted, protecting it from eavesdropping and tampering.

Adversary Model

An Adversary Model is a theoretical representation of the types of threats and attack methods a security system may face. It outlines the capabilities, resources, and goals of potential attackers, helping designers and engineers to understand and anticipate security vulnerabilities, and to develop effective countermeasures and security protocols.

Byzantine Fault Tolerance

Byzantine Fault Tolerance (BFT) is a property of distributed systems that enables them to continue functioning correctly even if some of the nodes in the system fail or act maliciously. This capability is crucial for systems where components may behave unpredictably or suffer from security breaches, ensuring reliability and continuous operation in distributed networks.

Byzantine Fault Tolerant frameworks can be based on either an honest majority or dishonest majority assumption. For example, Practical Byzantine Fault Tolerance (PBFT) is designed under the assumption of an honest majority — specifically, it requires that more than two-thirds of nodes act trustworthily to reach consensus, even in the presence of some malicious actors. Conversely, systems like BDOZ operate under the assumption of a dishonest majority. BDOZ maintains system integrity and achieves consensus even when the majority of participants might be compromised or actively colluding.

Why is MPC important?

MPC provides private execution environments to run sensitive computations that combine the benefits of many related technologies.

As in FHE (fully homomorphic encryption), computation inputs and outputs can be fully private whether the inputer is participating in the computation or not. However, unlike FHE, MPC nodes are forced to run only the agreed upon computation on the provided inputs: this guarantees that data cannot be maliciously manipulated, and can be later verified by a third party as well. In practice, this makes MPC closer to a verifiable form of FHE (or ZK-FHE).

These guarantees hinge on the protocol's security assumptions being true, namely that at least one MPC node (or a majority of them, in certain settings) is honest. The Arcium Network's on-chain architecture deploys multiple game-theoretic mechanisms that closely align nodes' honesty with their economic interests to ensure these conditions are met.

Arx Nodes

In the Arcium Network, an Arx node is an individual computing service provider that contributes to collective computation processes. Nodes may participate in multiple computational processes concurrently (see more about Clusters). For each one of these processes the Arx node holds a fragment of the overall data being computed (more specifically the node only holds a single keyshare to a given encrypted data). Nodes then collaboratively perform computations on these fragments without revealing their individual pieces of data to one another. This ensures the privacy and security of the data while enabling the Network to compute a function over an entire dataset. Nodes communicate through secure MPC protocols to share computation results, allowing the Network to derive a cryptographically verifiable final output (verifiable by anyone) without any single node having access to the complete data from others.

Epochs

Timing on the Arcium Network is tracked and handled via Epochs. These Epochs are of a consistent and fixed time duration, serving as a timing mechanism for the execution and scheduling of work, the distribution of rewards to Arx nodes, the lock-up periods of staked token, and more.

Clusters

In the Arcium Network, Clusters are groupings of Nodes defined by Network users that may then be used to execute computations. A Cluster serves as the set of Nodes which collectively executes a Multi-Party Computation. Nodes are placed in Clusters by users (computation customers) based on their unique properties, including their historical trustworthiness reputation on the Network, the capacity of their computational resources available, whether or not they have an optional Trusted Execution Environment for secret share management, as well as other factors.

Multi-Party Execution Environment (MXE)

On the Arcium Network, a Multi-Party eXecution Environment (MXE) defines a set of parameters for secure Multi-Party Computations to be executed on the Network. These MXEs are created by Network users (computation customers) to define their operations to be computed. The definition of an MXE consists of all relevant parameters, including which Cluster the MXE should use, data handling (computation definitions with input parameters and outputs), and more. MXEs are defined as either "persistent", meaning that they can be reused indefinitely into the future, or "single-use", indicating that the MXE may only be used for one computation and then automatically discarded. Persistent MXEs allow users to define persistent encrypted states that can directly be modified by computations in the MXE without ever decrypting the state.

Computations

In the Arcium Network, a Computation is an individual operation to be computed by an MXE. A Computation is created by a computation customer and consists of a definition of the circuit to be executed, parties that should have authority over the execution of the Computation (e.g. individuals, smart contracts, etc.), input data handling, output data handling, callbacks (e.g. to schedule future Computations, execute functions in other on-chain programs or off-chain callback hooks), and other attributes. Computations may be strung together to create chains of dependent operations, the output from one Computation getting passed via a callback to the next and so on.

Solana Programs / Integration

All orchestration of the Arcium Network is handled via the Solana blockchain, with programs on Solana handling all of the computation scheduling, rewards calculations and distributions, token staking and slashing, as well as many other organizational responsibilities. All network stakeholder and participant interactions are coordinated via the Arcium Network's Solana programs. This means that the Arcium Network uses Solana as its consensus layer, hence not requiring its own state and consensus for all normal operations – allowing for full parallelization within the Arcium Network.

Staking

In the Arcium Network, each Node maintains a proportional relationship between its computational (hardware) resources and the total amount of stake it has delegated to it. Stake may be delegated by both operators of Nodes as well as by 3rd-party delegators, and in both cases, the stake contributes towards unlocking the Node's hardware (rendering it available to do work). If the amount staked to a Node is less than its corresponding hardware capacity, then some of the Node's computational resources are ineligible to perform work (resulting in reduced performance), while any stake that exceeds the corresponding hardware capacity undergoes diminishing profitability. Therefore Node stakeholders have an active interest in maintaining a near-linear relationship between their Node's total stake and its computational resources available.

Slashing

In the event of Node misbehavior, the stake associated with the misbehaving Node is slashed as punishment. The slashing rate is uniform, thus resulting in a slash that corresponds to the size of the computation that was disrupted by the misconduct. Slashing acts as a strong disincentive for misbehavior, and also provides a mechanism to cover the costs associated with failed computations, compensating the other Nodes that did not misbehave for their work.