[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.