# TZIP-18  (new proposition, internal proxy)

**URL:** https://forum.tezosagora.org/t/tzip-18-new-proposition-internal-proxy/4767
**Category:** TZIP
**Tags:** smart-contracts
**Created:** [October 4, 2022, 4:57pm UTC](https://forum.tezosagora.org/t/tzip-18-new-proposition-internal-proxy/4767 "2022-10-04T16:57:10Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![zamrokk](https://forum.tezosagora.org/user_avatar/forum.tezosagora.org/zamrokk/32/1634_2.png) [@zamrokk](https://forum.tezosagora.org/u/zamrokk)
#### Post date: [October 4, 2022, 4:57pm UTC](https://forum.tezosagora.org/t/tzip-18-new-proposition-internal-proxy/4767/1 "2022-10-04T16:57:10Z")

</div>

> 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](https://forum.tezosagora.org/uploads/default/original/2X/1/1c316581b6ba63f342252649300ee3701cce91ac.png)

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

```auto
{ 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)