Enterprises Fear Not. Blockchain Smart Contracts Are Upgradable and Blockchain Journal Proves It

Smart contract technology has a lot to offer enterprises. Smart contracts, which are essentially software programs that run on a blockchain, enable the development of complex business applications that programmatically and scalably unlock the unique value proposition of distributed ledger technology (DLT). To the extent that certain distributed ledgers are also programmable application platforms (this is true in varying extent from one public distributed ledger to the next), smart contract technology often serves as the foundation for specific use cases. There’s an increasing use of smart contracts in a wide variety of situations from supply chain and inventory control to comprehensive customer engagement and beyond. For a growing list of enterprises and global brands that are relying on blockchain, we suggest browsing Blockchain Journal’s Enterprise Blockchain Adoption Tracker.

Similar to the enterprise adoption of other application platforms, one significant key to enterprise adoption of blockchain lies in the ability to update any custom-developed source code to not only evolve its functionality over time, but to address bugs, security vulnerabilities, integration issues, and performance. In fact, source code evolution has evolved into an art form that has given way to an entire enterprise “DevOps” culture (fully operationalizing software development); one that embraces the principles and disciplines of what’s known as continuous integration and continuous development (CI/CD).

But, this same enterprise requirement and culture is seemingly at odds with the widely held belief that everything that goes onto a blockchain – not just transactions, but smart contract source code as well – is immutable. In other words, once a new application in the form of a smart contract has been posted to a blockchain for production usage, it cannot be changed, updated, or otherwise improved. For most if not all enterprises, just the idea of such source code immutability should and would be a dealbreaker to adoption.

So, are smart contracts truly immutable to the point that they pose a serious barrier to enterprise adoption? Or, is smart contract immutability much ado about nothing, and can enterprises take the view that blockchain as an application platform offers developers the same upgradability as any other enterprise application platform? As often is the case, the answers to these questions are complicated.

The Enterprise Software Development Status Quo

There has yet to be an instance of serious commercial software released that has remained stagnant. Software needs to be revised as bugs are discovered, business conditions change, and the number of users grows. In fact, companies spend millions, if not billions of dollars implementing software development frameworks and processes that accommodate rapid change at a very large scale. Hence, the popularity of software development methodologies such as Agile and enterprise-grade software architectures such as Kubernetes.

But, in blockchain lurks a challenge to this tradition. As enterprises go down the path toward adopting blockchain and DLT, many will encounter a type of conventional thinking that asserts that smart contracts are immutable; that once written they can never be updated. If such thinking were true, it’s an obvious showstopper in terms of any serious use of smart contracts within the enterprise. Fortunately, despite the legendary immutability of blockchain, which also applies to a smart contract’s source code (thus, the myth), there is a well-known and often applied architectural pattern to upgradeable smart contracts that enterprises will not only appreciate, but should recognize from other unrelated development projects.

In other words, the so-called inability to upgrade smart contracts is more the exception than the rule. Yes, there are a small number of blockchain networks out there that do not support smart contracts or upgradeable smart contracts. But, on the other hand, there are a growing number of blockchains that do. In fact, many smart contract-capable blockchains involve an easy path to upgradeable smart contracts and, in an effort to confirm or deny its existence, Blockchain Journal wrote some code to put that path to the test on four of the many public distributed ledgers that allow for such upgradability; Avalanche, Binance Smart Chain, Ethereum, and Hedera.

To the extent that not all public distributed ledgers support smart contracts let alone smart contract upgradeability, forward-thinking enterprises’ quests to identify the best blockchain network suited to their objectives will benefit from strategically narrowing their shortlist of strategic DLT choices to public DLTs that support upgradable smart contracts. There are a lot of choices out there. It’s just a matter of research, which brings us to the nuts and bolts of it all.

With regard to choosing a platform that supports upgradable smart contracts, understanding how they work, even at a general level is important. As those who have been involved with software development at both the executive and operational levels for a while have come to understand, the devil is always in the details. Having a sense of what those details are matters.

In the course of upgrading a simple smart contract on the four aforementioned blockchain networks, we’ll use the same Remix online IDE that we’ve been using for some of Blockchain Journal’s other coding experiments. Remix supports creating smart contracts using the Solidity programming language, which is the go-to for writing smart contracts on networks that support the Ethereum Virtual Machine (EVM).

The EVM is an intermediary Virtual Machine technology that runs smart contract bytecode on a blockchain network, similar to the way the Java Virtual Machine (JVM) is designed to run Java bytecode on a host computer. The Avalanche, Binance Smart Chain, Ethereum, and Hedera public distributed ledgers, along with other chains, are compatible with the EVM.

There will be two versions of our simple smart contract that we’ll deploy and then upgrade. The first version will publish a single function named getSecretHelloMessage(), which returns the message Hello World. The second version of the smart contract will be an upgrade to the first version. The second version will publish two functions, the original getSecretHelloMessage() as well as an added function named getSecretGoodybeMessage(). The function getSecretGoodybeMessage() returns the message Goodbye World. (See Figure 1.)

Figure 1: The two versions of code for the demonstration project.

Before delving into the details, let’s talk about terminology. Recall that in this article’s introduction, we mentioned that the idea of an upgradeable smart contract is complicated. That’s because, while it’s true that a smart contract’s source code cannot be modified once it has been published to a public distributed ledger, many blockchains involve an end-run around that immutability — one that involves a microservices approach to software development (a composable enterprise development pattern that many enterprise developers should recognize) — that essentially results in the upgradeability of smart contracts.

As you’ll soon learn, an upgradable smart contract is actually at least two contracts working together. Thus, the term upgradable smart contract is a bit of a misnomer because of the way multiple smart contracts are involved to produce the effect of upgradability. Nonetheless, the conventional term used in the industry is an upgradable smart contract, so that’s the term we’ll use.

Understanding the Proxy Pattern For Upgrading Smart Contracts

There are several ways to create an upgradeable smart contract. One popular method uses a composable, microservices-like software design pattern called the proxy pattern.

With a proxy pattern, a developer creates two smart contracts. One is called a proxy contract and the other is called the implementation contract. The implementation contract contains the actual business logic that’s our candidate to be upgraded (in the spirit of evolving that business logic’s functionality). The proxy contract contains a pointer to the blockchain address of the implementation contract. The proxy contract, as its name implies, acts as a proxy to the logic of the implementation contract, and technically, the address of the implementation contract is not a part of the proxy contract’s immutable payload. In other words, the address is mutable, which is the key to updating smart contracts.

The scenario below describes an example of how the proxy pattern works.

A developer writes and deploys the V1 version of the implementation contract that has the getSecretHellowMessage() function. Then, when the developer writes and deploys the proxy contract, it contains the blockchain address of the V1 version of the implementation contract. A user makes the call to getSecretHellowMessage() via the proxy contract, as shown in Figure 2 below. In turn, the proxy contract forwards the call to the implementation contract, which has the actual business logic that returns the secret message, in the case of V1, “Hello World.”

Figure 2: A proxy contract routes calls to a function to the implementation contract that contains the function and its behavior.

When it’s time to upgrade the “smart contract,” the developer creates the V2 version of the implementation contract, which after deployment, will have a unique blockchain address that’s different from the V1 version. As seen in Figure 2, the V2 version of the smart contract has been upgraded to include the additional function getSecretGoodbyeMessage(). Then, in the proxy contract, the developer updates the mutable address to which end-user calls are routed to reflect the blockchain address of the V2 version instead of the V1 version. The proxy contract is then redeployed. The thing to keep in mind about redeploying the proxy contract is that the only thing that changes is the address of the implementation contract. As you’ll learn soon, in terms of the proxy contract, the address of the implementation contract is stored separately from the proxy contract’s immutable logic.

Once the proxy contract is “upgraded” to reflect the new address for the V2 implementation contract, any end-user calls to the getSecretHelloMessage() and getSecretGoodbyeMesage() functions will be routed to the V2 implementation contract. From the end-users' perspective, nothing has changed. S/he still calls the proxy contract as s/he always has. What happens subsequently in terms of routing that call to V2 instead of V1 is opaque to the user.

Addressing the Elephant in the Living Room

At this point, before doing the actual code demonstration, we need to address the elephant in the living room in terms of proxy contracts. It has to do with the supposed immutability of blockchain smart contracts.

As you might recall, the reason that we go through the effort of using the proxy pattern for an upgradable smart contract is to accommodate the fact that the business logic in the implementation contracts is indeed immutable. Once an implementation contract is deployed to a blockchain, its business logic can never be changed. Hence, the need to deploy a new and also immutable replacement of the implementation contract in order to upgrade the overall smart contract.

But, couldn’t the same argument be made about the proxy? Within the proxy, we’re changing the blockchain address of the implementation contract. Originally, the proxy stored the blockchain address of the V1 implementation contract. Then, we modified the address to point to the location of the V2 implementation. Doesn’t this change in the proxy contract violate the principle of blockchain immutability? Won’t redeploying the proxy require users to go to a different version of the proxy to do work?

The answer to both questions is no. The reason is that we’re not changing the logic of the proxy contract. We’re only changing the value of the variable within the proxy that stores the address of the implementation contract. (This variable is called state data.)

We can do this because all smart contracts — including proxy contracts — store their state data separately from their business logic. Changing state data, in this case, the address of the implementation contract, does not affect the business logic of the smart contract. Therefore, the proxy contract remains immutable and the original blockchain address of the proxy contract remains unchanged. As a result, users can keep calling the proxy contract as they have always done even though the location of the underlying implementation contract has changed.

Many of those using an upgradeable smart contract will not give proxy immutability a second thought. It’s a subtle point. But, for those who do notice such details, it’s worth explaining. Immutability is key to the integrity of any blockchain. Any inkling that the immutability is being violated must be addressed and understood, particularly at the enterprise level.

Blockchain Journal’s Smart Contract Upgrade Experiment

To demonstrate this proxy pattern of smart contract upgradability, we’ll use Ethereum’s browser-based Remix IDE to write an upgradable smart contract in the Solidity programming language.

Listing 1 shows the Solidity source code from the V1 version of the implementation contract. We’ll create a proxy contract that controls routing to the implementation contract using the Remix auto-generate feature that automatically creates the proxy contract.

SOLIDITY
Copy
1// SPDX-License-Identifier: MIT
2pragma solidity ^0.8.6;
3import "@

Listing 1: The Solidity code for V1 version of the upgradeable smart contract implementation code.

Explaining all the gory details of the Solidity source code needed to make an upgradeable smart contract is beyond the scope of this article. But, it is useful to point out that the bulk of the complexity that goes with creating smart contracts under Solidity is handled by three libraries that are imported at the beginning of the implementation contract as shown below:

SOLIDITY
Copy
1import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";
2import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
3import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";

One of the key features of Solidity is that it supports code reuse. Developers can encapsulate extraordinarily complex code intended for reuse into libraries that get shared with other developers. Code reuse allows developers to avoid reinventing the wheel. And, when it comes to upgradeable smart contracts, that wheel is very complex.

You’ll notice that the V1 implementation contract code in Listing 1 has only the getSecretHelloMessage() function. When it’s time to upgrade the code to the V2 version, we’ll just need to add the getSecretGoodbyeMessage() function to the smart contract code like so:

SOLIDITY
Copy
1function getSecretGoodbyeMessage()  public pure returns (string memory){
2        return "Goodbye World";
3}

The automation features of the Remix IDE takes care of the rest. The Remix IDE not only ensures that the Solidity code is syntactically correct, but it also compiles and deploys the smart contract code to the target EVM-compatible blockchain with nothing more than the click of a button (see Figure 3).

Figure 3: The Remix IDE makes it easier to create, compile, and deploy Solidity code to an EVM-compatible blockchain.

A benefit of using the Remix IDE is that in addition to making it easier to create and compile Solidity code, the IDE also has a feature that allows a developer to deploy that code to any number of EVM-compatible blockchains. All a developer needs to do is run Remix in either a Chrome, Firefox, or Brave browser and then bind the IDE to a MetaMask wallet plugin that needs to be installed into the same browser as well. Then, from within the MetaMask wallet, select the blockchain network that’s the intended deployment target of the smart contract. The way upgrading a smart contract in Remix works is that a developer creates and compiles an original smart contract. Then, before deploying the contract, the developer declares within the MetaMask plugin the external blockchain to which the smart contract will be deployed.

Before deploying the original contract, the developer selects the Deploy with Proxy option checkbox on the left side of the IDE (see Figure 3). This will not only deploy the original contract as the implementation contract, but it will also create the additional proxy smart contract to go with it. Then, the developer clicks the Deploy button. Both the implementation contract and the proxy contract are then deployed to the targeted blockchain (see Figure 4).

Figure 4: Remix prompts the developer for permission to create both the implementation and proxy contracts on the targeted blockchain.

When it’s time to upgrade the contract, the developer modifies the original implementation contract’s source code with the changes required for the upgrade. The developer unchecks the Remix checkbox labeled Deploy with Proxy and selects the checkbox labeled Upgrade with Proxy. Also, the developer enters the blockchain address of the proxy smart contract in the Enter Proxy Address textbox beneath the Upgrade with Proxy checkbox. The address of the proxy smart contract is reported in the Remix IDE when the proxy smart contract is created as part of the deployment process for the original implementation smart contract (see Figure 5).

Figure 5: The smart contract upgrade process as executed in Remix.

The developer clicks the Deploy button to deploy the upgraded implementation contract to the blockchain. The updated implementation contract will be deployed to a new blockchain address that’s different from the address of the original implementation contract. However, the logic in the upgraded implementation contract is now accessible by way of the proxy contract whose own blockchain address remains unchanged. Hence, users will be able to access the new functionality created in the upgraded implementation contract by way of the address of the proxy contract.

The important thing to understand at a high level about the upgradable smart contract deployment process under Remix is that we can deploy and upgrade smart contracts to a variety of EVM-compatible blockchains from within the Remix IDE. This can be done by simply changing the blockchain network declared in the MetaMask wallet (as long as MetaMask itself supports the desired blockchain network).

Changing the blockchain network within the MetaMask browser plugin is what we’ll do to create, deploy, and then upgrade smart contracts to Avalanche, Binance Smart Chain, Ethereum, and Hedera. The only thing that will change in the Solidity source code is the addition of the getSecretGoodbyeMessage() function to the V2 version of the implementation contract. Other than that, all the upgrade and deployment work is done by Remix.

The following examples show the results of upgrading the demonstration contract to each of the blockchain networks mentioned previously. In Blockchain Journal’s experiments, the upgrade process was executed against the TestNet instances of each of the blockchains. Our reason for using the various TestNets was to avoid spending real funds in order to conduct the demonstration. Developers can typically obtain funds to spend on a TestNet at no cost. These funds used for the TestNet deployments are mock funds — funny money for lack of a better description — and have no real value other than for testing purposes.

Avalanche

Figure 6 shows the demonstration code used in the previous two examples, only this time the code is deployed and upgraded on the Avalanche TestNet, and the proxy contract information is viewed using the SnowTrace blockchain explorer.

Figure 6: Upgrading the demonstration project on the Avalanche TestNet blockchain and viewing the result in the SnowTrace blockchain explorer.

Binance Smart Chain

Figure 7 shows the final deployment and upgrade of the demonstration project to the Binance Smart Chain blockchain. The target is the Binance Smart Chain TestNet and the proxy contract information is displayed using the BscScan blockchain explorer.

Figure 7: Upgrading the demonstration project on the Binance Smart Chain TestNet blockchain and viewing the result in the BscScan blockchain explorer.

Ethereum

Figure 8 shows the result of deploying and then upgrading the demonstration code to the Ethereum network from within the Remix IDE.

Figure 8: Upgrading the demonstration project on the Ethereum TestNet blockchain and viewing the result in the Etherscan blockchain explorer.

Figure 8 also shows details of the upgradeable smart contract as shown in the Etherscan blockchain explorer at the address of the proxy contract. Showing the proxy contract on Etherscan is proof that the proxy has been deployed.

Developers can execute the getSecretHelloMessage() and getSecretGoodbyeMessage() functions that are available in the proxy through the Remix IDE. After the proxy contract is deployed, the Remix IDE will publish clickable buttons that execute the corresponding functions from the implementation contract that are exposed by way of the proxy contract (see Figure 9).

Figure 9: The details from the Remix IDE showing smart contract functions that get executed by way of a proxy contract.

Hedera

Figure 10, below, shows the result of upgrading the demonstration project code on the Hedera TestNet blockchain. As with the previous example, the code is deployed and upgraded using the Remix IDE, and the deployed proxy smart contract is available for inspection on the Hedera TestNet using the HashScan blockchain explorer.

Figure 10: Upgrading the demonstration project on the Hedera TestNet blockchain and viewing the result in the HashScan blockchain explorer.

Considering the Smart Contract Cost Component of Enterprise Total Cost of Ownership (TCO)

Most blockchain networks charge a fee for every activity conducted on the network. These fees are typically referred to as gas. This is as true for a simple transfer of funds between two parties as it is for executing a complex smart contract or even upgrading smart contracts. In most cases, there is no free lunch. However, the cost of lunch can vary depending on the structure of the smart contract and the fee structure of the given blockchain network (from one ledger to the next, these costs will unquestionably vary).

Figure 11 below shows the gas fees incurred on the Binance Smart Chain TestNet blockchain when deploying and then upgrading the proxy and implementation contracts associated with the demonstration project for this article.

Figure 11: The fees charged through the deployment and upgrade of a smart contract.

The table below shows the gas fees incurred to deploy and upgrade the smart contract on the Binance Smart Chain network (as shown in Figure 11). The fees in the table are reported in US dollars.

As with most blockchain networks, gas fees must be paid in the protocol token that’s native to the given blockchain. In the case of the Binance Smart Chain shown above, the protocol token is BNB. MetaMask reported the fees in both BNB and, based on the current BNB/USD conversion rate at the time of our tests (May 18, 2023), in USD for the sake of readability. But, the fees are paid with the Binance Smart Chain’s protocol token and the same is true of running smart contracts on Ethereum (paid in Ether), Avalanche (paid in AVAX), and Hedera (paid in HBAR).

For this reason, any volatility in the fiat currency (i.e., USD, euros, etc.) valuation of a chain’s protocol token must play a role in the TCO calculations of working with a particular chain. For example, if a transaction on a distributed ledger costs 1 protocol token when that protocol token is worth US$1, then the cost of that transaction is US$1. However, if one year later, that protocol token is worth US$2, then the US dollar cost of that same transaction will have effectively doubled.

Decision makers are advised to carefully study the cost schedules of the different chains under their consideration to understand if and how such volatility may impact the long-term costs of their smart contract strategies. For example, in an effort to make blockchain project costs more predictable (and insusceptible to exchange rate volatility), Hedera’s fixed fee schedule for the many different types of blockchain operations (including those associated with smart contracts) is denominated in US dollars (even though those fees are paid for in the Hedera protocol token HBAR). As the US dollar value of HBAR appreciates, Hedera’s fee schedule for its various blockchain operations (paid in HBAR) inversely depreciates. Thus, despite any exchange rate volatility, the out-of-pocket US dollar cost for any given blockchain operation never changes. Such nuances are an example of how important it is to holistically model the long-term costs of any blockchain project. Just because a network stabilizes its costs in this way doesn’t necessarily mean other networks haven’t applied other appealing fee policies to make project costs more manageable and predictable. In other words, read the fine print.

The examples shown above are very simple contracts for demonstration purposes only. The total cost for deploying and upgrading production smart contracts can be non-trivial and should be taken into consideration as a part of any smart contract strategy. Enterprises should expect that the costs for deploying and upgrading a smart contract that uses more computing and storage resources to be commensurate with the consumption of those resources. Thus, enterprise users need to be aware of these costs. It’s not unusual to have a situation in which hundreds, if not thousands of smart contracts can be active. The costs can add up to a significant expense, particularly if contracts are being upgraded frequently.

The interesting thing to note is that the bulk of the cost of deploying the V1 and V2 versions of smart contract is incurred when deploying implementation contracts and the initial deployment of the proxy contract. Then, the fee for a subsequent redeployment of the proxy contract is only a few cents.

While there’s a noticeable one-time cost when initially deploying a proxy contract, subsequent redeployments are not as expensive. Redeployment of a proxy contract only involves a change to the address of the implementation contract (a change that only impacts the proxy contract’s state data). As such, proxy contract redeployments involve minimal transaction costs when compared to the costs associated with their original deployment.

However, in contrast to proxy contracts, it’s important to keep in mind that each time an implementation contract is upgraded, the fee associated with the deployment of the new implementation contract will be approximately the same as the cost of its initial deployment.

When it’s time to use the smart contract, external parties calling the proxy contract will be charged a gas fee each time the proxy contract is called. Any time a smart contract consumes computing resources, those costs are assumed by those using the contract. Upgradable smart contracts are no different.

About Rent

In addition to gas fees, some blockchain networks charge an additional fee called rent. Rent, as the name implies, is a fee charged by a blockchain for the ongoing storage of a smart contract as well as the contract’s state data.

One of the driving forces behind rent is to control the growing costs that go with supporting smart contracts, particularly upgradeable smart contracts.

Smart contracts are by definition immutable. Thus, as you’ve learned in this article, when a smart contract is upgraded, a completely new implementation contract is added to the network. The implementation contract that gets deprecated does not go away. Despite the fact that the deprecated implementation contract is no longer used, it is still hosted on the network, forever. That contract is still taking up storage resources throughout the many computers that make up the blockchain network. In the absence of rent, and unless a blockchain network can come up with some sort of other compensation mechanisms, the owners of those computers would be giving away that storage space for free.

Over the short term, network nodes can tolerate some free hosting. It’s a cost of doing business to gain market share, But over the long term, the network can’t afford to give away resources without some compensation to recover the cost of operating those resources. It’s an unsustainable model. At some point, someone needs to pay.

Rent is one mechanism for compensating owners for an immutable smart contract’s long-term consumption of their computing resources. Another way is to rely on gas fees to help cover the cost of long-term storage of smart contracts (again, due to their immutability).

Blockchain networks such as Hedera and Solana have documented their individual approaches to rent. The fine print makes it clear that enterprises should expect rent calculations to vary from one distributed ledger to the next. Some important players in the DLT space are encouraging DLTs to adopt charging rent. Vitalik Buterin, the founder of Ethereum, is one of the proponents of charging rent. However, as of this writing, Ethereum, Avalanche, and Binance Smart Chain do not charge rent when storing smart contracts.

This is not to say that these platforms won't charge rent in the future, nor is it to say that the TCO of using a distributed ledger that charges rent will exceed the TCO of a network that does not. Upgradeable smart contract usage is growing significantly and at some point charging rent will be a reasonable way to: (a) recover the cost of the necessary computing and storage resources to sustain the immutability of deprecated smart contracts, and (b) to dissuade developers from upgrades that are so frequent that they’re essentially abusing the availability of those resources as though they are a bottomless pit. Therefore, enterprise decision-makers will benefit from taking into account how current or intended rent policies will impact the TCO on a particular DLT when modeling the costs of their intended applications that include possible upgrade roadmaps and the long-term costs they may incur.

In Conclusion

Being able to upgrade a smart contract on-demand is a critical feature for enterprises intending to use DLT in a production setting. The state of the art in enterprise development frameworks in the non-DLT world makes it possible for businesses to accommodate large-scale code changes accurately and continuously at lightning-fast speeds. In order for smart contracts to be viable within the enterprise, they must be able to compete against current expectations that go with upgrading code in non-DLT environments.

Upgradable smart contracts are an important foundational stepping stone that will play a significant role in making smart contracts a viable part of an enterprise’s information technology stack. The vision is there. The tools and technologies are evolving. Given current trends in the evolution of smart contract technology, it’s just a matter of time until upgradable smart contracts reach par with other already-evolved forms of enterprise software development.

Disclosure: As mentioned on Blockchain Journal’s About page, BCJ is committed to the impartial, objective, and factual coverage of the blockchain industry. An important part of that commitment involves proper disclosure when sponsors are mentioned in our editorial. Swirlds Labs, a charter sponsor of Blockchain Journal, is one of the companies within the coalition of organizations that’s responsible for the success of the Hedera public distributed ledger. In addition to Avalanche, Binance Smart Chain, and Ethereum, Hedera is one of the four EVM-compatible public ledgers we used to conduct our smart contract upgradeability tests. These choices were made on the basis of the availability of technical support to our writers and editors (this was a technical article that required such support). These choices do not reflect an intention to promote one or more of the mentioned ledgers over others in the industry and we hope that you’ll find our presentation of the facts to be free of hyperbole. Questions or comments about our editorial integrity should be directed to [email protected].