If you ignore who the various multisig keyholders are, zkSync functionally can be instantly upgraded by m of n keyholders. The scheme they have where there are two different groups, one who proposes and one who can speed up the proposal, doesn’t change the fact that if you can compromise m keyholders across those two groups you can instantly upgrade the system and thereby steal all of the funds.
I think it is relevant to refer to the Ronin attack, where a state actor (allegedly) compromised a multisig to steal all of the funds of a platform. All of the other systems that have a yellow entry in the Upgradability column are protected against this attack vector to some degree, while zkSync is not protected against this attack vector.
IMO, a red yes in that column means there exists some set of keys that can upgrade the system instantly, while yellow means there exists some set of keys that can upgrade the system non-instantly and people can withdraw their funds during that intervening time.
If you ignore who the various multisig keyholders are
Fair point. The thing is: you can’t ignore the difference between “3/6 team multisig + 9/15 of prominent community figures” and “1/2 team multisig”, and just blank label both with a red “Yes”.
So we’ve put a lot of effort into thinking how we can mitigate it without giving team the privilege. Note that many Defi protocols, e.g. Maker (see here) are forced to use similar approaches.
I’m all in for transparency, but then please add nuance: multiple columns with different aspects, and links to the mechanism description.
There is a new class of attack vectors that show up when a multisig that can instantly deploy that simply don’t exist at all when you have a time delay on upgrades. While one can argue that a 12 of 21 multisig is better than a 1 of 2 multisig (and in many, but not all, cases this would be true) the same class of attacks are possible against any system secured by a multisig.
IMO, the risk matrix should use the colors to outline the class of attacks that can occur against the system, and it shouldn’t try to evaluate how good a particular project is at securing against the viable attacks within those classes.
I could see value in leaving the color red, but having that column include the m/n numbers (in the case of zkSync, it would be 12/21*) rather than just yes. That would also help show which projects have a multisig that can upgrade vs which are EOA upgradable.
All L2s currently are upgradable except for a couple. The upgradability problem isn’t unique to ZKRs or zkSync, it is just that zkSync’s entry in L2beat doesn’t accurately reflect reality at the moment IMO.
Multisigs with hot wallets or cold wallets are in different classes. Upgradeability by “team only” or “team + broader community” are in different classes.
If only 3 colors are used to label this entire risk spectrum, evaluators must use their best judgement on how to reflect the degree of risk in every approach to the audience.
There are an infinite number of ways we could divide up these risks. I am of the belief that the gulf between “there exists a set of keys that can steal all your money” and “there doesn’t exist any set of keys that could steal all your money” is significantly larger than the gulf between “the set of keyholders that can steal all your money are trustworthy and have good OpSec” and “the set of keyholders that can steal all your money are not trustworthy or have bad OpSec”.
While I would weakly agree that the zkSync setup is better than the setup of many other projects, I don’t think it is better enough to push it into the next class up, because it doesn’t cross that gigantic divide to “there doesn’t exist any set of keyholders who can instantly steal everything”.
