---
title: On-chain views patching
tags: protocol
description: proposal for having a way to patch views onto an existing contract
---

# Proposal: on-chain view patch

[toc]

This feasure is requested by NFT market and DAO contract developer from akaSwap.

## Motivation

On-chain views provides a synchronous way to a contract to fetch the data from another contract. This, however, benefits to no contract who was originated *before* Protocol Hangzhou.

Ideally a simple solution to patch views onto a no-views contract is to originate a new contract with views, followed by a contract storage migration process. This is challenging to some contracts that maintains a large data structure on their storage such as a token ledger or a historical datasheet. Additionally, originating a new contract constantly causes extra burden to the frontend/backend of DApp, and even to the DApp users.

To improve the UX of Tezos contract interaction, we propose to have a new mechanism for "*adding*" an on-chain view onto an existing no-views contract.

## Possible design

### default view

The **default view** is a *sudo* view top-level to all contracts under the name *"default"*. The term *sudo* indicates this view has no real concrete definition stored on contract. And hense, there will be no extra storage space required.

To a caller constract, by calling such *default view*, the caller contract passes no extra parameter and gets the whole storage from the callee contract, expect things like `ticket`, `operation` and `lazy_storage`.

This solution, however, has an immediate shortcoming, it might be very costy to be used frequently if the callee has a considerable size of storage. Considering the use cases listed in the Appendix, this design is less ideal.

- Pros:
- You do not have to rely on target contract's effort to fetch the data
- Simple. You just need to know the target contract's address and storage type to call it.
- Cons:
- Storage size can be large.
- Caller needs domain knowledge about the target contract to parse the returned storage.
- This can be problematic if, for example, you want to write a "generic" NFT market contract that works with various external FA2 contracts. You cannot rely on the storage layout of each FA2 contract in that case and would want to just call a predefined "get_balance" view.
- Enables contracts to rely on other contract's storage (same as the *dynamic view*)

#### example

# default_view_caller.tz
{ parameter address ;
  storage int ;
  code { UNPAIR ;              # un-pair to get the callee's address
         UNIT ;                # pass unit as no parameter to view
         VIEW "default" int ;  # call "default" view; and, 
                               # expect an int to be returned 
         IF_NONE {} { ADD } ;
         NIL operation ;
         PAIR } }

### dynamic view

As an strengthen version of above *default view*, the **dynamic view** solution also adds a *sudo* view to all contracts.

The main difference is, this sudo view 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.

- Pros:
- You do not have to rely on target contract's effort to fetch the data
- Enables fetching only relevant data
- Cons:
- Caller needs domain knowledge about the target contract to craft the view lambda.
- Might enable contracts to rely on other contract's "private" storage
- This can be problematic when, for example, we introduce "upgradable contracts" that can upgrade the storage type. Upgrading storage type can break other contracts even if the external interface is kept the same.
- An existing view, that happened to be named by "default", could shadow the proposed behavior.

#### example

# dynamic_view_caller.tz
{ parameter address ;
  storage int ;
  code { UNPAIR ;             # un-pair to get the callee's address
         LAMBDA               # define lambda
             (pair int int)    
             int               
             { CAR } ;
         VIEW "dynamic" int ; # call "dynamic" view; and, 
                              # expect an int to be returned  
         IF_NONE {} { ADD } ;
         NIL operation ;
         PAIR } }

### new universal view instruction

Similar to the UX provided by above solutions, we also introduce a way to perform onchain view from one contract against another contract. Yet, instead of overloading the same `VIEW` instruction, we introduce a new instruction, say `SCAN`, that works exactly as the said dynamic view except we don't need the `name` parameter.

Pros/Cons are very much as the dynamic view, except the usage/syntax should be simpler. We don't have to handle the awkwardness of having a new preserved keyword like `default`.

#### example

# scan_caller.tz
{ parameter address ;
  storage int ;
  code { UNPAIR ;                # un-pair to get the callee's address
         LAMBDA                  # define lambda
             (pair int int) int  
             { CAR } ;
         SCAN int ;              # call SCAN and expect an int to be returned  
         IF_NONE {} { ADD } ;
         NIL operation ;
         PAIR } }

### view injection

Add a new manager operation allowing contract owner to inject a legit view definition into an existing contract. That new added view must be named differently to those existing views. The contract owner could send such operaton via Tezos-client directly.

An additional implementation challenge is, the contract view is still considered as part of contract code. Which means we might want to refactor the storage layer to sperate views from the contract code.

- Pros:
- Caller does not need domain knowledge about the target contract. The person with most domain knowledge about the contract will write the view logic. And thus, in some sense, keeps the "private" storage private.
- Cons:
- The implicit account authorized for injecting views will need to be the originator address. Originator address is not currently used after origination (AFAIK) hence may not be considered important and can be a random dev addresses. This can be problematic since:
- The originator key can be lost (the dev who originated the contract changed his laptop, etc)
- The originator key can be exposed in low-security environment.
- There are some legacy contracts that are very hard or even impossible to reach out to their originator for asking patch.

#### example

> tezos-client patch view <contract_address> with <name> body <lambda>

## Proposed design

All soluions listed above has their pros and cons. Yet considering the UX and the level of challenge on the implementation, we believe adding a new specific instruction would be the most straightforward way.

## Appendix

### use case

#### oracle

Some newer oracles, for instance [Harbinger Price Oracle](https://tzkt.io/KT19B8uSfiQ8Cxk99ELc7MPccQ9ihyy7jhDU/views) and [Ubinetic Index Oracle](https://tzkt.io/KT1P8Ep9y8EsDSD9YkvakWnDvF2orDcpYXSq/views), have been originated with proper on-chain views since they were developed after the on-chain views was released. But many oracles, such as [Kolibri Oracle](https://tzkt.io/KT1Tj6xknbwjyK5gyfESNR6WESBcP3yX1mmj/entrypoints) and [Kaiko Price Oracle](https://tzkt.io/KT19kgnqC5VWoxktLRdRUERbyUPku9YioE8W/entrypoints), were created earlier. So, to interact with such oracle, the DApp is required to either use the off-chain views or the callback mechanism. Yet both solutions requires more resources comparing with using on-chain views directly.

#### NFT market

There is a callback view, `balance_of`, defined on the FA2 (TZIP-12). This makes lots of token contract has no on-chain views while they were originated, since it's not part of the FA2 standard. This kind of token contract would usually be ended up with a large token ledger in their stoage, such as [hicetnunc NFTs](https://tzkt.io/KT1RJ6PbjHpwc3M5rw5s2Nbmefwbuwbdxton/views), [FXHASH GENTK](https://tzkt.io/KT1KEa8z6vWXDJrVqtMrAeDVzsvxat3kHaCE/views), [akaSwap NFTs](https://tzkt.io/KT1AFq5XorPduoYyWxs5gEyrFK6fVjJVbtCj/views) and [Tez Dozen FA2](https://tzkt.io/KT1Xphnv7A1sUgRwZsecmAGFWm7WNxJz76ax/views), would have such callback view entrypoint yet no on-chain views.

As the result, many market contracts, which owns or need to interact with FA contract, have to call the callback view to get data from token contract. And even token contract update its contract code with on-chain view by originating a new contract, like [FXHASH GENTK 2](https://tzkt.io/KT1U6EHmNxJTkvaWJ4ThczG4FSDaHC21ssvi/views) does. It's clear that the existing tokens haven't been migrated to the new one. And thus the owner has to maintain and support both (or even multiple) token contracts.