Data availability
Your users need to know that they have control over their funds, and that they can retrieve their funds at any time, in case your application is not functioning correctly.
In order to provide self-custody, redundancy and trustlessness, StarkEx-powered applications must make their users' data always available.
Data availability ensures the following:
-
The state that you store in your users' vaults is perfectly synchronized with the state that StarkEx stores.
-
The full balances tree is always available, which provides your users with the security of knowing that if StarkEx ever stops functioning, they can prove custody of their funds.
Data availability modes
StarkEx supports the following data availability modes:
| Mode | Supported by… | Description |
|---|---|---|
ZK-Rollup |
StarkEx Perpetual |
Vault balances are published on-chain as calldata. The ZK-Rollup provides built-in trustlessness. Vault range: 263, 263+231 |
Validium |
StarkEx Perpetual |
Data is available off-chain. The Data Availability Committee (DAC) stores Validium vaults' balances, providing a trusted solution to make your users’ data available. Vault range: 0, 231 |
Volition |
StarkEx Spot |
ZK-Rollup vault range: 263, 263+231 Validium vault range: 0, 231 |
ZK-Rollup
When using ZK-Rollup, the Cairo program ensures that all the required data to recover the L2 balances Merkle Tree is published on-chain as calldata. The output of a Cairo program when using ZK-Rollup includes the following:
-
The proven new state
-
The complete list of differences of the users' balances compared with the previous state
|
In order to reduce calldata usage and the corresponding gas costs, StarkEX does not publish all on-chain transactions, only balance changes. For example, if Alice sends 500 USDC to Bob, and then receives 200 USDC from Charlie, StarkEx only publishes Alice’s new vault, which is now 300 USDC less than the previous state. This optimization is very efficient for real-life scenarios where heavy market makers comprise a large portion of the transactions, using only several vaults. |
- Advantage
-
ZK-Rollup is trustless. All the data needed to reclaim user’s funds on an escape event is present and visible on the blockchain.
- Disadvantage
-
Each vault that has changed in the batch incurs a gas cost. So for batches in which many vaults' states change, the cost of a state update event applies mostly to the data availability, rather than the verification of the proof.
-
StarkEx Spot Trading:
-
StarkEx Perpetual Trading:
Validium
When using Validium vaults, users' balances are not published on-chain. Rather, 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.
- Advantages
-
-
Lower cost: Payment for on-chain data is not required. When updating the on-chain state, most gas is spent on the verification of the proof.
-
Privacy: Users' balance information is stored off-chain, privately, with a committee of trusted parties, not on-chain.
-
- Disadvantage
-
Using a DAC requires trust in the committee members.
Volition (StarkEx Spot Trading only)
Volition enables you to use both ZK-Rollup and Validium vaults in your application and let your users decide which vault range to use, for each and every asset they own.
Your application locates each vault in the corresponding vault’s tree. Your user can change the data availability vault for all, or in the case of a fungible asset, some, of a specific asset, by transferring it into a vault on the other tree.
Batch state approval (ZK-Rollup and Validium)
StarkEx does not submit a new state to the blockchain without your signed approval of the state. So every time that a new batch of transactions is ready, you must query StarkEx’s availability gateway, compute the new state, and approve it.
In order to help you integrate this step into your process, StarkWare provides a reference implementation of code that queries and computes the state, known as the Committee Service. You can use this code as is or modify it. Alternatively, you can write your own code. The code repository also includes a hook you can use to add your own validation code to check additional conditions on the state.
You can run this code natively, or in a container, as described in the repository documentation.
About The Data Availability Committee (Validium only)
A DAC is a group of individuals or organizations. The members of the DAC commit to providing StarkEx-powered applications with redundancy and trustlessness in storing data and ensuring that data is always available.
StarkEx does not submit a new on-chain state without the DAC’s signed approval.
DAC members install and run an implementation of the Committee Service, which does the following:
-
validates the data availability of a batch in a StarkEx instance
-
sends signed approval of the batch to StarkEx.
This service ensures that the state you store in your database, such as the state of your users’ vaults, is perfectly synchronized with the state that StarkEx stores.
Members keep copies of the off-chain data, and return that data to the public domain if StarkEx Operators do not service their users’ withdrawal requests. In such a case, the application Smart Contract (ASC) stops accepting new state updates. The only action it allows is direct withdrawals of funds by users who are able to provide a Merkle proof for the latest state.
If you do not set up a DAC for an application using Validium, your application cannot be decentralized.
For information on StarkEx’s default Data Availability Committee members and more information on Data Availability, see StarkWare’s website.
To be a DAC member, you need to set up the Committee Service and connect your server.
To set up a new DAC, you need to contact prospective members of your DAC.