Skip to main content
Version: 1.0

Contract Updatability

Introduction​

A contract is a collection of data (its state) and code (its functions) that lives in the contract storage area of an account. When a contract is updated, it is important to make sure that the changes introduced do not lead to runtime inconsistencies for already stored data. Cadence maintains this state consistency by validating the contracts and all their components before an update.

Validation Goals​

The contract update validation ensures that:

  • Stored data doesn't change its meaning when a contract is updated.
  • Decoding and using stored data does not lead to runtime crashes.
    • For example, it is invalid to add a field because existing stored data won't have the new field.
    • Loading the existing data will result in garbage/missing values for such fields.
    • A static check of the access of the field would be valid, but the interpreter would crash when accessing the field, because the field has a missing/garbage value.

However, it does not ensure:

  • Any program that imports the updated contract stays valid. e.g:
    • Updated contract may remove an existing field or may change a function signature.
    • Then any program that uses that field/function will get semantic errors.

Updating a Contract​

Changes to contracts can be introduced by adding new contracts, removing existing contracts, or updating existing contracts. However, some of these changes may lead to data inconsistencies as stated above.

Valid Changes​

  • Adding a new contract is valid.
  • Removing a contract/contract-interface that doesn't have enum declarations is valid.
  • Updating a contract is valid, under the restrictions described in the below sections.

Invalid Changes​

  • Removing a contract/contract-interface that contains enum declarations is not valid.
    • Removing a contract allows adding a new contract with the same name.
    • The new contract could potentially have enum declarations with the same names as in the old contract, but with different structures.
    • This could change the meaning of the already stored values of those enum types.

A contract may consist of fields and other declarations such as composite types, functions, constructors, etc. When an existing contract is updated, all its inner declarations are also validated.

Contract Fields​

When a contract is deployed, the fields of the contract are stored in an account's contract storage. Changing the fields of a contract only changes the way the program treats the data, but does not change the already stored data itself, which could potentially result in runtime inconsistencies as mentioned in the previous section.

See the section about fields below for the possible updates that can be done to the fields, and the restrictions imposed on changing fields of a contract.

Nested Declarations​

Contracts can have nested composite type declarations such as structs, resources, interfaces, and enums. When a contract is updated, its nested declarations are checked, because:

  • They can be used as type annotation for the fields of the same contract, directly or indirectly.
  • Any third-party contract can import the types defined in this contract and use them as type annotations.
  • Hence, changing the type definition is the same as changing the type annotation of such a field (which is also invalid, as described in the section about fields fields below).

Changes that can be done to the nested declarations, and the update restrictions are described in following sections:

Fields​

A field may belong to a contract, struct, resource, or interface.

Valid Changes:​

  • Removing a field is valid


    _20
    // Existing contract
    _20
    _20
    access(all)
    _20
    contract Foo {
    _20
    _20
    access(all)
    _20
    var a: String
    _20
    _20
    access(all)
    _20
    var b: Int
    _20
    }
    _20
    _20
    _20
    // Updated contract
    _20
    _20
    access(all)
    _20
    contract Foo {
    _20
    access(all)
    _20
    var a: String
    _20
    }

    • It leaves data for the removed field unused at the storage, as it is no longer accessible.
    • However, it does not cause any runtime crashes.

  • Changing the order of fields is valid.


    _24
    // Existing contract
    _24
    _24
    access(all)
    _24
    contract Foo {
    _24
    _24
    access(all)
    _24
    var a: String
    _24
    _24
    access(all)
    _24
    var b: Int
    _24
    }
    _24
    _24
    _24
    // Updated contract
    _24
    _24
    access(all)
    _24
    contract Foo {
    _24
    _24
    access(all)
    _24
    var b: Int
    _24
    _24
    access(all)
    _24
    var a: String
    _24
    }

  • Changing the access modifier of a field is valid.


    _16
    // Existing contract
    _16
    _16
    access(all)
    _16
    contract Foo {
    _16
    access(all)
    _16
    var a: String
    _16
    }
    _16
    _16
    _16
    // Updated contract
    _16
    _16
    access(all)
    _16
    contract Foo {
    _16
    access(self)
    _16
    var a: String // access modifier changed to 'access(self)'
    _16
    }

Invalid Changes​

  • Adding a new field is not valid.


    _20
    // Existing contract
    _20
    _20
    access(all)
    _20
    contract Foo {
    _20
    access(all)
    _20
    var a: String
    _20
    }
    _20
    _20
    _20
    // Updated contract
    _20
    _20
    access(all)
    _20
    contract Foo {
    _20
    _20
    access(all)
    _20
    var a: String
    _20
    _20
    access(all)
    _20
    var b: Int // Invalid new field
    _20
    }

    • Initializer of a contract only run once, when the contract is deployed for the first time. It does not rerun when the contract is updated. However it is still required to be present in the updated contract to satisfy type checks.
    • Thus, the stored data won't have the new field, as the initializations for the newly added fields do not get executed.
    • Decoding stored data will result in garbage or missing values for such fields.

  • Changing the type of existing field is not valid.


    _18
    // Existing contract
    _18
    _18
    access(all)
    _18
    contract Foo {
    _18
    _18
    access(all)
    _18
    var a: String
    _18
    }
    _18
    _18
    _18
    // Updated contract
    _18
    _18
    access(all)
    _18
    contract Foo {
    _18
    _18
    access(all)
    _18
    var a: Int // Invalid type change
    _18
    }

    • In an already stored contract, the field a would have a value of type String.
    • Changing the type of the field a to Int, would make the runtime read the already stored String value as an Int, which will result in deserialization errors.
    • Changing the field type to a subtype/supertype of the existing type is also not valid, as it would also potentially cause issues while decoding/encoding.
      • e.g: Changing an Int64 field to Int8 - Stored field could have a numeric value624, which exceeds the value space for Int8.
      • However, this is a limitation in the current implementation, and the future versions of Cadence may support changing the type of field to a subtype, by providing means to migrate existing fields.

Structs, Resources and Interfaces​

Valid Changes:​

  • Adding a new struct, resource, or interface is valid.
  • Adding an interface conformance to a struct/resource is valid, since the stored data only stores concrete type/value, but doesn't store the conformance info.

    _12
    // Existing struct
    _12
    _12
    access(all)
    _12
    struct Foo {
    _12
    }
    _12
    _12
    _12
    // Upated struct
    _12
    _12
    access(all)
    _12
    struct Foo: T {
    _12
    }

    • However, if adding a conformance also requires changing the existing structure (e.g: adding a new field that is enforced by the new conformance), then the other restrictions (such as restrictions on fields) may prevent performing such an update.

Invalid Changes:​

  • Removing an existing declaration is not valid without using the #removedType pragma
    • Removing a declaration allows adding a new declaration with the same name, but with a different structure.
    • Any program that uses that declaration would face inconsistencies in the stored data.
  • Renaming a declaration is not valid. It can have the same effect as removing an existing declaration and adding a new one.
  • Changing the type of declaration is not valid. i.e: Changing from a struct to interface, and vise versa.

    _12
    // Existing struct
    _12
    _12
    access(all)
    _12
    struct Foo {
    _12
    }
    _12
    _12
    _12
    // Changed to a struct interface
    _12
    _12
    access(all)
    _12
    struct interface Foo { // Invalid type declaration change
    _12
    }

  • Removing an interface conformance of a struct/resource is not valid.

    _12
    // Existing struct
    _12
    _12
    access(all)
    _12
    struct Foo: T {
    _12
    }
    _12
    _12
    _12
    // Upated struct
    _12
    _12
    access(all)
    _12
    struct Foo {
    _12
    }

Updating Members​

Similar to contracts, these composite declarations: structs, resources, and interfaces also can have fields and other nested declarations as its member. Updating such a composite declaration would also include updating all of its members.

Below sections describes the restrictions imposed on updating the members of a struct, resource or an interface.

Enums​

Valid Changes:​

  • Adding a new enum declaration is valid.

Invalid Changes:​

  • Removing an existing enum declaration is invalid.
    • Otherwise, it is possible to remove an existing enum and add a new enum declaration with the same name, but with a different structure.
    • The new structure could potentially have incompatible changes (such as changed types, changed enum-cases, etc).
  • Changing the name is invalid, as it is equivalent to removing an existing enum and adding a new one.
  • Changing the raw type is invalid.

    _24
    // Existing enum with `Int` raw type
    _24
    _24
    access(all)
    _24
    enum Color: Int {
    _24
    _24
    access(all)
    _24
    case RED
    _24
    _24
    access(all)
    _24
    case BLUE
    _24
    }
    _24
    _24
    _24
    // Updated enum with `UInt8` raw type
    _24
    _24
    access(all)
    _24
    enum Color: UInt8 { // Invalid change of raw type
    _24
    _24
    access(all)
    _24
    case RED
    _24
    _24
    access(all)
    _24
    case BLUE
    _24
    }

    • When the enum value is stored, the raw value associated with the enum-case gets stored.
    • If the type is changed, then deserializing could fail if the already stored values are not in the same value space as the updated type.

Updating Enum Cases​

Enums consist of enum-case declarations, and updating an enum may also include changing the enums cases as well. Enum cases are represented using their raw-value at the Cadence interpreter and runtime. Hence, any change that causes an enum-case to change its raw value is not permitted. Otherwise, a changed raw-value could cause an already stored enum value to have a different meaning than what it originally was (type confusion).

Valid Changes:​

  • Adding an enum-case at the end of the existing enum-cases is valid.

    _27
    // Existing enum
    _27
    _27
    access(all)
    _27
    enum Color: Int {
    _27
    _27
    access(all)
    _27
    case RED
    _27
    _27
    access(all)
    _27
    case BLUE
    _27
    }
    _27
    _27
    _27
    // Updated enum
    _27
    _27
    access(all)
    _27
    enum Color: Int {
    _27
    _27
    access(all)
    _27
    case RED
    _27
    _27
    access(all)
    _27
    case BLUE
    _27
    _27
    access(all)
    _27
    case GREEN // valid new enum-case at the bottom
    _27
    }

Invalid Changes​

  • Adding an enum-case at the top or in the middle of the existing enum-cases is invalid.


    _27
    // Existing enum
    _27
    _27
    access(all)
    _27
    enum Color: Int {
    _27
    _27
    access(all)
    _27
    case RED
    _27
    _27
    access(all)
    _27
    case BLUE
    _27
    }
    _27
    _27
    _27
    // Updated enum
    _27
    _27
    access(all)
    _27
    enum Color: Int {
    _27
    _27
    access(all)
    _27
    case RED
    _27
    _27
    access(all)
    _27
    case GREEN // invalid new enum-case in the middle
    _27
    _27
    access(all)
    _27
    case BLUE
    _27
    }

  • Changing the name of an enum-case is invalid.


    _24
    // Existing enum
    _24
    _24
    access(all)
    _24
    enum Color: Int {
    _24
    _24
    access(all)
    _24
    case RED
    _24
    _24
    access(all)
    _24
    case BLUE
    _24
    }
    _24
    _24
    _24
    // Updated enum
    _24
    _24
    access(all)
    _24
    enum Color: Int {
    _24
    _24
    access(all)
    _24
    case RED
    _24
    _24
    access(all)
    _24
    case GREEN // invalid change of names
    _24
    }

    • Previously stored raw values for Color.BLUE now represents Color.GREEN. i.e: The stored values have changed their meaning, and hence not a valid change.
    • Similarly, it is possible to add a new enum with the old name BLUE, which gets a new raw value. Then the same enum-case Color.BLUE may have used two raw-values at runtime, before and after the change, which is also invalid.

  • Removing the enum case is invalid. Removing allows one to add and remove an enum-case which has the same effect as renaming.


    _23
    // Existing enum
    _23
    _23
    access(all)
    _23
    enum Color: Int {
    _23
    _23
    access(all)
    _23
    case RED
    _23
    _23
    access(all)
    _23
    case BLUE
    _23
    }
    _23
    _23
    _23
    // Updated enum
    _23
    _23
    access(all)
    _23
    enum Color: Int {
    _23
    _23
    access(all)
    _23
    case RED
    _23
    _23
    // invalid removal of `case BLUE`
    _23
    }

  • Changing the order of enum-cases is not permitted


    _24
    // Existing enum
    _24
    _24
    access(all)
    _24
    enum Color: Int {
    _24
    _24
    access(all)
    _24
    case RED
    _24
    _24
    access(all)
    _24
    case BLUE
    _24
    }
    _24
    _24
    _24
    // Updated enum
    _24
    _24
    access(all)
    _24
    enum Color: UInt8 {
    _24
    _24
    access(all)
    _24
    case BLUE // invalid change of order
    _24
    _24
    access(all)
    _24
    case RED
    _24
    }

    • Raw value of an enum is implicit, and corresponds to the defined order.
    • Changing the order of enum-cases has the same effect as changing the raw-value, which could cause storage inconsistencies and type-confusions as described earlier.

Functions​

Adding, changing, and deleting a function definition is always valid, as function definitions are never stored as data (function definitions are part of the code, but not data).

  • Adding a function is valid.
  • Deleting a function is valid.
  • Changing a function signature (parameters, return types) is valid.
  • Changing a function body is valid.
  • Changing the access modifiers is valid.

However, changing a function type may or may not be valid, depending on where it is used: If a function type is used in the type annotation of a composite type field (direct or indirect), then changing the function type signature is the same as changing the type annotation of that field (which is invalid).

Constructors​

Similar to functions, constructors are also not stored. Hence, any changes to constructors are valid.

Imports​

A contract may import declarations (types, functions, variables, etc.) from other programs. These imported programs are already validated at the time of their deployment. Hence, there is no need for validating any declaration every time they are imported.

The #removedType Pragma​

Under normal circumstances, it is not valid to remove a type declaration, whether a composite or an interface. However, a special pragma can be used when this is necessary to enable composite declarations to be "tombstoned", removing them from a contract and preventing any declarations from being re-added with the same name. This pragma cannot be used with interfaces.

To use this pragma, simply add a #removedType(T) line to the contract containing the type T you want to remove, at the same scope as the declaration of T. So, for example, to remove a resource definition R defined like so:


_10
access(all) contract Foo {
_10
_10
access(all) resource R {
_10
// definition of R ...
_10
}
_10
_10
// other stuff ...
_10
}

change the contract to:


_10
access(all) contract Foo {
_10
_10
#removedType(R)
_10
_10
// other stuff ...
_10
}

This will prevent any type named R from ever being declared again as a nested declaration in Foo, preventing the security issues normally posed by removing a type. Specifically, when a #removedType(T) pragma is present at a certain scope level in a contract, no new type named T can be added at that scope. Additionally, once added, a #removedType pragma can never be removed, as this would allow circumventing the above restriction.

Please note that this pragma's behavior is not necessarily final and is subject to change.