Volition and the Emerging Data Availability spectrum
TL;DR
Data Availability is a rich spectrum, not an on-chain/off-chain dichotomy. StarkEx deployments will cover this entire spectrum. StarkEx instances can currently be deployed as either a Rollup (on-chain data) or a Validium (off-chain data). The very first StarkEx deployment is a Validium.
We describe a new design: Volition, a hybrid on-chain/off-chain data solution, that allows users to dynamically pick where they want their data stored. StarkEx will support Volition soon.
Background
We recently launched the first StarkEx deployment on Ethereum Mainnet. This deployment powers the DeversiFi DEX. The Data Availability (DA) solution selected by DeversiFi has data stored off-chain by a DA Committee (DAC). DeversiFi chose this solution for V1.0 of their DEX because their customers — professional traders — cannot have their trading history recorded on-chain, as it would expose their strategies to competitors. DeversiFi opted for a solution that answers an important need of their customers, while minimizing their trust in the DAC. Worth noting: another reason DeversiFi opted for an off-chain data solution is scalability: scalability enables liquidity, an important property for an emergent DEX.
A nomenclature discussion followed our launch to properly name different scaling solutions, taking into consideration their DA approach. We proposed the following refinement in definitions.
Per these definitions, DeversiFi’s new DEX runs on top of a Validium.
Motivation
We believe DA is an important property of a scaling solution. We know that different applications, different users, different operators — all have their particular needs, which impact their DA choices. Companies developing scaling solutions will have to offer a range of offerings, to address this variety in customer/user needs.
Over the past year, we’ve spent considerable efforts researching the DA design space. It is a rich multi-dimensional space, and the ecosystem’s understanding of it will surely advance as blockchains grow. Our hope is to explain existing trade-offs we see, and to research means of reducing them. Specifically, we are committed to pursuing DA designs that scale sub-linearly (i.e., scale better than ZK-Rollups); as congestion on Ethereum grows, such designs will become increasingly important. If Ethereum becomes the ubiquitous public infrastructure we expect it to be, there is no avoiding this requirement. This post describes a few different attempts at addressing it.
Volition
The value proposition we aim for is simple: give users the freedom to choose — of their own volition — their DA preference at the individual transaction level at any point in time, for any type of asset, for any amount they choose. Imagine a trading firm, with its risk/reward profile, which dictates their preferences for storing funds securely and benefiting from low transaction fees. At such a firm, a trading day would start with the transfer of funds to its traders’ Off-chain Data (OFFD) account, where they can trade frequently and inexpensively throughout the day. At the close of business, for security reasons, all funds will be moved back to an On-chain Data (OND) account.
Conceptually, each account in StarkEx will be defined as either an OFFD or an OND. A user can control multiple accounts, and transfer funds between them, as the need arises. StarkEx produces a proof per batch of transactions. A proof that includes transactions involving an OND account must include as public input (call data) the post-batch balance for these accounts.
The above diagram should therefore be updated:
We’re implementing this design, and will provide additional details on its deployment soon.
Privacy
The solutions currently available on the market suffer from privacy problems. As mentioned above, privacy concerns drove DeversiFi’s choices for its first StarkEx version. Systems combining Zero-Knowledge Proofs (ZKP) with encryption allow data to be made private. This can be applied to both OND (Rollup) and OFFD (Validium), to offer users better privacy.
OND: We have a design for publishing encrypted data on-chain. This would allow traders to benefit from the security of a Rollup, without compromising their privacy and exposing their trading strategies.
OFFD: Privacy ensures that DAC members cannot abuse their role: they would still be able to attest to the availability of data, but without knowing the details of the trades or balances. Consequently, the StarkEx DAC membership could be expanded tenfold (from its current size of half a dozen members). With a larger DAC, the size of the batch-signing quorum could also be increased. Furthermore, the responsibilities of DAC members would be reduced to strictly signing for every batch processed by StarkEx; the data could be made public — DAC members would no longer be tasked to keep the data private.
In conclusion, adding privacy to StarkEx, in whatever configuration is chosen, can make it a better, more secure offering.
Next, we will provide high-level descriptions of two meaningful DA enhancements we’ve designed. Our intent is to both share our useful designs, as well as further emphasize the richness of the DA design space.
Minimally Viable Rollback (MVR)
When considering OFFD solutions, one concern is a data-unavailable attack: in case both the operator and DAC are compromised, one might transition the system to a new state without publishing the needed data (creating a data-unavailable state).
MVR solves this issue by enabling rollback of a data-unavailable state to a different state, for which data is available. It does so while preserving solvency in the new rolled back state (state_new), thus preventing double-spending. In an MVR system, each withdrawal is accompanied by submitting, on-chain, the details of all transactions that feed into the vault being withdrawn (in the last k batches). State_new is based on an earlier recent state (state_recent), whose data is available, but is not simply a copy of it. Rather, it’s a “solvent” state, incorporating all recent flows in & out of StarkEx (in the last k batches) that culminated in withdrawals. This enables users to withdraw from the new state.
The MVR design prevents the following (“double-spend”) attack: attacker withdraws funds after state_recent, then moves the system to a data-unavailable state; once the system reverts to state_recent, the attacker gets their already-withdrawn funds back.
With MVR, as long as the attack is detected within k batches, the system can revert to state_new, as proofs submitted within these batches include sufficient information to construct a solvent state.
In terms of scalability, some data is thus sent on-chain, but in the common case, less so than in a Rollup (worst-case: as much as a Rollup). With proper system design utilizing Fast Withdrawals, there will even be no additional public input compared to a Validium.
For a somewhat more detailed description, including how state_new is computed, read here.
Trustless Off-Chain Data Availability (TODA)
In TODA, users can operate in a fully trustless manner, by choosing to become a Power User (PU). The funds of a PU are always in their custody: typically a PU provides a signature per proof, just like DAC members. With their signature, a PU confirms that they have access to their own OFFD, thus allowing them to activate the Escape Hatch in case of an emergency, even if DAC members do not abide by their designated role to publish all data. Absent that timely signature, the PU’s funds are automatically withdrawn back on-chain to the Application Smart Contract — this is a Protective Withdrawal, and is at the core of TODA’s improved trustlessness.
A user who prefers not to be a PU can choose instead to trust an off-chain entity, though they will no longer be restricted to trusting a DAC member — they can opt to trust any PU willing to serve as a watchtower on their behalf (and would have to authorize that PU to do so). We will post a complete description of this protocol in the coming period.
Conclusion
DA is a critical component of any scalable blockchain-based system. The blockchain ecosystem, and StarkWare in particular, are spending considerable efforts in exploring this design space. This post described some of the more exciting designs we have in mind, including Volition, where users are free to choose whether their data resides on-chain or off-chain, every time they transact.
~Tom Brand, Avihu Levy, Uri Kolodny
