# Views TZIP
**URL:** https://forum.tezosagora.org/t/views-tzip/2560
**Category:** TZIP
**Created:** [December 30, 2020, 1:39pm UTC](https://forum.tezosagora.org/t/views-tzip/2560 "2020-12-30T13:39:46Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@cct](https://forum.tezosagora.org/u/cct)
#### Post date: [December 30, 2020, 1:39pm UTC](https://forum.tezosagora.org/t/views-tzip/2560/1 "2020-12-30T13:39:46Z")
Request for comments on the [views proposal](https://gitlab.com/tzip/tzip/-/blob/master/drafts/current/draft_views.md). The comments can be left below.
---
### Author:  [@tom](https://forum.tezosagora.org/u/tom)
#### Post date: [January 8, 2021, 2:26am UTC](https://forum.tezosagora.org/t/views-tzip/2560/2 "2021-01-08T02:26:00Z")
Why do we need `GET_STORAGE` if we have `VIEW`?
The existence of `GET_STORAGE` means that the storage type of a contract becomes definitely part of its observable behavior.
So, for example, a compiler cannot modify the storage type (perhaps optimizing things away, or adding things) while preserving semantics. Indeed, two contracts will be semantically equivalent only if they have _identical_ storage types (presumably including annotations, unless they are eliminated someday, or the `GET_STORAGE` check ignores them as a special case.)
---
### Author:  [@tom](https://forum.tezosagora.org/u/tom)
#### Post date: [January 8, 2021, 2:47am UTC](https://forum.tezosagora.org/t/views-tzip/2560/3 "2021-01-08T02:47:12Z")
Presumably, `GET_STORAGE` and `VIEW` will be forbidden to involve `ticket` or any other future non-DUPable/“forged” types (for `VIEW`, in the return type)?
If so, `GET_STORAGE` will be completely unusable on any contract whose storage involves `ticket`?
---
### Author:  [@cct](https://forum.tezosagora.org/u/cct)
#### Post date: [January 8, 2021, 8:26am UTC](https://forum.tezosagora.org/t/views-tzip/2560/4 "2021-01-08T08:26:29Z")
`VIEW` requires the targeted contract to prepare “function” and `GET_STORAGE` allows us to receive storage directly from the targeted contract.
The type for `GET_STORAGE` is necessary and observable since Michelson is typechecked and it is a part of definitions of contract.
---
### Author:  [@cct](https://forum.tezosagora.org/u/cct)
#### Post date: [January 8, 2021, 8:27am UTC](https://forum.tezosagora.org/t/views-tzip/2560/5 "2021-01-08T08:27:04Z")
Currently, `GET_STORAGE` and `VIEW` aren’t forbidden that since these two instructions are read-only. They can’t modify the storage.
What’s the concern for forbidden that?
---
### Author:  [@tom](https://forum.tezosagora.org/u/tom)
#### Post date: [January 8, 2021, 9:02am UTC](https://forum.tezosagora.org/t/views-tzip/2560/6 "2021-01-08T09:02:35Z")
> [@cct](#):
>
> The type for `GET_STORAGE` is necessary and observable since Michelson is typechecked and it is a part of definitions of contract.
Yes. The new thing to me is that the `storage` type of a contract becomes observable to other contracts, like the parameter type is now, or like the types of views would (and should) be. In other words, the storage type becomes part of the on-chain “public interface” of a contract. Personally, I like that the storage type is “private.”
> [@cct](#):
>
> Currently, `GET_STORAGE` and `VIEW` aren’t forbidden that since these two instructions are read-only. They can’t modify the storage.
>
> What’s concerns for forbidden that?
The most obvious implementations of `GET_STORAGE` and `VIEW` with `ticket` in the return type would violate the intended resource semantics of tickets. It would allow a contract to receive copies of tickets while leaving the original tickets in the other contract’s storage. For `GET_STORAGE` the ownership semantics would be completely destroyed, as any contract could steal copies of any other contract’s tickets.
Maybe, instead of forbidding tickets, one could walk the storage value, replacing any tickets with some kind of dummy tickets. (Maybe replace the ticketer address with a dummy address…?) This would have to be done lazily for tickets contained in big\_maps too, I guess.
---
### Author:  [@cct](https://forum.tezosagora.org/u/cct)
#### Post date: [January 8, 2021, 10:45am UTC](https://forum.tezosagora.org/t/views-tzip/2560/7 "2021-01-08T10:45:38Z")
> [@tom](#):
>
> The most obvious implementations of `GET_STORAGE` and `VIEW` with `ticket` in the return type would violate the intended resource semantics of tickets. It would allow a contract to receive copies of tickets while leaving the original tickets in the other contract’s storage. For `GET_STORAGE` the ownership semantics would be completely destroyed, as any contract could steal copies of any other contract’s tickets.
Please correct me if I am wrong. I think it isn’t a issue because when inspected the value of the received ticket by `GET_STORAGE`, `VIEW` or others, it will include the amount, and the address of the ticketer, i.e. the contract that created the ticket. So, we can’t really “forge” and pretend a ticket which has been created by another ticketer.
---
### Author:  [@tom](https://forum.tezosagora.org/u/tom)
#### Post date: [January 8, 2021, 11:10am UTC](https://forum.tezosagora.org/t/views-tzip/2560/8 "2021-01-08T11:10:50Z")
> [@cct](#):
>
> Please correct me if I am wrong. I think it isn’t a issue because when inspected the value of the received ticket by `GET_STORAGE`, `VIEW` or others, it will include the amount, and the address of the ticketer, i.e. the contract that created the ticket. So, we can’t really “forge” and pretend a ticket which has been created by another ticketer.
Tickets are intended to have a resource interpretation, like linear logic, or affine really; they can be `DROP`’d, but:
> [@](#):
>
> Tickets cannot be duplicated using the `DUP` instruction.
`VIEW` should not provide a way for a contract (or others) to effectively `DUP` its tickets, and `GET_STORAGE` definitely should not provide a way for _other_ contracts to `DUP` a contract’s tickets without its consent.
---
### Author:  [@tom](https://forum.tezosagora.org/u/tom)
#### Post date: [January 8, 2021, 11:23am UTC](https://forum.tezosagora.org/t/views-tzip/2560/9 "2021-01-08T11:23:41Z")
Anyway, my personal recommendation is to drop `GET_STORAGE` and to forbid `ticket` (`allow_forged:false`) in the return type of views.
The only specific (not very convincing) motivation I have heard for `GET_STORAGE` is that it would provide access to the storage data of “adversarial” contracts. But if `ticket` is forbidden for `GET_STORAGE`, and such adversarial contracts could simply include a `ticket` in their storage type to block the use of `GET_STORAGE`, then it wouldn’t serve that purpose.
There could be other solutions, though…
---
### Author:  [@tom](https://forum.tezosagora.org/u/tom)
#### Post date: [January 8, 2021, 11:32am UTC](https://forum.tezosagora.org/t/views-tzip/2560/10 "2021-01-08T11:32:25Z")
For conservation of tickets, it also seems necessary to forbid `operation` in the return type of `view`, since tickets can be smuggled under transfers or originations. (In any case, `operation` in a view seems questionable…)
Other miscellaneous questions arise too: are all the various transaction-context instructions like `SENDER`, `AMOUNT`, `BALANCE`, `SELF_ADDRESS` (but not `SELF`), etc… allowed inside `view`? Do they have the same values seen by the _caller_? Maybe some of them (`BALANCE`? `SELF_ADDRESS` and `SELF`?) take values pertaining to the _callee_?
---
### Author:  [@galfour](https://forum.tezosagora.org/u/galfour)
#### Post date: [January 8, 2021, 2:50pm UTC](https://forum.tezosagora.org/t/views-tzip/2560/11 "2021-01-08T14:50:58Z")
It is not only about adversarial contracts.
It can be about retroactively adding new views to the contract: the information is already there, but the view was not written before, and we want to use that new information.
---
### Author:  [@galfour](https://forum.tezosagora.org/u/galfour)
#### Post date: [January 11, 2021, 7:55pm UTC](https://forum.tezosagora.org/t/views-tzip/2560/12 "2021-01-11T19:55:23Z")
~~But yeah. We will drop `GET_STORAGE` as a result. I do not believe we can find a good model for it (stubbing tickets? what about big maps??).~~
There is actually a good one. Replacing `ticket` types with `ticket_stub` in `GET_STORAGE` 's return. The data itself doesn’t need to change.
For views, yup, ~~tickets and~~ wrappers (big maps or operations) have to be forbidden.
---
### Author:  [@tom](https://forum.tezosagora.org/u/tom)
#### Post date: [January 30, 2021, 1:05am UTC](https://forum.tezosagora.org/t/views-tzip/2560/14 "2021-01-30T01:05:20Z")
> [@galfour](#):
>
> There is actually a good one. Replacing `ticket` types with `ticket_stub` in `GET_STORAGE` 's return. The data itself doesn’t need to change.
Yuck. 😉 But it does sound workable to me…
At the moment, because tickets are represented as `Pair x y z`, you could simply replace `ticket t` with the `opened_ticket_type` (`pair address t nat`.)
But, we might like to introduce a `Ticket` tag in the future, to reduce risk from type confusion bugs (e.g. like the original VIEW draft.) In that case, `ticket_stub` must be a new type, and will have to parse `Ticket` (so that “the data itself doesn’t need to change”.)
~~But `ticket_stub` should unparse using some other tag, either `Pair` again or a new `Ticket_stub`. If it unparses with `Ticket` then the type confusion risk will come back: maybe I can steal your ticket as a `ticket_stub` using `GET_STORAGE`, then abuse a type confusion bug to cast it back to `ticket`.~~
Actually, I’m not sure this strategy will avoid all risk from type confusion…
* * *
Unrelatedly:
A possible hazard with `VIEW` is calling it on yourself. It should be well-known that doing this _intentionally_ is an evil (and currently inefficient) hack, and that the view will see a “stale” storage value.
But a more difficult hazard is that you must consider _unknowingly_ calling `VIEW` on yourself. Generally, ~~this might happen whenever you use a `view` interface which you also implement.~~ this might happen whenever any view you call (directly or indirectly) ends up calling one of your views.
I suppose you can call this a “reentrancy” hazard, which remains even though `VIEW` is “read-only”.
Should calling `VIEW` on yourself be forbidden? I don’t know… This will turn the safety hazards – and innocent examples – into liveness hazards.