Redesigning the set-admin command

design
proxies
cli

#1

For quite some time, we have had the set-admin command in the ZeppelinOS CLI. This command changes the admin of a proxy to the specified address, and it accepts either the alias or the address of the proxy to affect. As an example:

zos set-admin ERC20 $NEWADMIN # changes all ERC20 proxies to be managed by NEWADMIN
zos set-admin 0x1234 $NEWADMIN # changes the proxy at 0x1234 to be managed by NEWADMIN

Note that there is no way to simultaneously change the admin of all proxies. However, if we follow the same conventions we use on zos update, we could use a --all flag for this, which changes the admin for all proxies individually.

Now, we have the upcoming ProxyAdmin component, that will act as a central admin for all proxies in an application. This means that we now have the option to change the address that manages all proxies by just changing the owner of the ProxyAdmin.

How do we want to support this operation? An option is via a new flag in set-admin, that explains that the admin of all proxies will be moved to a new owner. To avoid confusions with --all, we could use zos set-admin --proxy-admin $NEWADMIN, though it sounds a bit repetitive.

Since we’re at it, we could also add an option to change the owner of the App and Package contracts from the CLI, if the project had been published. We could use a zos set-admin --app $NEWADMIN for this.

We wanted to gather your feedback around this. How do you feel about these new features? Should we add them as flags in the existing set-admin command? Or place them in a new command, such as set-owner, to avoid cluttering a single command? Does it make sense to deprecate the previous usage of changing the admin of individual proxies, in favour of changing the admin of just the ProxyAdmin?

Thanks for reading, and please leave your thoughts below!


#2

What happens if there’s an ERC20 with a proxy admin, and you call zos set-admin ERC20 $NEWADMIN? Would that make the previous proxy admin to no longer have permissions over the ERC20?


#3

That’s correct. The rationale for that is being able to transfer ownership of a single proxy to a separate entity (such as a multisig), while retaining the others under your control. However, now that I write this, I see that the most common use case should be actually transferring the whole ProxyAdmin. WDYT?


#4

I think it could be confusing, and prone to error. By mistake you can transfer only one of your contracts, when you wanted to transfer the proxy administrator. When there is a ProxyAdmin for all the contracts, and you try to transfer a single one, at the very least there should be a confirmation message explaining the situation.

We have two different behaviors, so I’m inclined to have two different commands. However, set-admin and set-proxy-admin are too similar, something smells bad there. Also set-admin and set-owner will seem like synonyms to everybody.

What would you think of something like transfer-ownership?

zos transfer-ownership --proxy-admin $NEWADMIN
zos transfer-ownership ERC20 $NEWADMIN // warns if there’s a proxy admin
zos transfer-ownership --app $NEWADMIN

It is confusing that so many things can be owned, and that you can have different owners for every one. But I guess people will not like to be forced to do everything through a single administrator contract.


#5

I particularly like the warning if there is a proxy admin when transferring an individual contract, I think we should definitely go with it.

About the name, I’d like to avoid the word owner. We have been consistently using admin to refer to the account that manages the proxy, to avoid confusion with the owner from Ownable. However, transfer-admin is a bit misleading; and I wouldn’t just use zos transfer, since it makes you immediately think of an erc20 transfer. That said, I can’t think of any improvements over set-admin.


#6

Yeah, I’m hitting a dead end here. None of the options fully satisfies me, which is not necessarily bad. It might be just one of those features that need a little more docs. Or it might need some UX testing with real users.

One last idea, is it necessary the --proxy-admin flag?

zos set-admin $NEWADMIN # Changes the ProxyAdmin, fails for SimpleProjects.
zos set-admin [alias-or-address] $NEWADMIN # Warns for AppProject and ProxyAdminProject.

#7

Good point. It may not be necessary if we add a confirmation!