Hardhat-deploy: 업그레이드 가능한 계약 배포에 대한 질문

hardhat-deploy가 기본적으로 배포 스크립트를 고려하는 방식은 멱등성입니다. 프록시 배포에도 동일하게 적용됩니다. 이것은 당신이 원하는 상태에 대해서만 생각하면 되고 hardhat-deploy가 모든 것을 그 상태에 도달하도록 만들 것이므로 개발/배포에 유용합니다.

그래서 귀하의 질문에 대답하기 위해, 제가 일반적으로 하는 일은 초기화 기능을 멱등성으로 만드는 것이므로 이미 초기화된 경우 그냥 건너뛰는 대신 던지십시오. 따라서 해당 기능을 postUpgrade 기능으로 추가할 수 있으며 모두 잘 작동합니다. 개발 중에 필요한 경우 업그레이드할 때 작업을 수행하도록 초기화 기능을 변경할 수도 있습니다.

더 복잡한 시나리오의 경우 각 업그레이드를 별도의 배포 스크립트로 구성할 수 있습니다.

변경될 수 있는 문서화되지 않은 기능이 있습니다. upgradeIndex 매개변수를 사용하면 순서대로 실행해야 하는 배포 스크립트를 지정할 수 있습니다.

업그레이드 기록 사이의 어느 시점에서나 yoru 프록시를 테스트하고 모든 작동을 확인할 수 있으므로 테스트에 적합합니다.

빠른 답변 감사합니다.
모든 작업을 원활하게 수행할 수 있었던 것 같습니다. OpenZeppelin Initializable 기본 계약의 initialize deploy() 를 사용한 다음 execute 를 사용합니다. execute() 는 true를 반환하므로 계약을 업그레이드할 때 실행되지 않습니다.

// deploy/01_deploy_skin_rewards.js

module.exports = async ({
  getNamedAccounts,
  deployments,
}) => {
  const {deploy} = deployments;
  const {deployer} = await getNamedAccounts();
  await deploy('SkinRewards', {
    from: deployer,
    proxy: {
      owner: deployer,
      proxyContract: 'OpenZeppelinTransparentProxy',
    },
    args: [],
    log: true,
  });
};
module.exports.tags = ['SkinRewards'];

그리고

// deploy/02_init_skin_rewards.js

require('dotenv').config();
const RewardPeriods = ethers.BigNumber.from(process.env.REWARD_PERIODS);
module.exports = async ({getNamedAccounts, deployments}) => {
  const { deployer } = await getNamedAccounts();
  const SnookGame = await deployments.get('SnookGame');
  const SnookState = await deployments.get('SnookState');
  const SnookToken = await deployments.get('SnookToken');
  const SkillToken = await deployments.get('SkillToken');
  const Afterdeath = await deployments.get('Afterdeath');
  const Treasury = await deployments.get('Treasury');

  await deployments.execute(
    'SkinRewards',
    {from:deployer},
    'initialize',
    RewardPeriods,
    Treasury.address,
    SnookGame.address,
    SnookState.address,
    SnookToken.address,
    SkillToken.address,
    Afterdeath.address
  );
  deployments.log('Initialized SkinRewards');
  return true;
};
module.exports.tags = ['initSkinRewards'];
module.exports.id = 'initSkinRewards';

이 방법이 _좋은 습관_으로 간주될 수 있습니까? 당신이 그것을 찾는 방법입니까?

위에서 언급했듯이 SkinRewards 에서는 initialize() 함수가 먼저 호출되도록 정의하는 OpenZeppelin의 Initializable 계약을 상속합니다. 따라서 사후 업그레이드를 실행하는 방법을 알 수 없습니다. 설명해주실 수 있나요? 감사 해요

좋은 것 같습니다. methodName ("postUpgrade")를 사용하는 것과 비교할 때 단점은 1 대신 2 tx를 실행한다는 것입니다.

초기화 함수를 멱등수로 만들면 추가 호출이 상태를 수정하지 않는지 확인하여 던지지 않고 여러 번 호출할 수 있습니다(이미 초기화된 경우 건너뛰기). 그러면 methodName 옵션을 통해 사용할 수 있습니다. . 첫 번째 배포에서도 실행됩니다.

인수를 사용하고 배포 기능이 설정되어 프록시 옵션을 끄고 변경할 수 없는 계약이 작동하도록 하기 때문에 methodName #$ 옵션은 인수에 args 옵션을 사용합니다.
이는 프록시 구현의 생성자에도 이러한 인수가 있어야 함을 의미합니다. 프록시 없이 계약을 사용하지 않으려면 인수로 아무 것도 할 수 없습니다.

실제로 편의를 위해 구현 계약에 arg construtcor가 0이면 생성자를 완전히 무시하지만 그것이 좋은 생각인지 확신할 수 없습니다.

methodName 옵션이 있는 스크립트는 다음과 같습니다.

// deploy/01_deploy_skin_rewards.js

module.exports = async ({
  getNamedAccounts,
  deployments,
}) => {
  const {deploy} = deployments;
  const {deployer} = await getNamedAccounts();
  await deploy('SkinRewards', {
    from: deployer,
    proxy: {
      methodName: 'initialize`,
      owner: deployer,
      proxyContract: 'OpenZeppelinTransparentProxy',
    },
    args: [
      RewardPeriods,
      Treasury.address,
      SnookGame.address,
      SnookState.address,
      SnookToken.address,
      SkillToken.address,
      Afterdeath.address
    ],
    log: true,
  });
};
module.exports.tags = ['SkinRewards'];

_초기화 함수를 멱등성으로 만드는 경우, 즉 추가 호출이 상태를 수정하지 않는지 확인하여(이미 초기화된 경우 단순히 건너뛰어) throw하지 않고 여러 번 호출할 수 있으면 methodName 옵션을 통해 사용할 수 있습니다. 첫 번째 배포에서도 실행됩니다._

즉, https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable/blob/release-v4.0/contracts/proxy/utils/Initializable.sol 에서 initialize() 함수를 그대로 사용할 수 없습니다. .

@freebyte 참으로

나는 이런 종류의 행동을 얻기 위해 옵션을 추가하는 것을 고려할 것입니다.

좋아요, 감사합니다!

또 다른 질문은 배포된 계약 사용에 관한 것입니다. 특히 Uniswap 에 대해 묻고 있습니다.

플러그인 문서 의 이 부분에서 배포된 Uniswap 계약의 주소를 제공하는 방법을 볼 수 없습니다. Uniswap NPM은 아티팩트가 있는 build 폴더와 함께 제공되지만 플러그인이 특정 주소의 계약에 대해 알도록 하려면 어떻게 해야 합니까? 우리는 배포 스크립트에서 ether를 사용하고 싶지 않습니다. 그렇죠?

다음 코드는 배포 스크립트에서 원하는 것이 아닙니다.

const { ethers } = require("hardhat");

const UniswapV2FactoryArtifact = require('@uniswap/v2-core/build/UniswapV2Factory.json');
const UniswapV2FactoryAddress = '0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f';

module.exports = async ({getNamedAccounts, deployments}) => {
  const {deployer} = await getNamedAccounts();
  const UniswapFactory = await ethers.getContractAt(UniswapV2FactoryArtifact.abi, UniswapV2FactoryAddress);
// continue...

deployments var에 Uniswap 배포를 가져오려면 어떻게 합니까?

이미 배포된 계약의 경우 해당 배포 폴더에 파일을 만드는 것이 가장 좋습니다.
따라서 메인넷 uniswap의 경우 hardhat.config.js에 메인넷 네트워크가 구성되어 있다고 가정하면 "deployments/mainnet/UniswapFactory.json" 파일을 생성할 수 있습니다. 최소한 주소와 BI 필드가 필요합니다.

그런 다음 해당 네트워크에 있을 때 배포를 통해 액세스할 수 있습니다.

아티팩트(uniswap 빌드 폴더)에 액세스하거나 스크립트를 배포할 수 있도록 가리키는 문서 링크, 그러나 후자는 해당 프로젝트가 이러한 배포 스크립트를 어딘가에 노출한 경우에만 작동합니다.

https://github.com/wighawag/universal-forwarder 와 같은 내 프로젝트에서 이를 수행하여 사용자가 npm 패키지를 설치하기만 하면 전체 프로젝트를 테스트 또는 자체 네트워크에 배포할 수 있습니다. 그러나 uniswap은 그것을 제공하지 않습니다

엄청난. 정말 감사합니다.

프록시에 대한 재초기화 기능

hardhat-deploy 0.8.0에 새 옵션(아직 사용 가능한 methodName 대신)을 추가했습니다.

https://github.com/wighawag/template-ethereum-contracts/blob/595c1b5ec9cdf1276f4d3a43b4825bcef78bd2cd/deploy/004_deploy_erc20_always_proxied_via_openzeppelin#_proxy.ts 를 참조하십시오

문제가 발생하면 알려주십시오.