---
title: Blogpost - Michelson dynamic views
tags: protocol
---

Target: after the dynamic views MR is merged!!!

## New proposal "dynamic views"

The advantage of views provides a synchronous way to fetch the data from another contract. This current feature cannot apply to contracts that deployed before the Hangzhou upgrade, or contracts that are deployed without declaring on-chain views in their codes. In this proposal, we want to provide a synchronous way as in views that able to fetch information from contracts that have been deployed.

TODO: "Why we propose VIEW_EXEC ?" "How does VIEW_EXEC will ease dev onchain & offchain"?

After the views feature introduced, the [Sexp contracts](https://blog.sexp.exchange/using-views-to-improve-sexp-contracts/) have to upgraded their contracts to support views (write new "copy" contracts to include view and deployed them), this lead to the old contracts ...
with this propose feature,

There are discussions that have been discussed on Agora with the subject: ["On-chain views patch"](https://forum.tezosagora.org/t/on-chain-view-patch/4717), where we discussed the pros. and cons and several approaches of design.

In this post, we will briefly introduce the design that we chose for this new proposal. The detail design can be found in this [design document](https://hackmd.io/3oI6oQlhQfuAspvcHo1TDg).

In this proposal, we propose to add a new [Michelson instruction](https://tezos.gitlab.io/active/michelson.html#core-instructions). This instruction takes a lambda term of type `s -> a` as input, where `s` is the storage type of the target contract, and `a` is a value type derivable from `s`. By providing a proper lambda function, a contract could read anything from the target contract storage at will. We name this new instruction `VIEW_EXEC`, `VIEW_EXEC` has the same properties as `VIEW` (detail design of previous views can be found at [this manual](https://tezos.gitlab.io/active/michelson.html#core-instructions)), they are:
- read-only: they may depend on the storage of the contract but cannot modify it nor emit operations,
- synchronous: the result is immediately available on the stack of the contract.

Unlike `VIEW`, `VIEW_EXEC` has:
- no name,
- no input, and output arguments,
- lambda function in a stack. In lambda output, the following types are forbidden (as in `VIEW`: `ticket`, `operation`, `big_map` and `sapling_state`)

### Example

Suppose we have a `contract_a` that look likes below, assume the initial value of the storage is `int 2`:

# contract_a
parameter unit ;
storage int ; # int 2
code { CDR;
       NIL operation;
       PAIR
}

Suppose we want to write a `contract_b` that fetches the `int` in the storage of `contract_a` and increment it.

Using the new `VIEW_EXEC`, we can write the `contract_b` like below:

# contract_b
parameter address ;
storage int ;
code { 
      CAR; # address
      LAMBDA int int { PUSH int 1; ADD } ;
      VIEW_EXEC ; # result: Some (int 3)
      ASSERT_SOME ;
      NIL operation ;
      PAIR ;
     }

Assume the initial storage of `contract_b` is `int 42`. When call the `contract_b` with the address of `contract_a`, it will return the value `Some (int 3)` (it takes the initial value of `contract_a`: 2 and call the lambda function that does the increment by one).

## Conclusion
we proposed a new approach to fetch storage information from legacy contracts. We would also like to continue communicating with users and ecosystem developers to further improve contracts UX. If you have any feedback, let us know!