Merge view and void entrypoints
A1 TZIP specifies two types of entrypoints whose purpose is to access some data from contract state:
- View entrypoints are defined as
view a r = (a, contract r). They allow other contracts to get some data from the current contract. You have to pass
contract rvalue which serves as a callback. It means that you have to originate a contract with parameter type
ror an entrypoint of type
rin order to use it.
- Void entrypoints are defined as
void a b = (a, lambda b b). They can be used off-chain to get some data from the contract. They do not require submitting anything to the Tezos network.
If we consider contract storage to be implementation detail, then one should access its data only using entrypoints. Sometimes we want to have a getter that can be used by other contracts (to get some data from this one) and be used off-chain to get some data easily.
I propose to add another type of "getter" entrypoint: one which combines view and void entrypoints. It should have two parameters (
r) and be defined as
(a, option (contract r). The idea is that if the second item is
Some contract, we treat it as a view entrypoint and if it is
None, we treat it as a void entrypoint and use
FAILWITH. The name of this entrypoint type is questionable, I will call it
getter in the rest of this issue, but I am not sure it's the best naming.
It's questionable what to do with view and void entrypoints: do we want to always use
getter or there are usecases for
voidentrypoints are useful when you do not want to expose some data to any other contract. I think we should definitely keep them.
viewentrypoints make it harder to get some data from outside. But it is still possible. I think the only advantage of
getteris that it is a bit cheaper, but the difference should be quite negligible.
That being said, I propose to deprecate
view and not deprecate
Also A1 says the following about void entrypoints:
They are included in the contract interface primarily to provide enable trust-less computation on the contract's storage. That is, the presence of the entrypoint on-chain implies that all parties can have certainty that anyone who calls a
voidwith identical arguments will compute the same result.
But I think it doesn't describe the main reason why they are useful: to be able to access contract data without knowing anything about its storage.