Comment on page
Understand the different data availability modes supported by the system.
Data availability refers to the ability of users to access and verify the data that is being processed on the Arc system. This is essential in order to ensure the self-custody, redundancy and trustlessness properties of the platform.
In Arc, transactions are processed off-chain and then submitted to the main blockchain in batches. The main blockchain then verifies the validity of these batches and records them on-chain. However, unlike traditional on-chain transactions, where data is always available on the main blockchain, Arc provides alternative mechanisms to store and access batch data.
Arc supports multiple data availability modes at a transaction level, allowing for flexibility in choosing the appropriate mode for each use case. The two modes currently supported by Arc are ZK-Rollup and Validium. Arc provides both modes to allow applications and users to choose the one that best suits their specific use case.
Arc API operations that result in changes in user balances (ie. deposits, transfers, mints and settlements) require the application to explicitly select the data availability mode.
Users can choose to use both modes within a single transaction by storing some data in one mode and the rest in the other (eg. a transfer from a ZK-Rollup sender to a Validium recipient). This flexibility provides a high degree of customisation and enables users to optimise their transaction costs while maintaining trustlessness and fine grained control data privacy.
ZK-Rollup is a mode in which all the necessary data to recover the Arc balances state is published on-chain as calldata. When using ZK-Rollup, the system outputs the proven new state and the complete list of differences of the users' balances compared to the previous state. This mode is trustless, as all the data required to reclaim user funds on an escape event is present and visible on the blockchain. However, each vault that has changed in the batch incurs a gas cost, which can be a disadvantage for batches in which many vaults' states change.
Validium is another mode supported by Arc. When using Validium, users' balances are not published on-chain. Instead, they are sent to several well-known and trusted parties who are members of the Data Availability Committee (DAC). A state update is valid and accepted on-chain only if at least a quorum of the committee members sign a state update. Specifically, they sign that they know all the new vault balances such that they determine to the new state, as enforced by the availability verifiers. Validium has the advantage of lower cost, as payment for on-chain data is not required. Additionally, user balance information is stored off-chain, privately, with a committee of trusted parties, not on-chain, providing greater privacy. However, using a DAC requires trust in the committee members, which can be a disadvantage for some users.
The composition of the DAC is crucial for preserving the integrity of the Arc data availability mechanism. The Arc Data Availability Committee (DAC) is a group of reputable and trusted parties responsible for providing redundancy and trustlessness in data storage, assuring data availability at all times, and authenticating the data availability of a batch within a Arc instance. This DAC will consist of Arc, Starkware, Three Sigma, and three additional members selected from the following list.
During the testnet phase, Starkware will service the Data Availability Committee, the full Arc DAC will go live with the mainnet release.
Each member of the DAC installs and executes an instance of the Committee Service, which is responsible for sending Arc signed approval of the batch after checking data availability. DAC members retain copies of off-chain data and distribute it to the public domain if Arc Operators fail to honor withdrawal requests from their users. In such a scenario, the on-chain contract ceases accepting new state updates and only permits customers to withdraw funds directly.