TZIP-18 (new proposition, internal proxy)

TZIP
1

Disclaimer: It is a copy of Hyperledger Fabric migration feature.

It is comparable to the common proxy-pattern approach but with internal proxy. Proxy is managed by Tezos node and removes developer manual maintenance

image
image1557×657 70.7 KB

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
*Easiest for DEVOPS to manage lifecycle
*Cheap, as storage and address does not move
*Full code still auditable, smart contract definition points to last source code version. Governance actions are traced as any other transactions and auditable too

Cons

  • Need to clearly define governance policies for upgrading contracts at first deployment
  • Require to update the protocol
  • Require to separate the contrat itself (code, storage, interface declaration) from its own metadata admnistration (address, version, policies)
3 Likes