Multiple tx receipt types in SVM

[lrettig]

SVM currently defines three types of tx receipts, each one subtly different:

• deploy template receipt
• exec app receipt
• spawn app receipt

This is probably SVM-specific and not directly relevant to the API - for one thing, we're obviously much less concerned with data size in the API. But it's good to be aware of this.

We need to consider whether we want one, unified receipt type in the API, and if so, exactly which of these fields it should contain and how it should be implemented.

CC @avive @yaronwittenstein

[avive]

I think we want all relevant data in the receipt and make it typed in the api in one receipt type. There are placeholders in the current api to add it. The user provided args to the a transaction (packed binary) should ideally be provided encoded in the Transaction data item. We have in the API SmartContractTransaction data item but it currently only has a field for the binary / packed user provided arguments. It is very important for the platform's user friendliness to have these args unpacked and typed in this object. In a transaction receipt, we should have typed field which represent the result of execution based on the svm tx type. For example, the address of a new spawned app for a spwan transaction. Otherwise it is impossible for smart contract developer or wallet to interact with the app instance - he needs its address. Currently look at field app_address=8 in TransactionReceipt. There is no sense of having different types of receipts on the top-level because so much data is shared between all receipt types. I count at least 6 shared fields across different tx types. In the future, we might have additional types of transactions and we def do not want to create a new type of receipt for each of these but to reuse 1 receipt type to include the relevant data of these type of txs in a structured way.