Hardhat-deploy: Dukungan proksi OpenZeppelin UUPS

Berencana untuk mendukung secara asli tetapi untuk saat ini masih memungkinkan untuk menggunakannya dengan hardhat-deploy. proksi jist perlu memiliki arg pemilik dummy/tidak digunakan di konstruktornya agar tetap kompatibel.

proksi jist perlu memiliki arg pemilik dummy/tidak digunakan di konstruktornya agar tetap kompatibel.

Bukankah itu membuat penggunaan UUPS tidak lagi bermanfaat? Alasan menggunakan UUPS adalah untuk menghemat gas pada panggilan transaksi karena proxy tidak perlu memeriksa apakah admin yang melakukan panggilan.

Mungkin saya melewatkannya, dapatkah Anda menguraikan dengan beberapa kode semu cara menggunakan hardhat-deploy dengan proxy uups (dengan argumen yang tidak digunakan)?

Terima kasih

Itu tidak akan mempengaruhi gas, itu hanya argumen dummy sehingga hardhat-deploy dapat menyebarkannya tanpa mengubah kode. konstruktor tidak perlu melakukan apa pun dengan argumen itu.
Akan melihat apakah saya dapat membuat perubahan untuk membuatnya bekerja tanpa perubahan segera. itu harus menjadi perubahan kecil di mana Anda dapat menentukan arg konstruktor untuk proxy atau mungkin hanya menentukan bahwa itu adalah proxy UUPS

Terima kasih @wighawag , akhirnya bisa menyelesaikan ini.

Bagi mereka yang tertarik saya membuat kontrak ini:

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

Dan kemudian penerapan saya terlihat seperti ini ( proxyContract: "UUPSProxy" menjadi bagian penting):

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

@JasoonS Tolong bisakah Anda mengklarifikasi tujuan dari kode kontrak UUPSProxy ? Apakah ini hanya kontrak tiruan sehingga hardhat-deploy mengetahui antarmuka konstruktor proxy yang sebenarnya? Atau apakah itu benar-benar berhubungan dengan kontrak proxy yang dikerahkan?

Apa sebenarnya peran admin , saya mendapatkan kesalahan tidak peduli apakah ada di sana, deployer (=upgrade admin) atau jika saya menghilangkan bidang.

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

@marceljay Tolong (selalu) tempel kesalahan yang Anda dapatkan :-)

Hai @aspiers , saya belum menggali hardhat-deploy secara mendalam jadi tolong perbaiki saya @wighawag. Tetapi dari apa yang saya pahami, ia tahu cara menggunakan proxy transparan. Dan proxy transparan dikerahkan dengan admin yang mengelola proxy tersebut. Dalam kontrak UUPS Anda tidak memiliki kontrak eksternal (admin proxy) yang mengelola pemutakhiran, melainkan dalam implementasi itu sendiri - jadi tidak diteruskan ke konstruktor proxy.

Jadi untuk membuatnya bekerja dengan hardhat-deploy, kami menerapkannya dengan konstruktor yang sama dengan proxy transparan, tetapi kami mengabaikan bidang admin dan mendapatkan efek yang sama.

Sepertinya berhasil untuk saya @marceljay

Penafian cuplikan kode saya tidak diaudit :sweat_smile: - Saya tidak bertanggung jawab atas proxy yang dikonfigurasi dengan buruk :laughing:

@marceljay Ah, ya, saya bisa menebak masalah Anda. Saya mengedit tanggapan asli saya.

Kode berikut adalah apa yang harus dilakukan pada implementasi. Jadi saya memiliki fungsi pada implementasi (bukan proxy) yang disebut inisialisasi yang mengambil 1 argumen (admin).

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

@marceljay Ah, ya, saya bisa menebak masalah Anda. Saya mengedit tanggapan asli saya.

Kode berikut adalah apa yang harus dilakukan pada implementasi. Jadi saya memiliki fungsi pada implementasi (bukan proxy) yang disebut inisialisasi yang mengambil 1 argumen (admin).

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

Ya sekarang masuk akal, melihat Anda mengedit jawabannya :)

Tahukah Anda jika kontrak ERC1967Proxy sama dengan yang digunakan oleh plugin upgrade OZ?

@JasoonS Terima kasih banyak atas penjelasannya tetapi saya masih belum sepenuhnya mengerti. Di atas Anda memposting kontrak mulai:

contract UUPSProxy is ERC1967Proxy {

Apakah itu benar-benar diterapkan secara nyata oleh contoh kode await deploy Anda posting di atas, atau apakah itu hanya kontrak dummy sehingga hardhat-deploy mengetahui antarmuka konstruktor proxy yang sebenarnya, atau yang lainnya? Kau menulis:

kami menyebarkannya dengan konstruktor yang sama dengan proxy transparan

tetapi jika itu benar-benar menyebarkannya maka saya tidak melihat bagaimana itu bisa bekerja, karena kontrak itu mewarisi dari ERC1967Proxy bukan UUPSUpgradeable , jadi dari mana fungsi UUPS yang sebenarnya berasal?

Apakah itu benar-benar diterapkan secara nyata oleh sampel menunggu kode penerapan yang Anda posting di atas?

Ya, itu benar-benar menyebarkannya.

karena kontrak itu mewarisi dari ERC1967Proxy bukan UUPSUpgradeable

Seharusnya menggunakan ERC1967Proxy (baik UUPS dan proxy transparan dari openzeppelin menggunakan erc1967, https://docs.openzeppelin.com/contracts/4.x/api/proxy#transparent-vs-uups). Kontrak UUPSUpgradeable digunakan oleh kontrak implementasi (ini bukan bagian dari proxy).

jadi dari mana fungsi UUPS yang sebenarnya berasal?

Secara desain, kontrak implementasi memiliki fungsionalitas UUPS, (yang bagus karena lebih hemat gas karena logikanya tidak ada di proxy itu sendiri, tetapi buruk karena dimungkinkan untuk meningkatkan ke kontrak yang tidak kompatibel secara tidak sengaja dan merusak kemampuan upgrade ).

Juga, saya jelas bukan ahli proxy, ini hanya dari penelitian saya sendiri.

@JasoonS berkomentar pada 1 September 2021 21:18 :

karena kontrak itu mewarisi dari ERC1967Proxy bukan UUPSUpgradeable

Seharusnya menggunakan ERC1967Proxy (baik UUPS dan proxy transparan dari openzeppelin menggunakan erc1967, docs.openzeppelin.com/contracts/4.x/api/proxy#transparent-vs-uups ).

Benar. Dan ERC-1967 tidak berbuat banyak kecuali menentukan lokasi penyimpanan dari alamat implementasi, alamat beacon, dan alamat admin. BTW fakta menyenangkan yang saya perhatikan: sesuai dengan ERC-1967, implementasi UUPS OZ sebenarnya melanggar EIP1822 yang menentukan lokasi penyimpanan yang sedikit berbeda untuk alamat implementasi.

Kontrak UUPSUpgradeable digunakan oleh kontrak implementasi (ini bukan bagian dari proxy).

Oh, tentu saja! Terima kasih telah membantu saya melihat apa yang secara bodoh saya lewatkan di sini.

jadi dari mana fungsi UUPS yang sebenarnya berasal?

Secara desain, kontrak implementasi memiliki fungsionalitas UUPS, (yang bagus karena lebih hemat gas karena logikanya tidak ada di proxy itu sendiri, tetapi buruk karena dimungkinkan untuk meningkatkan ke kontrak yang tidak kompatibel secara tidak sengaja dan merusak kemampuan upgrade ).

Ya, jadi implementasinya harus mewarisi dari UUPSUpgradeable .

Terima kasih banyak lagi untuk bantuan yang luar biasa ini!