Compatible with 4.0.0, custom proxyAdmin upgrade contract

[Smilestate]

version：5.0.0

🧐 Motivation
When I used the above version of the proxy contract, I was surprised to find that deploying the proxy contract would trigger the deployment of the proxyAdmin contract and give the proxy upgrade permission to proxyAdmin. I think it is unreasonable. If there are many proxy contracts in my project, I There are many admin contract addresses to remember.

📝 Details
I saw the constructors logic, admin, and data of the transparent proxy in the previous version. Among them, admin is the proxyAdmin contract address. It is possible to manage multiple agency contracts with one admin contract. But in the latest version, I found that the constructor is logic, owner, data, where owner is the manager who automatically deploys admin. That is to say, each agent contract will deploy an admin contract internally for management and upgrade. However, there is no external method to obtain the admin contract address, and it can only be viewed through the released changeAdmin event.

`/**

• @dev Returns the admin of this proxy.
  */
  function _proxyAdmin() internal virtual returns (address) {
  return _admin;
  }
  Added method to obtain proxyAdmin!

constructor(address _logic, address initialOwner, bytes memory _data) payable ERC1967Proxy(_logic, _data) {
_admin = address(new ProxyAdmin(initialOwner));
// Set the storage value and emit an event for ERC-1967 compatibility
ERC1967Utils.changeAdmin(_proxyAdmin());
}

constructor(address logic, address admin, bytes memory _data) payable ERC1967Proxy(_logic, _data) {
changeAdmin(admin);
}
Or adjust the constructor to the specified proxyAdmin contract address that has been deployed.
`
I hope it can be updated as soon as possible, because it is a headache for users to deploy multiple agents and have multiple management contracts! Hope to adopt!

[changeset-bot]

⚠️ No Changeset found

Latest commit: 78999c8

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[ernestognw]

Hi @Smilestate,

This is a deliberate design decision. Considering your comments, the two alternatives to consider are the current implementation vs one where the proxy admin can be changed.

On one side, the current implementation costs more on deployment but saves gas in every call that goes through the proxy (i.e. regular users!) since it avoids reading the proxy admin from storage and reads it as an immutable variable instead.

On the other side, allowing changing the proxy admin for consistency purposes only saves gas on construction but loses the immutable access benefits on each call through the proxy.

We think managing multiple proxy admin addresses is a management issue that can be solved with off-chain tooling. Concretely, OpenZeppelin Defender should be a good fit for that.

Given that said, this pull request not only doesn't allow changing the proxy admin, but it adds an extra storage read, which removes the initial reason why changing the proxy admin is disallowed.

I'm closing.