Hardhat-deploy: Prise en charge du proxy OpenZeppelin UUPS

Prévoir un support natif mais pour l'instant il est toujours possible de les utiliser avec hardhat-deploy. le proxy jist doit avoir un argument de propriétaire factice/inutilisé dans son constructeur pour rester compatible.

le proxy jist doit avoir un argument de propriétaire factice/inutilisé dans son constructeur pour rester compatible.

Cela ne rendrait-il pas l'utilisation d'UUPS inutile ? La raison d'utiliser UUPS est d'économiser de l'essence sur les appels de transaction, car le proxy n'a pas besoin de vérifier si c'est l'administrateur qui effectue l'appel.

Peut-être que ça me manque, pourriez-vous expliquer avec un pseudo-code comment utiliser hardhat-deploy avec les proxys uups (avec l'argument inutilisé)?

Merci

Cela n'affectera pas le gaz, c'est juste un argument factice afin que hardhat-deploy puisse le déployer sans changement de code. le constructeur n'a pas besoin de faire quoi que ce soit avec cet argument.
Je vais voir si je peux faire le changement pour le faire fonctionner sans aucun changement bientôt. cela devrait être un petit changement où vous pouvez spécifier l'argument constructeur pour le proxy ou peut-être simplement spécifier qu'il s'agit d'un proxy UUPS

Merci @wighawag , parvenu .

Pour ceux que ça intéresse j'ai créé ce contrat :

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

Et puis mes déploiements ressemblent à ceci ( proxyContract: "UUPSProxy" étant la partie importante):

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

@JasoonS Pouvez-vous clarifier le but de ce code de contrat UUPSProxy ? Est-ce juste un contrat fictif pour que hardhat-deploy connaisse l'interface du constructeur du proxy réel ? Ou est-ce réellement lié au contrat de procuration qui est déployé ?

Quel est exactement le rôle de admin , j'obtiens une erreur, peu importe s'il est là, le deployer (=upgrade admin) ou si j'omet le champ.

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

@marceljay Veuillez (toujours) coller la ou les erreurs que vous obtenez :-)

Salut @aspiers , je n'ai pas creusé profondément dans hardhat-deploy, alors corrigez-moi @wighawag. Mais d'après ce que je comprends, il sait comment déployer des proxys transparents. Et des proxys transparents sont déployés avec un administrateur qui gère ces proxys. Dans les contrats UUPS, vous n'avez pas de contrat externe (administrateur proxy) gérant les mises à niveau, il se trouve plutôt dans l'implémentation elle-même - il n'est donc pas transmis au constructeur de proxy.

Donc, pour que cela fonctionne avec hardhat-deploy, nous le déployons avec le même constructeur qu'un proxy transparent, mais nous ignorons simplement le champ admin et obtenons le même effet.

Semble fonctionner pour moi @marceljay

Avis de non -

@marceljay Ah, oui, je peux deviner votre problème. J'ai modifié ma réponse initiale.

Le code suivant est ce qu'il faut faire sur l'implémentation. J'ai donc une fonction sur l'implémentation (pas le proxy) appelée initialize qui prend en 1 argument (l'administrateur).

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

@marceljay Ah, oui, je peux deviner votre problème. J'ai modifié ma réponse initiale.

Le code suivant est ce qu'il faut faire sur l'implémentation. J'ai donc une fonction sur l'implémentation (pas le proxy) appelée initialize qui prend en 1 argument (l'administrateur).

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

Ouais maintenant c'est parfaitement logique, vu que tu as modifié la réponse :)

Savez-vous si le ERC1967Proxy est le même que celui utilisé par le plugin de mise à niveau OZ ?

@JasoonS Merci beaucoup pour les explications mais je ne comprends toujours pas complètement. Ci-dessus vous avez posté un contrat commençant :

contract UUPSProxy is ERC1967Proxy {

Est-ce que cela est réellement déployé par l'exemple await deploy code

nous le déployons avec le même constructeur qu'un proxy transparent

mais si c'est vraiment le déploiement, je ne vois pas comment cela pourrait fonctionner, car ce contrat hérite de ERC1967Proxy non de UUPSUpgradeable , alors d'où viendrait la fonctionnalité UUPS réelle ?

Est-ce que cela est réellement déployé par l'exemple de code de déploiement d'attente que vous avez publié ci-dessus

Oui, il le déploie réellement.

car ce contrat hérite d'ERC1967Proxy non UUPSUpgradeable

Il est censé utiliser le proxy ERC1967 (à la fois UUPS et les proxys transparents d'openzeppelin utilisent erc1967, https://docs.openzeppelin.com/contracts/4.x/api/proxy#transparent-vs-uups). Le UUPSUpgradeable est utilisé par le contrat d'implémentation (il ne fait pas partie du proxy).

alors d'où viendrait la fonctionnalité UUPS réelle ?

De par sa conception, le contrat de mise en œuvre contient la fonctionnalité UUPS (ce qui est bien car il est plus économe en gaz car la logique n'est pas dans le proxy lui-même, mais mauvais car il est possible de passer par erreur à un contrat non compatible et de casser l'évolutivité ).

De plus, je ne suis certainement pas un expert en proxy, cela vient de mes propres recherches.

@JasoonS a commenté le 1 septembre 2021 21:18 :

car ce contrat hérite d'ERC1967Proxy non UUPSUpgradeable

Il est censé utiliser le proxy ERC1967 (UUPS et les proxys transparents d'openzeppelin utilisent erc1967, docs.openzeppelin.com/contracts/4.x/api/proxy#transparent-vs-uups ).

Droit. Et ERC-1967 ne fait pas grand-chose à part spécifier l'emplacement de stockage de l'adresse d'implémentation, l'adresse de balise et l'adresse d'administrateur. BTW fait amusant que j'ai remarqué: en se conformant à ERC-1967, l'implémentation OZ UUPS viole en fait EIP1822 qui spécifie un emplacement de stockage légèrement différent pour l'adresse d'implémentation.

Le UUPSUpgradeable est utilisé par le contrat d'implémentation (il ne fait pas partie du proxy).

Oh, bien sûr ! Merci de m'avoir aidé à voir ce qui me manquait bêtement ici.

alors d'où viendrait la fonctionnalité UUPS réelle ?

De par sa conception, le contrat de mise en œuvre contient la fonctionnalité UUPS (ce qui est bien car il est plus économe en gaz car la logique n'est pas dans le proxy lui-même, mais mauvais car il est possible de passer par erreur à un contrat non compatible et de casser l'évolutivité ).

Oui, donc l'implémentation doit hériter de UUPSUpgradeable .

Merci encore pour cette aide précieuse !