---
title: 'New Proposition for TZIP-18'
tags: tzip-18, upgrade, smartcontract, protocol
---

New Proposition for TZIP-18
===

## New Proposition for TZIP-18

> It is a copy of Hyperledger Fabric migration feature.

It is comparable to the naive approach combined with internal proxy except that the proxy is managed by Tezos node and requires no more developer manual operations

sequenceDiagram
  Admin->>Tezos: originate smart contract "A" version "1" with adminPolicy "AND(Admin,Admin2)" 
  Tezos-->>Admin: contractAddress A version "1"
  User->>frontend: click on %myfunction
  frontend->>SmartContractA: transaction %myfunction
  Note right of SmartContractA : executing logic of "A" version "1"
  Admin->>Tezos: migrate smart contract "A" version "2" "<NEW_CODE>" "<OPTIONAL_STORAGE_MIGRATION_SCRIPT>"
  Tezos-->>Admin: success 1/2
  Admin2->>Tezos: migrate smart contract "A" version "2" "<NEW_CODE>" "<OPTIONAL_STORAGE_MIGRATION_SCRIPT>"
  Note right of Tezos : check smart contract policy passed & ready for activation & dispatch to other nodes
  Note right of Tezos : pausing all calls to contract "A"
  Note right of Tezos : executing storage migration script from "1" to "2"
  Note right of Tezos : set current contract version A to version "2"
  Note right of Tezos : point contract address "A" to version "2" code binary
  Note right of Tezos : resume all calls to contract "A"
  Tezos-->>Admin2: success 2/2 , new version 2 is activated
  User->>frontend: click on %myfunction
  frontend->>SmartContractA: transaction %myfunction
  Note right of SmartContractA : executing logic of "A" version "2"

Some changes to consider :
- contract addresses does not refer to same block/code anymore, it is true only on first deployment. Later we use the same address but it redirects to other code version.
- during migration, all nodes knows which binary of the code to run depending of the current code version associated to the smart contract. So we have a notion of smartcontract definition (name,version,code,adminPolicies). i.e internal PROXY
- admin policies : defining who can deploy a new version. Like DAO , it can be a multisig signature of required n among m signatures to actually activate the new version `tezos-client migrate contract "A" "2.0" "<NEW_CODE>" "<OPTIONAL_STORAGE_MIGRATION_SCRIPT>" `
- admin policies might be updatable too. `tezos-client update contract-policy "A" "OR(Admin,Admin2)" ` . We can imagine new roles to do smart contract migration, edit smart contract policies, etc ...
- policy could be implemented in different ways :
- simple expression on addresses : OR , AND. Ex : `AND(tz1VSUr8wwNhLAzempoch5d6hLRiTh8Cjcjb,tz1aSkwEot3L2kmUvcoxzjMomb9mvBNuzFK6)`
- complex lambda expression : returning a boolean from Michelson code like below

{ PUSH address "tz1VSUr8wwNhLAzempoch5d6hLRiTh8Cjcjb" ;
  SOURCE ;
  COMPARE ;
  EQ }

- how to revert ? It is not possible to revert, instead, deploy the source code of previous version with a reverse storage migration script. It will increment the smart contract version anyway
- migration script ? use a lambda instead of initial storage

| Pros | Cons |
| -- | -- |
| Easiest for DEVOPS to manage lifecycle | Need to clearly define governance policies for upgrading contracts at first deployment |
| Cheap, as storage and address does not move | Require to update the protocol |
| Full code still auditable, smart contract definition points to last source code version. Governance actions are traced as any other transactions and auditable too | Require to separate the contrat itself (code, storage, interface declaration) from its own metadata admnistration (address, version, policies) |