Contract Upgrades

[richardpringle]

As is apparent on multiple blockchains and blockchain-frameworks, there is demand for upgradeable contracts.

What is an upgradeable contract?

Nothing precludes a smart-contract author from deploying a new contract and calling the new contract version-(n + 1), but what happens when another contract has hardcoded its address? That other contract is calling old code and needs to also release version-(n + 1). It's untenable to have to release a new contract every time a "parent" contract is updated (dependent-contract calls parent-contract).

Existing Solutions

Since the problem seems to relate to the calling code and the address of the contract, it's not surprising that the general community has centered around a type of proxy pattern. There are two types of proxies:

1. Proxies built on top of protocol
2. Proxies built into the protocol

It seems that with the benefit of hindsight, the community of blockchain builders seems to be converging on building the proxy into protocol itself.

Proposals to follow...

[richardpringle]

[WIP]

Decoupling code and accounts

(diagram below is a WIP, it needs a couple of updates)
(TODO: make it clear what fields are optional vs mandatory)

Concepts

State

• Address
  Representation of the state of a single entity (which could be a multisig). The entity can exist on or off-chain. For the on-chain case, there must be code associated with the account
• Account
  An account represents the authorization details for a singular state-space
• State-space
  A state-space is owned by a single on or off-chain entity and can store arbitrary key-value pairs representing things like native balance
• CodeID
  The hash of the wasm-bytecode that's deployed to the chain

Logic

• Auth-Function
  The authorization logic for a state-space. Today, this should only be a stateless function (eg signature verification). In the future, it could be possible to deploy wasm-code here and/or give this access to its own state.

Actions

• Deploy
  Deploy wasm bytecode to the chain
  (should unused code be cleaned up over time? We could keep the code-hash on-chain, but force a redeployment of code that hasn't been used)
• Initialize Account
  Initialize an on-chain address and account and set a CodeID
  (The difference between an on-chain vs off-chain account is simply the existence of a CodeID. Addresses will be derived from the CodeID, and some salt)
  (TODO: add to diagram or add separate "actions" diagram)
• Execute
  (details aren't correct here, I believe I was thinking that the user provides an Account and CodeID or something that resolves to a codeid aka proxy address)
  When a user wants to trigger an Execute action, they have to provide the address and arguments (update diagram with args) and the VM provides the context.
• Upgrade
  To perform an upgrade, a user simply provides an address that has already been initialized on-chain and swaps the code-id.
  (missing: they also need to be able to add permissions to new code for different accounts)

[samliok]

I like this approach, I think the main difference between your approach and mine is where the contract upgrade logic is defined. In my case, the logic is explicitly defined in the contract whereas here actions can upgrade the contract in ways that are unbeknownst to callers of the contract. Say i'm calling constantly calling a contract that typically costs 1 AVAX and the contract is upgraded suddenly drains 100 AVAX, I might not be too thrilled. You could just say that the user should simulate the TX and unsure the output looks correct, I feel like this could just be a footgun since users aren't going to check every tx especially if they're calling the contract many times. I guess this is a property inherent to proxys, but I'd rather have something more explicit.

Instead of coupling a built in proxy to the execution action, we could add a built in nameservice like discussed offline. By default, using the nameservice to call contracts would act as a proxy but users would also be able to explicitly call the original address to ensure they are calling the same contract logic.

[samliok]

Additional comments about the design

A state-space is owned by a single on or off-chain entity
How would the authorization function work with off-chain entities?

Secondly, could you expand on the permissions object each account stores. Do they log a list of codeIDs the account has write access to? because just having the codeID is not enough for this

The upgrades are pretty clear but probably worth including the Actor of the person calling upgrade in the action table.

[richardpringle]

Instead of coupling a built in proxy to the execution action, we could add a built in nameservice like discussed offline. By default, using the nameservice to call contracts would act as a proxy but users would also be able to explicitly call the original address to ensure they are calling the same contract logic.

This might deserve its own discussion haha

[richardpringle]

In my case, the logic is explicitly defined in the contract whereas here actions can upgrade the contract in ways that are unbeknownst to callers of the contract.

Yeah, I definitely see the benefit of both worlds. In the case where the upgrade logic lives in the original code, we're still treating code as the source of truth that everyone can agree on which I like, it's clear. The problem is, it's really hard to predict what behaviour you're going to need or how you're doing to make changes. So then what happens is the upgrade logic ends up being the same thing that I'm suggesting you bake into the protocol itself.

The benefit of baking it into the protocol is that you know that the same rules apply to everything, you don't have to look at every particular case.

We've talked about this offline, but just to be clear, I actually don't have one preference over the other (yet). I've specifically proposed something different so that it's easier to compare different strategies.

[samliok]

My initial thoughts were outlined in #1578 and I'll repost here. My design looks at contract upgrades from a contract <-> host function level rather than at the action level. This means, we don't need any additional actions to support this design(not saying this is bad or good).

Currently, a contract's state space is prefixed by its address.

flowchart TD
    State(Global State)
    ContractA("Contract A Address")
    ContractB("Contract B Address")
    ContractC("Contract C Address")
    StateA("Contract A State Space")
    StateB("Contract B State Space")
    StateC("Contract C State Space")

    State --> ContractA
    State --> ContractB
    State --> ContractC
    ContractA --> StateA
    ContractB --> StateB
    ContractC --> StateC

    style State stroke:#f9f,stroke-width:4px
    style ContractA stroke:#bbf,stroke-width:2px
    style ContractB stroke:#bbf,stroke-width:2px
    style ContractC stroke:#bbf,stroke-width:2px
    style StateA stroke:#bfb,stroke-width:2px
    style StateB stroke:#bfb,stroke-width:2px
    style StateC stroke:#bfb,stroke-width:2px

Loading

The state space of a contract should be decoupled with its code. This way, contracts would have much greater flexibility in interacting with state, and offer a very clean and explicit interface for managing state access and ownership. StateSpace would become a property of contracts, with their own read/write/own permissions. Initially every contract would be instantiated with it's own state space, but would be able to move access and control as it pleases.

flowchart TD
    State(State)
    Space1("State Space 0x1a2b")
    Space2("State Space 0x3c4d")
    Space3("State Space 0x5e6f")
    State --> Space1
    State --> Space2
    State --> Space3
    style State stroke:#f9f,stroke-width:4px
    style Space1 stroke:#bbf,stroke-width:2px
    style Space2 stroke:#bbf,stroke-width:2px
    style Space3 stroke:#bbf,stroke-width:2px
  

Loading

classDiagram
    %% Defining the classes
    class ContractA {
        StateSpace: 0x1a2b
    }
    class ContractB {
          StateSpace: 0x3c4d
    }
    class ContractC {
       StateSpace: 0x5e6f
    }
	class ContractD {
		StateSpace: nil
	}
	

	class StateSpace {
		owner: Address
		writers: map[Address]bool
		statePrefix: []byte
	}

Loading

This design gives contracts much more flexibility regarding state access as contracts can share state and move ownership. A StateSpace can have multiple writers, but only one owner. This allows multiple contracts to explicitly program how their StateSpace is accessed, offering new functionality to contracts. For example, contracts can award write access to other contracts after a voting process, or to the highest bidder of an auction. Another idea would be to "lend" write access to a StateSpace for any contract willing to pay a monthly fee.

A lightweight implementation of this would expose one additional host function

	extern fn set_state_access(access: AccessControl)
	
	enum AccessControl {
		// gives `contract` write access to this contracts StateSpace
		// calling contract must have ownership of its StateSpace
		Write(Contract)
		// moves ownership to `contract`, 
		// calling contract must have ownership, 
		Own(Contract)
		// removes all access `contract` has to calling contract
		Remove(Contract)
		// delegates access control to `contract`
		Delegate(Contract)
	}

Upgrading contracts are quite easy.

	Contract A
	pub fn upgrade(new: Address) {
		// validate caller & other logic...
		
		// change owner
		set_state_access(AccessControl::own(address))		
	}

	Contract B
	pub fn init(contractA: Address) {
		// Allow contractA to move ownership to ContractB
		set_state_access(AccessControl::delegate(contractA))
	}

In this example, ContractB would be initialized letting ContractA to set it's StateSpace. Contract A would then move ownership to ContractB once granted access. If ContractA would still like write access, it can give itself write permissions before moving ownership to ContractB