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

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)