Hardhat-deploy: OpenZeppelin UUPS 프록시 지원

기본적으로 지원할 계획이지만 현재로서는 hardhat-deploy와 함께 사용할 수 있습니다. 프록시 jist는 호환성을 유지하기 위해 생성자에 더미/미사용 소유자 인수가 있어야 합니다.

프록시 jist는 호환성을 유지하기 위해 생성자에 더미/미사용 소유자 인수가 있어야 합니다.

UUPS를 사용하는 것이 더 이상 도움이 되지 않습니까? UUPS를 사용하는 이유는 프록시가 호출하는 관리자인지 확인할 필요가 없기 때문에 트랜잭션 호출에 가스를 절약하기 위한 것입니다.

내가 놓친 것일 수도 있습니다. 의사 코드로 uups 프록시(사용하지 않는 인수 포함)와 함께 hardhat-deploy를 사용하는 방법을 자세히 설명할 수 있습니까?

감사 해요

그것은 가스에 영향을 미치지 않으며 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 (=upgrade admin) 또는 필드를 생략해도 오류가 발생합니다.

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

@marceljay 발생한 오류를 (항상) 붙여넣으세요 :-)

안녕하세요 @aspiers , 저는 hardhat-deploy를 깊이 파고 들지 않았으므로 @wighawag를 수정하십시오. 그러나 내가 이해한 바에 따르면 투명한 프록시를 배포하는 방법을 알고 있습니다. 투명 프록시는 해당 프록시를 관리하는 관리자와 함께 배포됩니다. UUPS 계약에는 업그레이드를 관리하는 외부 계약(프록시 관리자)이 없으며 구현 자체에 있으므로 프록시 생성자로 전달되지 않습니다.

따라서 hardhat-deploy로 이 작업을 수행하려면 투명 프록시와 동일한 생성자를 사용하여 배포하지만 admin 필드를 무시하고 동일한 효과를 얻습니다.

나를 위해 일하는 것 같습니다 @marceljay

면책 조항 내 코드 조각이 감사되지 않습니다 :sweat_smile: - 잘못 구성된 프록시에 대해 책임을 지지 않습니다 :laughing:

@marceljay 아, 네, 귀하의 문제를 추측할 수 있습니다. 원래 답변을 수정했습니다.

다음 코드는 구현에서 수행할 작업입니다. 그래서 1개의 인수(관리자)를 취하는 initialize라는 구현(프록시가 아님)에 대한 함수가 있습니다.

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

@marceljay 아, 네, 귀하의 문제를 추측할 수 있습니다. 원래 답변을 수정했습니다.

다음 코드는 구현에서 수행할 작업입니다. 그래서 1개의 인수(관리자)를 취하는 initialize라는 구현(프록시가 아님)에 대한 함수가 있습니다.

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

예, 이제 완벽하게 이해되었습니다. 답변을 수정한 것을 보았습니다. :)

ERC1967Proxy 계약이 OZ 업그레이드 플러그인에서 사용하는 것과 동일한지 알고 계십니까?

@JasoonS 많은 설명 감사합니다만 아직 완전히 이해가 되지 않습니다. 위에서 다음과 같이 시작하는 계약을 게시했습니다.

contract UUPSProxy is ERC1967Proxy {

위에 게시한 샘플 await deploy 코드에 의해 실제로 배포 됩니까, 아니면 hardhat-deploy가 실제 프록시 생성자의 인터페이스를 알도록 하는 더미 계약입니까, 아니면 다른 것입니까? 당신은 썼다:

투명 프록시와 동일한 생성자를 사용하여 배포합니다.

그러나 실제로 배포하는 경우 해당 계약이 ERC1967Proxy 아닌 UUPSUpgradeable ERC1967Proxy 에서 상속되므로 실제 UUPS 기능은 어디에서 올까요?

위에 게시한 배포 코드를 기다리는 샘플에 의해 실제로 배포됩니까?

예, 실제로 배포합니다.

해당 계약은 UUPSUpgradeable이 아닌 ERC1967Proxy에서 상속되기 때문입니다.

ERC1967Proxy(UUPS와 openzeppelin의 투명 프록시 모두 erc1967, https://docs.openzeppelin.com/contracts/4.x/api/proxy#transparent-vs-uups 사용)를 사용해야 합니다. UUPSUpgradeable 계약은 구현 계약에서 사용됩니다(프록시의 일부가 아님).

그렇다면 실제 UUPS 기능은 어디에서 오는 것일까요?

설계상 구현 계약은 UUPS 기능을 보유합니다(이는 로직이 프록시 자체에 없기 때문에 가스 효율적이기 때문에 좋지만 실수로 호환되지 않는 계약으로 업그레이드하고 업그레이드 가능성을 깨뜨릴 수 있기 때문에 나쁩니다. ).

또한, 나는 확실히 프록시 전문가가 아닙니다. 이것은 제 자신의 연구에서 나온 것입니다.

@JasoonS가 2021년 9월 1일 오후 9시 18분 에 댓글을 작성했습니다.

해당 계약은 UUPSUpgradeable이 아닌 ERC1967Proxy에서 상속되기 때문입니다.

ERC1967Proxy (모두 UUPS 및 openzeppelin 사용 erc1967에서 투명 프록시를 사용하도록되어 docs.openzeppelin.com/contracts/4.x/api/proxy#transparent-vs-uups을 ).

오른쪽. 그리고 ERC-1967은 구현 주소, 비콘 주소 및 관리자 주소의 저장 위치를 ​​지정하는 것 외에는 많은 기능을 하지 않습니다. BTW 재미있는 사실: ERC-1967을 준수하면서 OZ UUPS 구현은 실제로 구현 주소에 대해 약간 다른 저장 위치를 ​​지정하는 EIP1822를 위반합니다.

UUPSUpgradeable 계약은 구현 계약에서 사용됩니다(프록시의 일부가 아님).

물론이죠! 내가 어리석게 여기에서 놓친 것을 볼 수 있도록 도와주셔서 감사합니다.

그렇다면 실제 UUPS 기능은 어디에서 오는 것일까요?

설계상 구현 계약은 UUPS 기능을 보유합니다(이는 로직이 프록시 자체에 없기 때문에 가스 효율적이기 때문에 좋지만 실수로 호환되지 않는 계약으로 업그레이드하고 업그레이드 가능성을 깨뜨릴 수 있기 때문에 나쁩니다. ).

예, 구현은 UUPSUpgradeable 에서 상속해야 합니다.

이 큰 도움에 다시 한번 감사드립니다!