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.
The following solutions are not mutually exclusive.
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
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
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.
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.
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!