Contract interface detection (part 2)

[bryanchriswhite]

Background

#129 closes #83 by implementing option 1 from the proposal in the description. We can improve the accuracy of our predictions over time if we combine the signal we're getting from contract instantiation messages with the signal we get from contract execution messages (i.e. method usage incl. signature and success/failure) as suggested by option 2.

Acceptance criteria

The following contribute to the Jaccard results accordingly:

Status	Failure type	Signal	Effect
Success	N/A	method name & signature match	base + bonus
Success	N/A	method name matches	base
*Failure	persistent (e.g. signature mismatch)	method name & signature match	- base - bonus
*Failure	persistent (e.g. out of gas money)	method name matches	?
*Failure	non-persistent (e.g. signature mismatch)	method name & signature match	no effect
*Failure	non-persistent (e.g. out of gas money)	method name matches	no effect

NOTE: "method signature", in this context, meaning "method call payload types signature"

Open questions

*Handling failure cases

Since #124, only the transaction and message primitive handlers are called in response to the indexer encountering a failed transaction. In order for the indexer to be able to consider the method name and payload of failed contract execution messages, we will have to add a new message handler. Assuming the number of failed contract execution messages the network sees is high as compared to other types of prospective entities and may come with a noticeable performance impact. This may be a reason worth considering ignoring the failure status cases.

Jaccard contribution

The case where status is failure and only method name matches seems less obvious that the others. It seems to me that an argument could be made for considering this a negative signal, like the other failure case, but weaker than in the case where the signature matches; however, it is possible that the signature not matching is the reason that the call failed. Furthermore, it is generally possible that the reason for failure could be unrelated to whether or not the contract conforms to a particular interface (i.e. not enough gas money). Perhaps we should be ambivalent with respect to failure cases unless we are also very confident that we are able to distinguish between these to classes of failure.

[Jonathansumner]

Into Sprint 11 update:

Current Implementation

At present, only option 1 from issue #83 description is implemented. The InstantiateContractMessage payload structure is analysed and scored based on the keys and value types compared against a known ideal structure. The result of which is then attributed to the resultant contract instance as the interface field, with an interface enum such as Interfaces.CW20.

These individual contract interface predictions do not yet contribute towards a collective classification of the contract code or StoreContractMessage at large. This renders the contract interface prediction shallow, but with a straightforward path to strengthen prediction confidence and expand upon input variety.

Future Direction

Option 3 from issue #83 should be investigated, where the ExecuteContractMessage method is considered, and specifically the success or failure of each. Observing accepted vs. failed method calls will help to flesh out the predicted model contract function, likely again by comparison against a known set of ideal contract methods.
Each of these method calls, alongside the instantiate message classification, could be collated into a richer and more nuanced categorisation that will describe the contract code itself with confidence.
This overarching interface prediction should be dynamically updated with newly indexed relevant entities.