Hardhat-deploy: Поддержка прокси OpenZeppelin UUPS

Планируется поддержка изначально, но пока все еще можно использовать их с hardhat-deploy. прокси-jist должен иметь фиктивный / неиспользуемый аргумент владельца в своем конструкторе, чтобы оставаться совместимым.

прокси-jist должен иметь фиктивный / неиспользуемый аргумент владельца в своем конструкторе, чтобы оставаться совместимым.

Разве это не сделало бы использование UUPS бесполезным? Причина использования UUPS состоит в том, чтобы сэкономить газ на вызовах транзакций, поскольку прокси-серверу не нужно проверять, совершает ли вызов администратор.

Может быть, мне это не хватает, не могли бы вы уточнить с помощью какого-нибудь псевдокода, как использовать hardhat-deploy с прокси-серверами uups (с неиспользованным аргументом)?

Спасибо

Это не повлияет на газ, это просто фиктивный аргумент, так что hardhat-deploy может развернуть его без изменения кода. конструктору не нужно ничего делать с этим аргументом.
Посмотрим, смогу ли я внести изменения, чтобы они работали без каких-либо изменений в ближайшее время. это должно быть небольшое изменение, в котором вы можете указать аргумент конструктора для прокси или, возможно, просто указать, что это прокси UUPS

Спасибо @wighawag , наконец-то добрались до этого.

Для желающих я создал этот контракт:

pragma solidity ^0.8.0;

import "@openzeppelin/contracts/proxy/ERC1967/ERC1967Proxy.sol";

// Kept for backwards compatibility with older versions of Hardhat and Truffle plugins.
contract UUPSProxy is ERC1967Proxy {
  constructor(
    address _logic,
    address, // This is completely unused by the uups proxy, required to remain compatible with hardhat deploy: https://github.com/wighawag/hardhat-deploy/issues/146
    bytes memory _data
  ) payable ERC1967Proxy(_logic, _data) {}
}

И тогда мои развертывания выглядят примерно так ( proxyContract: "UUPSProxy" - важная часть):

  await deploy(CONTRACT, {
    from: deployer,
    proxy: {
      proxyContract: "UUPSProxy",
      // ... your other config, initializers etc
    },
    log: true,
  });

@JasoonS Пожалуйста, не могли бы вы уточнить назначение этого кода контракта UUPSProxy ? Это просто фиктивный контракт, чтобы hardhat-deploy знал интерфейс реального конструктора прокси? Или это действительно как-то связано с развертываемым прокси-контрактом?

Какова именно роль admin , я получаю сообщение об ошибке независимо от того, есть ли там deployer (= администратор обновления) или если я опускаю поле.

proxy: {
      proxyContract: "UUPSProxy",
      execute: {
        methodName: "initialize",
        args: [admin],
      },
    },

@marceljay Пожалуйста (всегда) вставляйте ошибки, которые вы получаете :-)

Привет, @aspiers , я еще не

Итак, чтобы заставить эту работу работать с hardhat-deploy, мы развертываем его с тем же конструктором, что и прозрачный прокси, но мы просто игнорируем поле администратора и получаем тот же эффект.

Кажется, у меня работает @marceljay

Отказ от ответственности, мой фрагмент кода не проверяется: sweat_smile: - Я не несу ответственности за плохо настроенные прокси: смеется:

@marceljay Ах, да, я могу догадаться о вашей проблеме. Я отредактировал свой исходный ответ.

В следующем коде показано, что делать с реализацией. Итак, у меня есть функция реализации (а не прокси), называемая инициализацией, которая принимает 1 аргумент (администратор).

execute: {
  methodName: "initialize",
  args: [admin],
},

@marceljay Ах, да, я могу догадаться о вашей проблеме. Я отредактировал свой исходный ответ.

В следующем коде показано, что делать с реализацией. Итак, у меня есть функция реализации (а не прокси), называемая инициализацией, которая принимает 1 аргумент (администратор).

execute: {
  methodName: "initialize",
  args: [admin],
},

Да, теперь это имеет смысл, видел, как вы редактировали ответ :)

Знаете ли вы, что ERC1967Proxy тот же, что используется плагином обновлений OZ?

@JasoonS Большое спасибо за объяснения , но я до сих пор не в полной мере получить его. Выше вы разместили контракт, начинающийся:

contract UUPSProxy is ERC1967Proxy {

Действительно ли это await deploy вы разместили выше, или это просто фиктивный контракт, чтобы hardhat-deploy знал интерфейс фактического конструктора прокси, или что-то еще? Вы написали:

разворачиваем с тем же конструктором, что и прозрачный прокси

но если это действительно развертывание, тогда я не понимаю, как это могло бы работать, потому что этот контракт наследуется от ERC1967Proxy не UUPSUpgradeable , так откуда же взяться фактическая функциональность UUPS?

Действительно ли это действительно развертывается с помощью образца кода ожидания развертывания, который вы опубликовали выше

Да, он действительно его разворачивает.

потому что этот контракт наследуется от ERC1967Proxy не UUPSUpgradeable

Предполагается использовать ERC1967Proxy (как UUPS, так и прозрачные прокси из openzeppelin используют erc1967, https://docs.openzeppelin.com/contracts/4.x/api/proxy#transparent-vs-uups). Контракт UUPSUpgradeable используется контрактом реализации (он не является частью прокси).

так откуда взяться фактической функциональности UUPS?

По дизайну контракт реализации содержит функциональность UUPS (что хорошо, потому что он более эффективен, поскольку логика не находится в самом прокси, но плохо, потому что можно по ошибке перейти на несовместимый контракт и нарушить возможность обновления. ).

Кроме того, я определенно не эксперт по прокси, это просто мое собственное исследование.

@JasoonS прокомментировал 1 сентября 2021 г., 21:18 :

потому что этот контракт наследуется от ERC1967Proxy не UUPSUpgradeable

Предполагается использовать ERC1967Proxy (как UUPS, так и прозрачные прокси из openzeppelin используют erc1967, docs.openzeppelin.com/contracts/4.x/api/proxy#transparent-vs-uups ).

Верно. И ERC-1967 ничего не делает, кроме указания места хранения адреса реализации, адреса маяка и адреса администратора. Кстати, забавный факт, который я заметил: в соответствии с ERC-1967 реализация OZ UUPS фактически нарушает EIP1822, который указывает немного другое место хранения для адреса реализации.

Контракт UUPSUpgradeable используется контрактом реализации (он не является частью прокси).

Да, конечно! Спасибо, что помог мне увидеть, чего я здесь по глупости упустил.

так откуда взяться фактической функциональности UUPS?

По дизайну контракт реализации содержит функциональность UUPS (что хорошо, потому что он более эффективен, поскольку логика не находится в самом прокси, но плохо, потому что можно по ошибке перейти на несовместимый контракт и нарушить возможность обновления. ).

Да, поэтому реализация должна наследовать от UUPSUpgradeable .

Еще раз большое спасибо за эту огромную помощь!