0 
@openzeppelin/contracts/proxy/utils/Initializable.sol

vs

@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol

Why would anyone use proxies that do not support upgradable contracts? Instead, just create contract without a proxy, doesn't that save the trouble?

// SPDX-License-Identifier: MIT pragma solidity 0.8.15; import { Initializable } from "@openzeppelin/contracts/proxy/utils/Initializable.sol"; contract Test is Initializable { address public owner; constructor() public { owner = msg.sender; } function initialize() public initializer { // logic } }

Aren't all proxies meant to support upgradable implementation contracts??

Another question is since it uses a non-upgradable contract, is it still susceptible to the constructor caveat? Openzeppelin Docs

Improve this question

2 Answers 2

Reset to default
1

Proxies can be implemented with and without the upgradeability feature (see Proxies). Depending on the use case or technical considerations, you may opt to deploy a non-upgradeable proxy using one of the most known mechanism such as Diamond Proxy (see ERC-2535).

One use case of a non-upgradeable proxy would be to separate your contract's functions into smaller contracts called facets and allow your proxy to route functions call to the proper facet. By doing so, for example, you can get rid of the maximum contract size limit (which is now 24.576 kb).

Improve this answer
4
  • But am wondering if it's still susceptible to if it's non upgradable Constructor Caveat Commented Mar 28, 2024 at 8:08
  • No matter of the type of the proxy (upgradeable or non-upgradeable) they are still oblivious to the existence of constructors in the logic contracts. Therefore, whenever the proxy links to a logic contract, one must use a initializer function rather than a constructor so the proxy can sync with the logic contract state. Commented Mar 28, 2024 at 8:20
  • Hmm, what if you were in the constructor to call the initializer function? 1) Deploy new Implementation 2) Upgrade to new implementation How would this negatively affect the newly implemented contract? Commented Mar 28, 2024 at 8:42
  • This answer is weird to me because Diamonds are upgradeable. Commented Sep 10, 2024 at 15:34
0

  1. @openzeppelin/contracts/proxy/utils/Initializable.sol and @openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol is the same, diffrent import from diffrent package

  2. When using upgradable we don't use the constructor to prevent re-initialize contract state

 /// @custom:oz-upgrades-unsafe-allow constructor constructor() { _disableInitializers(); }
Improve this answer
1
  • I agree on the first point, but the second point we should do it for almost all contracts. But am wondering if it's still susceptible to Constructor Caveat Commented Mar 28, 2024 at 7:42

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.