[anchpop]

Right now they're immature, but I'm hopeful that advancements in ZK-tech will allow practical ZK-rollups. ZKSync already has a zk-evm testnet running (which I believe is based on zk-llvm), so we're close. Currently all the big rollups have master keys which can be used to steal all the money deposited by them, but there's no reason in principle they have to have this. Polygon has permissionless rollups, so I'm quite hopeful that they'll be a viable trustless permissionless scaling solution soon.

[joosters]

The crypto(graphy) is rarely the weakness in these situations, so declaring faith in (insert new tech buzzword here) is almost certainly not going to be the answer. It comes down to operational and human factors, like poorly written code. (new tech buzzword) will involve lots of new code, and why do people think this time the new code will be error-free?

[anchpop]

In this case, the weakness was that the keys that controlled the bridge were somehow stored insecurely. When attackers gained access to the keys, they were able to steal from the bridge. In a properly-implemented rollup, there are no keys to secure, so this attack vector is ruled out.

But more broadly, there is really nothing else with the same security properties as a smart-contract-enabled cryptocurrency. Paypal will delete your account any time they want, Visa and Mastercard will blacklist whatever industries they feel like blacklisting, etc. If you want a system that's decentralized and where these attacks aren't possible, you have no alternative. The problem is that current blockchain-based systems can only handle a certain number of operations/second while remaining decentralized. The appeal of scaling solutions like ZK-rollups is that they give us the same security properties as the main chain without any security compromises (relative to the main chain). That's all conditional on their code being correct, but given that there's such a large payout to hacking e.g. bitcoin or ethereum or zksync and it still hasn't happened, we can guess that the coders have done their jobs well and such problems are at least very difficult to find.

[3np]

What you are saying applies equally to "the internet" and "computers".

[ethbr0]

For those who don't follow blockchain tech, like me, here's a primer on ZK-rollups: https://learn.bybit.com/blockchain/zk-rollups-eth-scalabilit...

[parineum]

> Right now they're immature

It's 14 years old.

The community has had a fix for all of these problems just over the horizon for a decade. It just isn't coming.

The real issue is that most of the crypto being held is held by people who don't care about using it as currency or for anonymity, they're using it as an "investment". That's why when coins that work better as cash or privacy or whatever come out, nobody cares, they just keep trucking on with bitcoin. All they care about is that the value of bitcoin goes up.

[anchpop]

ZK rollups are not anywhere near 14 years old

[atweiden]

Anyone can make anything which supposedly “works better as cash”.

How will they create confidence in the money, though?

In addition, please bear in mind aluminium and copper are more _generally useful_ than gold.

We cannot state, therefore, a money’s usefulness is more important than the hardness of the money: i.e. its scarcity and resistance to fundamental change.

This is likely why most competing currencies these days claim to be “decentralized”. It’s really just their way of claiming hardness without openly admitting to such.

[DennisP]

The nice thing about zkrollups is that users have a cryptographic guarantee of being able to withdraw their money. The rolled-up transactions are posted on chain in compressed form, and a contract on chain verifies a concise proof that all the rules were followed, including that all transactions had valid signatures.

So if this is done correctly, any master keys shouldn't be able to steal user funds. The key holders would be the ones authorized to post the data, but the worst they could do is censor transactions.

[anchpop]

Right. It's possible to conceive of a rollup, particularly a zk-rollup, without anything like a master key. But current rollups do have those keys. ZK-sync for example has two, one used mostly used for upgrading the smart contract that has a 14-day withdrawal delay (or something like that) and one for use in case of emergency that has no withdrawal delay. If the second were compromised, it would lead to all the money stored in the rollup being stolen. But there's no reason in principle that either of these are necessary.

ZK-rollups are awesome because they don't introduce any trust assumptions (except for the master key issue, which is just an implementation detail). The only risk is current zk-rollup designs is that they could censor certain transactions by never including them in a "batch" (the rollup equivalent of a block), but with unpermissioned rollups like the one I think Polygon has even this issue is mitigated

[estro0182]

>done correctly

This has been the difficult bit for the ecosystem, and I think grasps at what GP is saying. For every competent dev/cryptographer in the space, there are 10(0) who are not because there’s so much money floating around. Those 10(0) may implement zk-class protocols incorrectly and end up in the same situation we see today. There is promise in but a ton of validation/maturation to do for zkrollups in the wild.