Make it not possible to transferOwnership

[PaulRBerg]

Proposal

Transferring ownership comes with the trade-off of making the currentProxies mapping in the registry contract outdated (as indicated by @razgraf in private discussions about PRBProxy).

What if we got rid of transferOwnership? There would be no other way to transfer the owner, since the fallback function and the execute function disallow any transfer of ownership.

Note: this idea is complementary to #79. Feedback welcome from @razgraf and @SolcAndMe (sorry to tag you, again, guys!).

Pro

• No more outdated entries in currentProxies
• Reduced deployment cost

Cons

• The ability to transfer ownership of a proxy may be useful in certain cases, e.g. when migrating your personal crypto wallets.

[SolcAndMe]

Responding to both #80 and #79 here: My preference would be to stop tracking ownership in the registry and or factory and keep transferOwnership. Semantically you could keep the currentProxies mapping by renaming it to lastDeployedProxy or something similar. In the end a dev user still has to double check the emitted events.

[PaulRBerg]

Thanks, @SolcAndMe, but I need help understanding this idea.

The fact that the registry maps owners to proxies is part of why it exists. Specifically, the registry is meant to provide a way to identify a unique proxy associated with a given user. Otherwise, frontends wouldn't be able to know what proxy should be retrieved for each user.

[SolcAndMe]

Otherwise, frontends wouldn't be able to know what proxy should be retrieved for each user.

Yes, though as you said because the record is not updated in the Registry, if the user does change ownership, frontends still need to check for any TransferOwnership to be 100% sure that a Proxy corresponds to an EOA. And because they have to do so either way - then relying solely on events would not be a huge stretch. But then also if we just change the terminology from currentProxies to lastDeployedProxies instead of removing it in the Registry (or Factory) the original v3 flow would remain intact.

[PaulRBerg]

frontends still need to check for any TransferOwnership

They don't need to check for that event. They can just call owner() on the proxy.

then relying solely on events would not be a huge stretch

I don't see how this is possible. With the registry, yes, you also need to call owner, but at least you have a "foothold" in knowing what proxy to call in the first place.

if we just change the terminology from currentProxies to lastDeployedProxies

I see. So you still recommend keeping the users as keys in lastDeployedProxies?

[SolcAndMe]

They don't need to check for that event. They can just call owner() on the proxy.

True!

I see. So you still recommend keeping the users as keys in lastDeployedProxies?

Yes, it would just be a change in terminology.

[PaulRBerg]

I see! Thanks for explaining.

[razgraf]

Did you consider separating the tracking and the deployment?

1. allow everyone to deploy as many proxies as they wish
2. have the Registry track proxy addresses in a "reverse resolution" sense. Think of it like ENS, you get to pick a "go-to" proxy for your address, that all apps may point to.

You could include a setLeadProxy type of system with the optional set in the create method of the Factory. There's still the problem of transfer ownership (a lead proxy can be transferred without the registry knowing), but I guess you could simply embed extra check logic into the Registry getter (check if proxyMapping[account].owner() === account).

[PaulRBerg]

What you described is pretty much the same as it works now, except that the registry automatically sets the "lead proxy" for the user. Asking the user to manually set the "lead proxy" is a step backward from a UX perspective.

[razgraf]

Not quite, right now you cannot change back and forth between a "lead proxy". Also, you can solve the step back by automatically assigning a new proxy as "lead" if the user doesn't have one in the mapping (or the current one is wrong). That is if the Registry and Factory are still one contract.

[PaulRBerg]

Not quite, right now you cannot change back and forth between a "lead proxy"

Fine, but I don't see what is the use case for this.

you can solve the step back by automatically assigning a new proxy as "lead" if the user doesn't have one in the mapping

I didn't understand this point. Could you please restate it?

[razgraf]

The use case is having a simpler and clearer reverse mapping of primary proxy contracts.

step backward
Ok, trying to simplify my thought process. I find the current system unclear. The currentProxies aren't intuitive. I'm simply trying to suggest a simpler alternative, let's start with that.

[PaulRBerg]

Eventually I did not remove the transferOwnership function, but I moved it to the registry so that the proxies mapping gets updated every time ownership of the proxy is transferred. For more details, see this PR:

#81.