Open Zeppelin

OpenZeppelin is a prominent software company that provides security products to build, automate, and operate decentralized applications on Ethereum and other blockchain platforms. It is best known for its reusable, secure smart contracts libraries, which are foundational in developing Ethereum-based applications, particularly in the decentralized finance (DeFi) sector. These libraries are extensively tested and audited to ensure robust security standards, helping developers mitigate the inherent risks associated with smart contract vulnerabilities.

The OpenZeppelin suite includes tools for creating, testing, and managing smart contracts throughout their lifecycle. One of the core offerings is the OpenZeppelin Contracts, a library of modular, reusable, and secure smart contracts written in Solidity. This library includes utilities for advanced features such as proxy patterns.

OpenZeppelin documentation provides an excellent detailed overview on proxy contracts:

One of the biggest advantages of Ethereum is that every transaction of moving funds, every contract deployed, and every transaction made to a contract is immutable on a public ledger we call the blockchain.

Although it is not possible to upgrade the code of your already deployed smart contract, it is possible to set-up a proxy contract architecture that will allow you to use new deployed contracts as if your main logic had been upgraded.

The way OpenZeppelin (and other similar tools) can be used to deploy an upgradeable smart contract is as follows:

1. Instead of deploying a single smart contract, a proxy contract is deployed to one blockchain address (hereafter referred to as “Proxy Address”) and an implementation contract is deployed to another blockchain address (hereafter referred to as “Implementation Address”).

2. The Implementation Address contains the code which will be exposed and published to users, but the Proxy Address is the blockchain address which will be published on the website, on an application, or anywhere users would need to find it to interact with the implementation contract.

3. The Proxy Address would be a smart contract with code that would look like this:

contract Proxy {
 owner; // the owner
 implementation; // where the real contact lives

 // change the owner
 function setOwner(newowner) {
  require(caller == owner);
  owner = newowner;
 }

 // upgrade the code
 function setImplementation(newImplementation) {
  require(caller == owner);
  implementation = newImplementation;
 }

 // function call through to the real contract
 function indirectCall(...) {
  implementation.Call(...)
 }
}

4. The proxy contract can be deployed on the blockchain network, and the owner of the proxy contract can be set to a blockchain address of our choosing (hereafter referred to as the “Control Address”).

5. Once deployed, all function calls to the Proxy Address are forwarded to the Implementation Address and only the owner of the Proxy Address (in this case us) can upgrade it, providing some security.

6. Now if we so decided, the implementation contract could be upgraded by deploying a new implementation contract to a new blockchain address (hereafter referred to as “New Implementation Address”) and use the Control Address to amend the proxy contract at the Proxy Address to the New Implementation Address.