Data Availability
Motivation
StarkEx is a self-custodial scalability engine. This is the fourth and final post in our Self-Custodial Series, which has described the different facets of a self-custodial system. This post describes StarkEx’s solution for Data Availability (DA): its first deployment, and the road ahead to an increasingly trustless future.
As a reminder, in StarkEx, transactions are batched, then validated off-chain, and an accompanying STARK proof is generated. We refer to this process as a valid state transition. The proof, alongside a commitment to the new state of the system are then sent to the blockchain, where the proof is verified and the commitment is stored. The data pertaining to the batched transactions can be stored either on-chain or off-chain. With on-chain DA, transactions are recorded as call-data. With off-chain DA, the transactions are recorded off-chain. Off-chain DA is more scalable: it consumes an essentially fixed amount of blockchain resources, regardless of the volume of activity on StarkEx.
The first StarkEx deployment — powering DeversiFi’s decentralized exchange — will have off-chain DA. DeversiFi made this choice not only because of scalability advantage, but also because it offers their users better privacy with respect to their trading strategies. Consequently, users who wish to access their balance can obtain it from the StarkEx Operators: the Application Operator and the Proof Operator (in this first deployment: DeversiFi and StarkWare, respectively). Users can verify their account balance in a given state with a Merkle path from their account in the Merkle tree to its root. Note the particulars of their trust in the Operators: users need not trust Operators that the state of the system is valid, as the STARK proofs enforce the validity of the state. Users merely have to trust the Operators to make the data available.
The Data Availability Committee (DAC)
In order to allow users to eliminate their trust in the StarkEx Operators altogether, we’ve formed a Data Availability Committee (DAC). DAC members are entrusted with keeping copies of the off-chain data, and placing them back in the public domain in case of emergency. Emergency is defined as a scenario where StarkEx Operators do not service users’ withdrawal requests. In case of emergency, the Application Smart Contract (ASC) will no longer accept new state updates, and instead allow only direct withdrawals of funds by users able to provide a Merkle proof for the latest state.
DAC Member’s Responsibilities
In the normal course of affairs
- Receive each state transition, compute the new state, and sign the commitment to the new state.
- Keep a private and secure copy of this off-chain data
The ASC will accept a STARK proof only if a quorum of DAC members has signed on its corresponding state commitment.
In case of emergency
make their copy of the data publicly available. Now users can access the Merkle path to their accounts, and use that path to retrieve their funds directly from the ASC, without needing to trust the Operators in any way.
The Road Ahead
We believe it is important to minimize trust in the DAC.
First, we intend to encrypt the data stored by the DAC. This will ensure that DAC members are no longer privy to any data pertaining to StarkEx users. Such an encryption ensures committee members are not exposed to sensitive information, thus reducing their liability and users’ implied trust in DAC members. Consequently, encryption will allow StarkWare to greatly expand the number of committee members, and further reduce the reliance on any individual member to comply with their role in case of emergency.
Later on, we will implement a fully trustless solution, where an interested party could altogether eliminate trust in the DAC. Instead, it would have to invest very limited resources: either in placing their own data on-chain, or in monitoring the progress of the off-chain data (though far less resources than the Operator). We will publish these ideas in more detail soon.
