1 of 33

2 of 33

Brief overview

of the workshop agenda

"Let’s begin by taking a look at the agenda for today's workshop. We'll start with an introduction to smart contracts, laying the groundwork for why upgradeability is important. From there, we'll discuss the challenges associated with upgrading smart contracts and how we can overcome them using various proxy patterns. We’ll cover different types of proxies, such as Transparent Proxy, UUPS Proxy, and Beacon Proxy, and demonstrate their implementation in both Solidity and ink!.

Additionally, we’ll look at real-world examples, including the evolution of Uniswap from V1 to V3. To wrap things up, we’ll go over best practices, security considerations, and the importance of testing. Finally, I’ll leave some time for questions to ensure we cover any areas of interest or concern you might have."

3 of 33

What are

Smart Contracts?

4 of 33

Reasons for upgrading smart contracts 🔄

5 of 33

Upgradeability Challenges

Key challenges in upgrading smart contracts ⚠️

Immutability of blockchain ⚠️

Need to preserve contract state and address.

6 of 33

Proxy Pattern

Introduction to the Proxy Pattern 🛡️

7 of 33

Proxy Types

Different types of proxies (e.g., Transparent Proxy, UUPS Proxy, Beacon Proxy) 📑.

8 of 33

Transparent

Proxy Pattern

9 of 33

UUPS

Proxy Pattern

10 of 33

Beacon

Proxy Pattern

11 of 33

Diamond Standard

12 of 33

Implementing Proxies

in Solidity

13 of 33

Solidity Code Example - Transparent Proxy

"When we look at the Transparent Proxy pattern in Solidity, we typically see a few key components in the code. Let me walk you through the example.

Proxy Contract Definition:

The proxy contract usually contains a fallback function, which is triggered whenever a function that is not explicitly defined in the proxy contract is called.
This fallback function uses the delegatecall operation to forward the call to the implementation contract. The delegatecall allows the proxy to execute the implementation's code while maintaining the proxy's storage and address.

Storage Management:

One crucial aspect here is the storage management. The proxy contract has to store the address of the implementation contract securely. This is typically done using an implementation state variable.
The contract must ensure that there is no storage collision between the proxy and implementation contracts. This is often managed by placing the proxy’s state variables at the top of the storage layout.

Admin Functions:

The proxy contract also includes admin functions, typically restricted to the contract owner or admin. These functions are used to update the implementation contract's address, allowing the logic to be upgraded while keeping the same proxy contract address.

Initialization:

A critical step is the initialization of the proxy contract. The implementation address needs to be set upon deployment to ensure the proxy points to the correct contract. Additionally, initializing the implementation contract is crucial to avoid security vulnerabilities."

14 of 33

Introduction to ink!

and its proxy pattern 🦀

15 of 33

ink!

Code Example - Proxy

"Now, let's look at a proxy implementation using ink!, which is specifically designed for the Polkadot ecosystem. ink! has some differences from Solidity, but the overall concept of proxy patterns remains consistent.

Contract Structure:

In ink!, the contract is typically structured using Rust-like syntax. The proxy contract will contain a reference to the implementation contract, stored in a state variable.

Delegation Mechanism:

Just like in Solidity, ink! also uses a delegation mechanism. The proxy contract includes a method to forward calls to the implementation contract, but instead of delegatecall, ink! might use an approach native to its ecosystem, like cross-contract calls.

Storage and Initialization:

Storage management is handled similarly, where the implementation address is stored securely, and the proxy contract must ensure the integrity of the storage layout.
Initialization is also crucial in ink!. The proxy must be properly initialized to ensure that it delegates correctly to the implementation contract. This might involve setting the implementation address and ensuring any initial setup is complete."

in detail:

```rust

#![cfg_attr(not(feature = "std"), no_std)]

```

This line indicates that the code should compile without the standard library when the "std" feature is not enabled - common for blockchain contracts.

```rust

use ink_lang as ink;

```

Imports the ink! language items and aliases it to `ink`.

```rust

#[ink::contract]

mod proxy {

```

Defines a new ink! smart contract module named "proxy".

```rust

use ink_env::call::{build_call, Call, ExecutionInput, Selector};

```

Imports necessary components from `ink_env` for making contract calls.

```rust

#[ink(storage)]

pub struct Proxy {

implementation: AccountId,

}

```

Defines the contract's storage structure with a single field `implementation` of type `AccountId` which likely stores the address of the contract being proxied to.

```rust

impl Proxy {

#[ink(constructor)]

pub fn new(implementation: AccountId) -> Self {

Self { implementation }

}

```

Implements the constructor for the Proxy contract that takes an `implementation` address and initializes the storage.

```rust

#[ink(message, payable, selector = _)]

pub fn forward(&self) {

```

Defines a payable function that can receive any selector (the `_` means it will handle any function call).

```rust

let call = build_call::<<Self as ::ink_lang::Contract>::Env>()

.called(self.implementation)

.value(Self::env().transferred_value())

.exec_input(ExecutionInput::new(Self::env().call().selector()))

.returns::<()>()

.params();

```

This block:

- Builds a cross-contract call

- Sets the target to the implementation address

- Forwards any attached value (tokens)

- Sets up the execution input with the same selector as the incoming call

- Specifies no return value

- Prepares the parameters

```rust

ink_env::call::invoke_contract(&call).unwrap_or_else(|err| {

panic!(

"Failed to forward call to {:?}: {:?}",

self.implementation, err

)

});

```

Actually performs the cross-contract call to the implementation contract. If it fails, it panics with an error message.

This code implements a proxy contract pattern - a common design pattern in blockchain development that allows for upgradeable contracts. The proxy forwards all calls to another contract (the implementation) while maintaining a consistent address for users to interact with.

The key features are:

1. It's payable (can receive tokens)

2. It accepts any function call (through `selector = _`)

3. It forwards both the call data and any attached value to the implementation contract

4. It maintains the ability to upgrade by changing the implementation address

16 of 33

Introduction to OpenZeppelin and OpenBrush libraries 📚

17 of 33

⚠️ WARNING: OpenBrush is no longer actively maintained

18 of 33

19 of 33

Using OpenZeppelin for

upgradeable contracts 🏗️

20 of 33

Solidity Code Example - UUPS Proxy

"Let’s take a look at the UUPS Proxy pattern in Solidity. UUPS, which stands for Universal Upgradeable Proxy Standard, differs from the Transparent Proxy pattern in that the upgrade logic is embedded within the implementation contract itself.

Implementation Contract:

The implementation contract contains an upgradeTo function, which allows for the logic to be updated. This function is restricted to the admin or owner, ensuring that only authorized individuals can perform upgrades.
The upgradeTo function typically checks if the new implementation is a valid contract and whether it is properly initialized.

Proxy Contract:

The proxy contract remains simple in this pattern, often containing just the fallback function and delegating the call to the current implementation.
The proxy contract stores the implementation address and delegates execution using delegatecall.

Upgrade Logic:

When an upgrade is needed, the admin calls the upgradeTo function on the current implementation. This function updates the implementation address in the proxy contract, effectively upgrading the contract's logic.
The UUPS pattern provides flexibility because the upgrade logic can be customized within the implementation contract itself."

21 of 33

OpenBrush Upgradeable Contracts

Using OpenBrush for upgradeable contracts 🦀.

22 of 33

ink! Code Example

| OpenBrush

"In this slide, we see an example of using OpenBrush, a library for ink! that simplifies the implementation of upgradeable contracts. Let's break down how the proxy pattern is implemented here.

Using OpenBrush Utilities:

OpenBrush provides utility functions that make it easier to handle proxy patterns. These utilities abstract some of the complexities involved in forwarding calls and managing storage.

Contract Initialization:

The initialization process is crucial in OpenBrush as well. The proxy contract needs to be initialized with the correct implementation address, and OpenBrush provides functions to help with this setup.

Delegation and Upgrades:

The proxy contract uses OpenBrush's utilities to delegate calls to the implementation contract. The upgrade mechanism is integrated using OpenBrush’s predefined patterns, making it simpler to manage upgrades across different contracts.

Security Considerations:

As with any proxy implementation, security is a top priority. OpenBrush includes best practices for securing admin functions and ensuring that upgrades do not compromise the contract's integrity."

23 of 33

🦄 Uniswap Example - Need for Upgrades

24 of 33

Uniswap V1 to V2 Upgrade

Transition from Uniswap V1 to V2 🚀.

25 of 33

Uniswap V2 to V3 Upgrade

Transition from Uniswap V2 to V3 🔄

26 of 33

Best Practices for

Upgradeable Contracts

Recommended practices for implementing upgradeable contracts 🌟

27 of 33

Testing Upgradable Contracts

Importance of testing upgradeable contracts 🧪

28 of 33

Security Considerations

Key security considerations for upgradeable contracts 🔒

29 of 33

Proxy Misuse and Security Incidents

Proxy Admin Key Compromise
PAID Network was exploited
Uninitialized UUPS Proxy Implementation

Parity Multisig Freeze
Harvest Finance, Teller, KeeperDAO, and Rivermen NFT all used uninitialized contracts that would allowed attackers to set initialization parameters pointing to a contract and execute selfdestruct() during a delegatecall().

Storage Collision

The Audius governance hack

delegatecall() or call to an Untrusted Contract

Pickle Finance and Furucombo, dYdX

Developers can take advantage of the proxy pattern contract to implement an upgradeable contract system. However, proxy patterns are not the easiest library to use and can bring devastating security issues to the project if used incorrectly. The following section showcases incidents related to proxy misuses, and the centralization risk that proxy brings.

Proxy Admin Key Compromise

The proxy admin controls the upgrade mechanism to transparent upgradeable proxies, should the admin’s private key become compromised an attacker could upgrade the logic contract to execute their own malicious logic on the proxy state.

PAID Network was exploited by an attacker who compromised the private key of the proxy admin and triggered the upgrade mechanism to change the logic contract. The upgrades allowed the attacker to burn user PAID tokens and mint PAID tokens to themselves which were subsequently sold. The code itself was not vulnerable but rather the attacker was able to gain access to the private key for the privileged admin.

Uninitialized UUPS Proxy Implementation

For the UUPS proxy pattern, logic contract states are initialized through an initialize() function with input parameters provided by the caller through the proxy contract. The initialize() function is often protected by the "initializer" modifier to restrict the function to only be called once. After the initialize() function call, the logic contract is initialized from the proxy contract's perspective. However, the logic contract is not initialized from the logic contract's perspective because the initialize() isn't directly called in the logic contract. Given a contract is uninitialized, anyone could call the initialize() function to initialize it, set state variables to a corrupted value and potentially take over the logic contract.

The impact of a logic contract being taken over depends on the contract code in the system. In a worst-case scenario, the attacker can upgrade the logic contract in the UUPS proxy pattern to a malicious one and perform the "self destruct" function call; this can cause the entire proxy contract to become useless and assets in the contract to be permanently lost.

Incidents:

Parity Multisig Freeze: Implementation initialization was not called. An attacker then triggered initialization for many wallets and locked ether in the contract via a selfdestruct() call.
Harvest Finance, Teller, KeeperDAO, and Rivermen NFT all used uninitialized contracts that would allowed attackers to set initialization parameters pointing to a contract and execute selfdestruct() during a delegatecall().

Storage Collision

In an upgradeable contract system, a proxy contract does not declare state variables but rather uses pseudo-random storage slots to store important data. The proxy contract saves values from the logic implementation state variables in the relative position they were declared. If the proxy contract declares its own state variables, the storage collision will happen when both the proxy and logic contract attempt to use the same storage slot. OpenZeppelin libraries do not use state variables and instead save values, such as the admin address, to specific storage slots to prevent conflict based on EIP 1967 standard.

Incidents:

The Audius governance hack resulted from a storage collision created by the introduction of new logic to the proxy contract. The proxy contract declared a proxyAdmin address state variable whose value would be incorrectly read when executing the logic contract code. The logic contract values for initialized and initializing were read as data from the proxyAdmin value, allowing the attacker to call the initialize() function again to change the governance to the attacker. The attacker then changed the voting parameters and passed their own proposal to steal the Audius treasury balance.

delegatecall() or call to an Untrusted Contract

Suppose delegatecall() is present within a logic contract, and the contract doesn't correctly verify the call target. In that case, an attacker could utilize the function to perform a call to his malicious contract to destroy the logic implementation or execute custom logic. Similarly, an unrestricted address.call() function in the logic contract with a maliciously supplied address and data field would allow the attacker to act as the proxy contract.

Incidents:

Pickle Finance and Furucombo, dYdX. Vulnerable contracts had approval of user tokens. An arbitrary call()/delegatecall() was present in the code that used an user supplied address with user supplied data. Attackers would be able to call token contracts with the transferFrom() function to remove user balances. dYdX executed their own white-hat hack to preserve funds due to proxy vulnerability.

30 of 33

Best Practices

General

Integrate Proxy Pattern Only When Necessary
Do Not Modify the Proxy Library

Operational

Initialize the Logic Contract
Secure the Proxy Admin Account
Use a Separate Account for the Transparent Proxy Admin

Contract Storage

Be Cautious when Declaring State Variables in Proxy Contracts
Maintain the Logic Contract's Variable Declaration Order and Type
Include Storage Gap in Base Contracts
No State Variable Assignment During Construction or Declaration

General

Integrate Proxy Pattern Only When Necessary

Not every contract needs to be upgradeable. There are numerous risks involved in using the proxy pattern, as shown in the previous section. The "upgradeable" property also raises trust issues because the proxy admin can upgrade the contract without consensus from the community. It's recommended to integrate the proxy pattern into your project only when necessary. You definitely don't want everyone to be able to kill your contract.

Do Not Modify the Proxy Library

Proxy contract libraries are complex, especially the parts that handle the storage management and the upgrade mechanism. Any mistake made in the modification can affect the working of the proxy and logic contract. Plenty of high severity proxy-related bugs we found during audits are caused by incorrectly modified proxy libraries. The Audius incident is a perfect example to show the consequence of a poorly modified proxy.

Operational

Initialize the Logic Contract

An attacker can take over an uninitialized logic contract and potentially damage the proxy contract system. Initialize the logic contract after deployment or use the _disableInitializers() in the logic contract's constructor to disable the initialization automatically.

Secure the Proxy Admin Account

An upgradeable contract system often requires a "Proxy Admin" privilege role to manage the contract upgrade. An attacker can freely upgrade the contract to a malicious one and steal the users' assets if he compromises the admin key. We recommend carefully managing the proxy admin account's private key to avoid any potential risks of being hacked. A multi-sig wallet can be used to prevent the single point of key management failure.

Use a Separate Account for the Transparent Proxy Admin

The proxy admin and logic governance should be separate addresses to prevent loss of interaction with the logical implementation. If the proxy admin and logical governance reference the same address, no call will be forwarded to execute the privileged functions, sealing change of governance functionality.

Contract Storage

Be Cautious when Declaring State Variables in Proxy Contracts

As explained in the Audius Governance hack incident, a proxy contract must be careful when declaring its own state variable. State variables declared in the proxy contract in a normal way would cause a data collision when reading and writing data. If the proxy contract needs a state variable, save the value to an EIP1967-like storage slot that would prevent the collision when executing the logic contract’s code.

Maintain the Logic Contract's Variable Declaration Order and Type

Each version of a logic contract must maintain the same order and type of state variables, and new state variables need to be added to the end of the existing variables. Otherwise, the delegate call would result in the proxy contract reading and/or overriding the incorrect storage values; and the old data may be associated with a newly declared variable, which can cause serious issues to the application.

Include Storage Gap in Base Contracts

Logic contracts require storage gaps included in the contract code to anticipate new state variables when a new logic implementation is deployed. The size of the gap needs to be updated appropriately after adding the new state variables.

No State Variable Assignment During Construction or Declaration

Assigning state variables during declaration or in the constructor will only affect the value in the logic contract, not the proxy contract. Non-immutable parameters should be assigned using the initialize() function.

31 of 33

Best Practices

Contract Inheritance

Upgradeable Contracts Should Only Inherit From Other Upgradeable Contracts
Do Not Instantiate New Contracts in the Logic Contract
Parent Initialization Risks

Logic Contract Implementation

Avoid Using selfdestruct() or Performing delegatecall()/call() to Untrusted Contracts

32 of 33

Summary

Recap of the workshop 📜

In this workshop, we covered the importance of upgradeable contracts, various proxy patterns, practical implementations in Solidity and ink!, and best practices for secure upgrades

Proxy contracts bypass blockchain immutability by enabling protocols to update their code execution post deployment. However, developing proxy contracts is still meticulous, and incorrect implementations could lead to project compromising security and logical issues.

The overall best practice is to use provided and tested solutions, as Transparent, UUPS, and Beacon proxy patterns each have proven upgrade mechanisms with respective use cases. Otherwise, the privileged role to upgrade the proxy should also be securely managed to prevent an attacker from changing the proxy logic.

Logical implementations should also be careful to not implement functions that would result in a delegatecall() chain that could potentially execute attacker logic, such as selfdestruct(). While following best practices ensures that proxy contracts are robust deployments while maintaining the upgradeable flexibility, all code is prone to new security or logical issues that may compromise a project. It is best that all code is properly reviewed by an expert auditor, such as CertiK, that has experience auditing and securing proxy contract protocols.

33 of 33

Open floor for questions❓