Hardhat-deploy: Soporte de proxy OpenZeppelin UUPS

Planeando brindar soporte de forma nativa, pero por ahora todavía es posible usarlos con hardhat-deploy. el proxy jist necesita tener un argumento propietario ficticio / no utilizado en su constructor para seguir siendo compatible.

el proxy jist necesita tener un argumento propietario ficticio / no utilizado en su constructor para seguir siendo compatible.

¿No haría eso que usar UUPS ya no sea beneficioso? La razón para usar UUPS es ahorrar gas en las llamadas de transacciones porque el proxy no necesita verificar si es el administrador quien realiza la llamada.

Tal vez me lo pierda, ¿podría explicar con un pseudocódigo cómo usar hardhat-deploy con proxies uups (con el argumento no utilizado)?

Gracias

No afectará al gas, es solo un argumento ficticio para que hardhat-deploy pueda implementarlo sin cambiar el código. el constructor no necesita hacer nada con ese argumento.
Voy a ver si puedo hacer el cambio para que funcione sin ningún cambio pronto. debería ser un pequeño cambio donde puede especificar el constructor arg para el proxy o tal vez simplemente especificar que es un proxy UUPS

Gracias @wighawag ,

Para los interesados ​​creé este contrato:

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) {}
}

Y luego mis implementaciones se parecen a esto ( proxyContract: "UUPSProxy" es la parte importante):

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

@JasoonS ¿ Puede aclarar el propósito de ese código de contrato UUPSProxy ? ¿Es solo un contrato ficticio para que hardhat-deploy conozca la interfaz del constructor del proxy real? ¿O realmente se relaciona de alguna manera con el contrato de proxy que se implementa?

¿Cuál es exactamente el rol de admin Recibo un error sin importar si está allí, el deployer (= actualizar administrador) o si omito el campo.

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

@marceljay Por favor (siempre) pegue los errores que obtenga :-)

Hola @aspiers , no he

Entonces, para que esto funcione con hardhat-deploy, lo implementamos con el mismo constructor que un proxy transparente, pero simplemente ignoramos el campo de administración y obtenemos el mismo efecto.

Parece estar funcionando para mí @marceljay

Descargo de responsabilidad mi fragmento de código no está auditado: sweat_smile: - No asumo ninguna responsabilidad por proxies mal configurados: riendo:

@marceljay Ah, sí, puedo adivinar tu problema. Edité mi respuesta original.

El siguiente código es lo que se debe hacer en la implementación. Entonces tengo una función en la implementación (no el proxy) llamada initialize que toma 1 argumento (el administrador).

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

@marceljay Ah, sí, puedo adivinar tu problema. Edité mi respuesta original.

El siguiente código es lo que se debe hacer en la implementación. Entonces tengo una función en la implementación (no el proxy) llamada initialize que toma 1 argumento (el administrador).

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

Sí, ahora tiene mucho sentido, te vi editado la respuesta :)

¿Sabe si el ERC1967Proxy es el mismo que utiliza el complemento de actualizaciones OZ?

Una gran cantidad de las explicaciones, pero yo todavía no entiendo totalmente que @JasoonS Gracias. Arriba publicaste un contrato que comienza:

contract UUPSProxy is ERC1967Proxy {

¿Eso realmente se implementa de verdad con el código de muestra await deploy que publicó anteriormente, o es solo un contrato ficticio para que hardhat-deploy conozca la interfaz del constructor del proxy real, o algo más? Tu escribiste:

lo implementamos con el mismo constructor que un proxy transparente

pero si realmente está implementando eso, entonces no veo cómo podría funcionar, porque ese contrato hereda de ERC1967Proxy no UUPSUpgradeable , entonces, ¿de dónde vendría la funcionalidad UUPS real?

¿Eso realmente se implementa de verdad con el código de implementación de espera de muestra que publicó anteriormente?

Sí, realmente lo implementa.

porque ese contrato hereda de ERC1967Proxy no UUPSUpgradeable

Se supone que usa el ERC1967Proxy (tanto UUPS como proxies transparentes de openzeppelin usan erc1967, https://docs.openzeppelin.com/contracts/4.x/api/proxy#transparent-vs-uups). El contrato de implementación utiliza el contrato UUPSUpgradeable (no forma parte del proxy).

entonces, ¿de dónde vendría la funcionalidad UUPS real?

Por diseño, el contrato de implementación tiene la funcionalidad UUPS, (lo cual es bueno porque es más eficiente en gas ya que la lógica no está en el proxy en sí, pero es malo porque es posible actualizar a un contrato no compatible por error y romper la capacidad de actualización ).

Además, definitivamente no soy un experto en proxies, esto es solo de mi propia investigación.

@JasoonS comentó el 1 de septiembre de 2021 a las 21:18 :

porque ese contrato hereda de ERC1967Proxy no UUPSUpgradeable

Se supone que usa el ERC1967Proxy (tanto UUPS como proxies transparentes de openzeppelin usan erc1967, docs.openzeppelin.com/contracts/4.x/api/proxy#transparent-vs-uups ).

Derecha. Y ERC-1967 no hace mucho, excepto especificar la ubicación de almacenamiento de la dirección de implementación, la dirección de baliza y la dirección de administrador. Por cierto, un dato curioso que noté: al cumplir con ERC-1967, la implementación de OZ UUPS en realidad viola EIP1822, que especifica una ubicación de almacenamiento ligeramente diferente para la dirección de implementación.

El contrato de implementación utiliza el contrato UUPSUpgradeable (no forma parte del proxy).

¡Oh, por supuesto! Gracias por ayudarme a ver lo que me estaba perdiendo estúpidamente aquí.

entonces, ¿de dónde vendría la funcionalidad UUPS real?

Por diseño, el contrato de implementación tiene la funcionalidad UUPS, (lo cual es bueno porque es más eficiente en gas ya que la lógica no está en el proxy en sí, pero es malo porque es posible actualizar a un contrato no compatible por error y romper la capacidad de actualización ).

Sí, entonces la implementación tiene que heredar de UUPSUpgradeable .

¡Muchas gracias de nuevo por esta gran ayuda!