InitializableAdminUpgradeabilityProxy in solc 0.7?

alsco77 · January 7, 2021, 8:50am

I am upgrading an environment containing proxies from solc 0.5.x to 0.7.x. Previously, the proxy contracts were created using InitializableAdminUpgradeabilityProxy from "@openzeppelin/upgrades": "2.7.2", however it appears that the library has been deprecated in favour of native hardhat integration.

Environment

    "@openzeppelin/contracts": "3.3.0",
    "@openzeppelin/upgrades": "2.7.2",
    "hardhat": "^2.0.3",

Details

While I can see the benefit long term from creating better DX during testing and development, this limits my ability to do manual deployments for single contract deployments, or contracts that have nested dependencies (i.e. the initialize fn of one relies on the proxy address of another). Also It would be great for me to retain backwards compatibility in the codebase to ensure that subsequent upgrades on existing contracts go smoothly.

Are there any branches with 0.7.x ports of the contracts in question?

abcoathup · January 7, 2021, 11:14pm

Hi @alsco77,

As an aside, you should be able to do nested deployments using the Upgrades Plugins for Truffle or Hardhat.

The proxy contracts that were in OpenZeppelin Upgrades library have been added to OpenZeppelin Contracts. See: Building for interoperability: why we’re focusing on Upgrades Plugins

There is a Solidity 0.7 tagged release of OpenZeppelin Contracts.

github.com

OpenZeppelin/openzeppelin-contracts/blob/v3.3.0-solc-0.7/contracts/proxy/TransparentUpgradeableProxy.sol

// SPDX-License-Identifier: MIT

pragma solidity ^0.7.0;

import "./UpgradeableProxy.sol";

/**
 * @dev This contract implements a proxy that is upgradeable by an admin.
 * 
 * To avoid https://medium.com/nomic-labs-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357[proxy selector
 * clashing], which can potentially be used in an attack, this contract uses the
 * https://blog.openzeppelin.com/the-transparent-proxy-pattern/[transparent proxy pattern]. This pattern implies two
 * things that go hand in hand:
 * 
 * 1. If any account other than the admin calls the proxy, the call will be forwarded to the implementation, even if
 * that call matches one of the admin functions exposed by the proxy itself.
 * 2. If the admin calls the proxy, it can access the admin functions, but its calls will never be forwarded to the
 * implementation. If the admin tries to call a function on the implementation it will fail with an error that says
 * "admin cannot fallback to proxy target".
 *

This file has been truncated. show original

Please note, the Upgrades Plugins don’t currently use the proxy contracts from OpenZeppelin Contracts. They use a variant (prior to migration to OpenZeppelin Contracts) that is for Solidity 0.6.

github.com

OpenZeppelin/openzeppelin-upgrades/blob/@openzeppelin/upgrades-core@1.4.3/packages/core/contracts/proxy/AdminUpgradeabilityProxy.sol

// SPDX-License-Identifier: MIT

pragma solidity ^0.6.0;

import './UpgradeabilityProxy.sol';

/**
 * @title AdminUpgradeabilityProxy
 * @dev This contract combines an upgradeability proxy with an authorization
 * mechanism for administrative tasks.
 * All external functions in this contract must be guarded by the
 * `ifAdmin` modifier. See ethereum/solidity#3864 for a Solidity
 * feature proposal that would enable this to be done automatically.
 */
contract AdminUpgradeabilityProxy is UpgradeabilityProxy {
  /**
   * Contract constructor.
   * @param _logic address of the initial implementation.
   * @param _admin Address of the proxy administrator.
   * @param _data Data to send as msg.data to the implementation to initialize the proxied contract.

This file has been truncated. show original

frangio · January 8, 2021, 5:16pm

@alsco77 The “initializable” variant of the proxies was not migrated to OpenZeppelin Contracts, only the proxies that have a constructor.

Do you need the initializable variant? Please share more about your use case so we can figure out the best suggestion for you.

alsco77 · January 18, 2021, 2:15am

@frangio @abcoathup Hey guys! Thanks for getting back to me

Hmm. I don’t think its a necessity for me anymore… I was hoping to maintain backwards compatibility in the codebase itself, however since we aren’t re-deploying the proxy contracts, it shouldn’t affect the existing contract storage layout/functionality (although it’s always nice to test with the real thing).

Thanks for the info - will ping back here with more specifics if my current plan doesn’t work out