Hardhat-deploy: OpenZeppelinUUPSプロキシのサポート

ネイティブでサポートすることを計画していますが、今のところ、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 （=アップグレード管理者）であるか、フィールドを省略しても、エラーが発生します。

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

@marceljay （常に）発生したエラーを貼り付けてください:-)

こんにちは@aspiers 、私は

したがって、これを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が実際のプロキシのコンストラクターのインターフェイスなどを認識できるようにするための単なるダミーコントラクトですか？ あなたが書いた：

透過プロキシと同じコンストラクターでデプロイします

しかし、それが実際に展開されている場合、そのコントラクトは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 / proxy＃transparent-vs- uupsを使用します）。

右。 また、ERC-1967は、実装アドレス、ビーコンアドレス、および管理者アドレスの保存場所を指定する以外はほとんど何もしません。 ところで、私が気付いた面白い事実：ERC-1967に準拠して、OZ UUPS実装は、実装アドレスにわずかに異なるストレージ場所を指定するEIP1822に実際に違反しています。

UUPSUpgradeableコントラクトは、実装コントラクトによって使用されます（プロキシの一部ではありません）。

もちろん！ 私がここで愚かに欠けていたものを見るのを手伝ってくれてありがとう。

では、実際のUUPS機能はどこから来るのでしょうか。

設計上、実装コントラクトはUUPS機能を保持します（ロジックがプロキシ自体にないため、ガス効率が高いため良いですが、互換性のないコントラクトに誤ってアップグレードしてアップグレード可能性を損なう可能性があるため、悪いです）。

そうです、実装はUUPSUpgradeableから継承する必要があります。

この大きな助けに改めて感謝します！