External Views

External Views

Introduction

We need to look at data from the chain. A big hurdle in doing so is that different contracts have differently formed data, with different intended semantics. The Michelson types provide a starting template, but they are far from being enough.

Ideally, those views would be both programmatic (as in, they might involve computations), and signalled by the smart-contract in some way.
The latter is part of another amendment, namely, metadata. As such, we will focus here on how to make them programmatic, and the kind of obstacles we encounter when doing so.

Solutions

The following solutions are not mutually exclusive.

External Libraries

The most basic solution is to not add any kind of support in the RPCs. With this, it’s the job of different libraries (eg, Taquito, GoTezos, etc.) to do so.
There are a lot of problems with this solution:

  • It’s hard to maintain sync among multiple libraries maintained by different authors
  • Either the smart-contract writers have to write a plugin for each of those libraries, or for the maintainers of those libraries to add support for each smart-contract. This does not scale and will likely lead to massive fragmentation
  • For the indexers, the situation is even more complex, as they will also have to store this additional data

Additional RPCs

I think a big help to this is adding more RPCs. I am currently working on this (MR). There are two RPCs that I care about in particular

Views

This RPC is simple. It simply applies some code to the storage of a given smart-contract. The idea would then be for a smart-contract to add views to its metadata, which yield an interface to access the contracts, that external libraries can then uniformly use.

For instance, a smart-contract writer would write their contract in LIGO, add some views at the end, and compile all of them before originating the contract.

Reducers

This RPC is more complicated and I do not have a prototype ready yet. The idea would be for a smart-contract to add reducers (as in MapReduce) to its metadata, which yield an interface for indexers to store data about it.

For instance, the current FA 1.2 specification features a total supply entry-point. With reducers, there would be no need to compute this inside the contract. The same would be true for any arbtirary information.

I will fill in more information later as more work is done.

Events

There is no prototype ready yet. The idea would be to add an LOG instruction in Michelson. This would LOG arbitrary data from the smart-contract, which would then included in the receipt of the operation.

With metadata, these additional RPCs and events, a smart-contract could then be given a comprehensive high level interface for external actors, compatible with all tools using RPCs. I believe this would constitute a very fluid integration experience.


I welcome all kinds of feedback. If you are interested in working on any of those things, please contact me!

5 Likes

I think external views/reducers should be deployed on chain when the contract is originated and be a part of the contract definition available for the review and verification. They will not be loaded during normal contract execution, but be available to run off-chain using special RPC command.

2 Likes

I will second emishur’s proposal for view calls via the RPC. Contract specifications do not necessarily require a storage of a particular shape, but they include view entry points to access values from a contract. This is to allow values to be calculated and/or stored instead of just stored.

There is a roundabout technique to call the view points by implementing a Contract View Contract, calling it with run_operation dry run, causing an error, then retrieving and parsing the data out of the error.

Edit: You can use the empty signature edsigtXomBKi5CTRf5cjATJWSyaRvhfYNHqSUGrn4SdbYRcGwQrUGjzEfQDTuqHhuA8b2d8NarZjz8TRf65WkpQmo423BtomS8Q (a 64 length byte array with all 0s base58 encoded with edsig prefix) to run the dry operation without needing to sign with a private key.