Difference between revisions of "Validium"

From CryptoWiki

m (1 revision imported)
 
Line 1: Line 1:
== Basics ==
== Basics ==
* From this [https://medium.com/matter-labs/zkrollup-vs-validium-starkex-5614e38bc263 article] (6-6-2020):
* Utilizes validity proofs. Data is stored [[Off Chain|off-chain]]. Usually cheaper then [[rollups]].
*From this [https://medium.com/matter-labs/zkrollup-vs-validium-starkex-5614e38bc263 article] (6-6-2020):
''"[[DeversiFi]] recently launched a new version of their exchange, powered by the [[StarkWare|StarkEx]] trading engine.''
''"[[DeversiFi]] recently launched a new version of their exchange, powered by the [[StarkWare|StarkEx]] trading engine.''


''StarkEx is a Validium: a [[Layer-2]] scaling solution in which the validity of all [[transactions]] is enforced using [[zero-knowledge proofs]], while data availability is kept [[off-chain]]. This prevents the funds in the Validium from being stolen as every transfer of value from an account of a given user must be authorized by that user.''
''StarkEx is a Validium: a [[Layer-2]] scaling solution in which the validity of all [[transactions]] is enforced using [[zero-knowledge proofs]], while data availability is kept [[off-chain]]. This prevents the funds in the Validium from being stolen as every transfer of value from an account of a given user must be authorized by that user.''


''Validium’s mechanism is very similar to a [[Zk-Rollup|zkRollup]], the only difference being that data-availability in a zkRollup is [[on-chain]], while Validium keeps it off-chain. This permits Validium to achieve considerably higher throughput — but this comes at a price: Operators of a StarkEx Validium can freeze users’ funds.''
''Validium’s mechanism is very similar to a [[Zk-Rollup|zkRollup]], the only difference being that data-availability in a [[zkRollup]] is [[on-chain]], while Validium keeps it off-chain. This permits Validium to achieve considerably higher throughput — but this comes at a price: Operators of a StarkEx Validium can freeze users’ funds.''


''Without zkRollup’s data availability guarantees, the operator — or to be more precise: the data availability manager(s) — of a Validium can deny any user the right to move their funds.''
''Without zkRollup’s data availability guarantees, the operator — or to be more precise: the data availability manager(s) — of a Validium can deny any user the right to [[move]] their funds.''


''Here’s how it works: the operator makes a tiny change in the Merklized state without disclosing the state change to users. Lacking this information, users cannot create Merkle proofs of ownership for their accounts.''
''Here’s how it works: the operator makes a tiny change in the Merklized [[state]] without disclosing the state change to users. Lacking this information, users cannot create Merkle proofs of ownership for their accounts.''


''While the problem is not entirely solvable, StarkEx mitigates it by introducing a [[permissioned]] Data Availability Committee (DAC). The DAC must acknowledge it has received the data by signing every update to the state by a quorum of its members. In StarkEx, the DAC consists of [https://medium.com/starkware/data-availability-e5564c416424 8 participants] (adding too many members will jeopardize the liveness of the system). These are well known, highly reputable organizations in established legal jurisdictions. It is very unlikely for them to ever even try to abuse their powers — or so the reasoning goes.''
''While the problem is not entirely solvable, StarkEx mitigates it by introducing a [[permissioned]] Data Availability Committee (DAC). The DAC must acknowledge it has received the data by signing every update to the state by a [[quorum]] of its members. In StarkEx, the DAC consists of [https://medium.com/starkware/data-availability-e5564c416424 8 participants] (adding too [[MANY|many]] members will jeopardize the liveness of the system). These are well known, highly reputable organizations in established legal jurisdictions. It is very unlikely for them to ever even try to abuse their powers — or so the reasoning goes.''


''Paradoxically, being well known, highly reputable, and residing in a jurisdiction with a strong state is [https://vitalik.ca/general/2019/05/09/control_as_liability.html exactly] what makes them vulnerable. One plausible scenario of things going haywire: operators are required to implement [[KYC]]/[[AML]] regulations and are obliged to freeze all funds of the accounts with over $10k trading history (possibly forever).''
''Paradoxically, being well known, highly reputable, and residing in a jurisdiction with a strong state is [https://vitalik.ca/general/2019/05/09/control_as_liability.html exactly] what makes them vulnerable. One plausible scenario of things going haywire: operators are required to implement [[KYC]]/[[AML]] regulations and are obliged to freeze all funds of the accounts with over $10k trading history (possibly forever).''


''It gets even more interesting as we dive deeper. StarkEx implements a [https://medium.com/starkware/contract-upgradability-d3a4451877c Verifier Contract Upgrade] mechanism that permits the operator to add a new item to the chain of verifier contracts immediately, sans delay. This cannot invalidate any of the old logic — you can’t remove user [[signature]] checks for example. Rather it allows additional constraints to be added (you can think of constraints as `require()` statements, speaking in terms of [[Solidity]]).''
''It gets even more interesting as we dive deeper. StarkEx implements a [https://medium.com/starkware/contract-upgradability-d3a4451877c Verifier Contract Upgrade] mechanism that permits the operator to add a new item to the chain of verifier [[contracts]] immediately, sans delay. This cannot invalidate any of the old logic — you can’t remove user [[signature]] checks for example. Rather it allows additional constraints to be added (you can think of constraints as `require()` statements, speaking in terms of [[Solidity]]).''


''It is a nice security feature: should any missing constraint be found in the StarkEx’ STARK circuit logic, it can be fixed quickly without introducing any new vulnerabilities. However, this feature can be abused as a concealed censorship backdoor. In a nutshell, the StarkEx operator can always deploy an extension to the contract logic that introduces a blacklist without any prior warning to users. It’s not entirely clear from their documentation, but it looks like the consent of the DAC is not required to enforce the new rules.''
''It is a nice security feature: should any missing constraint be found in the StarkEx’ [[STARK]] circuit logic, it can be fixed quickly without introducing any new vulnerabilities. However, this feature can be abused as a concealed censorship backdoor. In a nutshell, the StarkEx operator can always deploy an extension to the [[contract]] logic that introduces a [[blacklist]] without any prior warning to users. It’s not entirely clear from their documentation, but it looks like the consent of the DAC is not required to enforce the new rules.''


''This doesn’t make much sense if you were to think of StarkEx as a fully [[decentralized exchange]] protocol. Imagine [[Vitalik Buterin]] owning a switch that can instantly freeze any [[Ethereum]] account. On the other hand, it makes perfect sense if you look at StarkEx as a security enhancement for crypto exchanges (which its creators surely do)."''
''This doesn’t make much sense if you were to think of StarkEx as a fully [[decentralized exchange]] protocol. Imagine [[Vitalik Buterin]] owning a switch that can instantly freeze any [[Ethereum]] account. On the other hand, it makes perfect sense if you look at StarkEx as a security enhancement for crypto exchanges (which its creators surely do)."''
Line 27: Line 28:
''"If an attacker can [[51% Attack|51% attack]] the smaller chain, how much damage can they do?''
''"If an attacker can [[51% Attack|51% attack]] the smaller chain, how much damage can they do?''


''If the smaller chain is a "validium", they can permanently lock up all the users' money but they can't steal anything. Validiums (eg. Starkware's [[Immutable X (IMX)|ImmutableX]]) are thus an interesting middle ground. They are not quite "true [[Layer Two|L2s]]" to the same extent as rollups are, because someone who takes over the validium can still deny users access to their funds and extort them, but they are nevertheless significantly more secure than [[Sidechain|sidechains]], and importantly they can be as scalable as sidechains.''
''If the smaller chain is a "validium", they can permanently lock up all the users' money but they can't steal anything. Validiums (eg. [[Starkware]]'s [[Immutable X (IMX)|ImmutableX]]) are thus an interesting middle ground. They are not quite "true [[Layer Two|L2s]]" to the same extent as rollups are, because someone who takes over the validium can still deny users access to their funds and extort them, but they are nevertheless significantly more secure than [[Sidechain|sidechains]], and importantly they can be as scalable as [[sidechains]].''


''This is what we mean by "shared security". If you are hodling assets and doing stuff on the smaller chain, are you as secure as if you were doing it on the larger chain, or are you less secure? On a rollup or a [[plasma]], you are just as secure. On an independent L1 or a sidechain, you are much less secure. On a validium, you're somewhere in the middle."''
''This is what we mean by "shared security". If you are [[hodling]] assets and doing stuff on the smaller chain, are you as secure as if you were doing it on the larger chain, or are you less secure? On a rollup or a [[plasma]], you are just as secure. On an independent L1 or a [[sidechain]], you are much less secure. On a validium, you're somewhere in the middle."''
[[Category:Jargon/Various]]
[[Category:Jargon/Various]]

Latest revision as of 06:34, 18 April 2022

Basics

"DeversiFi recently launched a new version of their exchange, powered by the StarkEx trading engine.

StarkEx is a Validium: a Layer-2 scaling solution in which the validity of all transactions is enforced using zero-knowledge proofs, while data availability is kept off-chain. This prevents the funds in the Validium from being stolen as every transfer of value from an account of a given user must be authorized by that user.

Validium’s mechanism is very similar to a zkRollup, the only difference being that data-availability in a zkRollup is on-chain, while Validium keeps it off-chain. This permits Validium to achieve considerably higher throughput — but this comes at a price: Operators of a StarkEx Validium can freeze users’ funds.

Without zkRollup’s data availability guarantees, the operator — or to be more precise: the data availability manager(s) — of a Validium can deny any user the right to move their funds.

Here’s how it works: the operator makes a tiny change in the Merklized state without disclosing the state change to users. Lacking this information, users cannot create Merkle proofs of ownership for their accounts.

While the problem is not entirely solvable, StarkEx mitigates it by introducing a permissioned Data Availability Committee (DAC). The DAC must acknowledge it has received the data by signing every update to the state by a quorum of its members. In StarkEx, the DAC consists of 8 participants (adding too many members will jeopardize the liveness of the system). These are well known, highly reputable organizations in established legal jurisdictions. It is very unlikely for them to ever even try to abuse their powers — or so the reasoning goes.

Paradoxically, being well known, highly reputable, and residing in a jurisdiction with a strong state is exactly what makes them vulnerable. One plausible scenario of things going haywire: operators are required to implement KYC/AML regulations and are obliged to freeze all funds of the accounts with over $10k trading history (possibly forever).

It gets even more interesting as we dive deeper. StarkEx implements a Verifier Contract Upgrade mechanism that permits the operator to add a new item to the chain of verifier contracts immediately, sans delay. This cannot invalidate any of the old logic — you can’t remove user signature checks for example. Rather it allows additional constraints to be added (you can think of constraints as `require()` statements, speaking in terms of Solidity).

It is a nice security feature: should any missing constraint be found in the StarkEx’ STARK circuit logic, it can be fixed quickly without introducing any new vulnerabilities. However, this feature can be abused as a concealed censorship backdoor. In a nutshell, the StarkEx operator can always deploy an extension to the contract logic that introduces a blacklist without any prior warning to users. It’s not entirely clear from their documentation, but it looks like the consent of the DAC is not required to enforce the new rules.

This doesn’t make much sense if you were to think of StarkEx as a fully decentralized exchange protocol. Imagine Vitalik Buterin owning a switch that can instantly freeze any Ethereum account. On the other hand, it makes perfect sense if you look at StarkEx as a security enhancement for crypto exchanges (which its creators surely do)."

Shared Security

"If an attacker can 51% attack the smaller chain, how much damage can they do?

If the smaller chain is a "validium", they can permanently lock up all the users' money but they can't steal anything. Validiums (eg. Starkware's ImmutableX) are thus an interesting middle ground. They are not quite "true L2s" to the same extent as rollups are, because someone who takes over the validium can still deny users access to their funds and extort them, but they are nevertheless significantly more secure than sidechains, and importantly they can be as scalable as sidechains.

This is what we mean by "shared security". If you are hodling assets and doing stuff on the smaller chain, are you as secure as if you were doing it on the larger chain, or are you less secure? On a rollup or a plasma, you are just as secure. On an independent L1 or a sidechain, you are much less secure. On a validium, you're somewhere in the middle."